A Campbell wrote: > -----Original Message----- > From: [email protected] [mailto:sipx-dev- > [email protected]] On Behalf Of Krzeminski, Damian > (BL60:9D30) > Sent: Thursday, April 02, 2009 10:10 AM > To: [email protected] > Subject: Re: [sipX-dev] XML/RPC and keystore > > 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/con > trib/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.
Agree with you Damian I don't see where restarting sipXconfig should hold us back. I am assuming when you add a server the admin would get a notification to restart sipXconfig? > > 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 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
