M. Ranganathan wrote: > On Wed, Apr 1, 2009 at 11:31 PM, M. Ranganathan <[email protected]> wrote: >> On Wed, Apr 1, 2009 at 5:26 PM, Damian Krzeminski <[email protected]> >> wrote: >>> I was chatting with Ranga on #sipx about it and somehow I got disconnected. >>> >>> Apparently because of some changes in how certificates are created we now >>> have to reload the keystore and it does not seem trivial. >>> >>> One of the options of solving that (not sure if that would work but hey - >>> anything is better than restarting). >>> >>> sipXconfig is using Apache XmlRpc to use xml/rpc. This library lets you >>> choose one of the 3 transports for XmlRpc. Default one - the one that we >>> are using is based on standard java.net.URLConnection >>> >>> However we always have an option to switch to the one based on Apache >>> commons HttpClient library (we already use it for something else). >>> (sipXconfig creates XmlRpcClient in >>> XmlRpcClientInterceptor.afterPropertiesSet this is the place where the >>> transport factory would have to be passed) >>> >>> If we were to switch we could probably use AuthSSLProtocolSocketFactory and >>> register it with Protocol.registerProtocol("https", authhttps); >>> >>> http://www.jdocs.com/httpclient/3.0.1/org/apache/commons/httpclient/contrib/ssl/AuthSSLProtocolSocketFactory.html >>> >>> >>> Maybe we could try to reregister protocol when we need to re-read the >>> keystore. >>> >>> Damian >> Thats a possibility. >> >> I wonder how this ever worked. Another thing that ought to work is to >> use the same key/certificate pair for all hosts in the cluster for xml >> rpc. >> >> I do not see any way of dynamically updating the trust store used by a >> running jvm - especially because one does not have access to the trust >> store instance that is being used for xml rcp. >> >> Is there a specific need for each host to have its own key / >> certificate ? If all hosts can use the same key then we have only one >> key/certificate pair. This will greatly simplify things. I think this >> is how the 3.10 version used to work. NOTE : I added update of the >> java keystore to gen-ssl-keys ( as requested by Scott ). This code >> never existed in 3.10. Consequently the same key was being used > > That should read "Consequently I *believe* the same key pair was > being used across the cluster for XML RPC". > > In other words, gen-ssl-keys never did update the JVM trust store > prior to this change. There was no code to do that import into the > truststore.jks file in other words. The startup script > "javacertsetup.sh" (and prior to that the code in sipxconfig.sh in a > previous iteration of this never ending re factoring) used to check > if the cert existed and update the trust store prior to starting the > jvm. > > >> everywhere. Why cant we go back to that scheme? >> > > > Is this a significant usability hit to have to restart sipxconfig on > Master when you add a new node, given the rarity of that event ? >
It's a disappointing news: we spent quite a lot of time making sure that adding a new secondary server would be as seamless as possible. That said - at this point people are probably sick and tired waiting for a stable 4.0 builds. There is a ton of a new functionality there: most of it well tested and ready to be used. I want to go through remaining 30-ish issues on sipXconfig list so that we are ready to make a stable branch and I do not have time to look into the cert problems at the moment. So I propose that we just go with what we have and try to improve upon is as soon as it's practical. > Note : You have that same problem when you install a web key. > sipxconfig needs to be restarted here too. We need to add some code > there to accomplish that. > That's a bit different: if I change a cert for the server. It's kind of natural that I have to restart the server. When I add a new peer I be surprised I still have to restart a server. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
