On Thu, Apr 2, 2009 at 10:19 AM, Alfred Campbell <[email protected]> wrote: > 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.
The problem has been fixed. This workaround of having to restart sipxconfig on HA install is no longer necessary. >> >> _______________________________________________ >> 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 > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
