M. Ranganathan wrote: > On Thu, Apr 2, 2009 at 10:09 AM, Damian Krzeminski <[email protected]> > wrote: >> 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. > > > I agree this would be a good course of action. The other option is to > go with a system wide key pair ( which is less secure - given that if > one server is compromised they are all compromised). > > >>> 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. > > > > In fact the problem is not the xml RPC client that we are using in > sipxconfig. I believe it is is because sipxconfig is using default > mechanisms (provided by Jetty) to initialize the trust store. That > trust store is system wide and the default ssl socket factory uses it. > Hence when the xml rpc client is initialized, it is creating a socket > that uses the same trust store as jetty. If you got rid of the xml > based initialization of jetty and used an explicit trust store which > you hand over to jetty during initialization, you subsequently retain > a pointer to that trust store. You will then be able to re-read the > contents of the jks database when ever those contents have changed. I > believe (tm) that this will solve the problem. Note that the trust > store is an in memory structure. The jvm does not automatically scan > the contents of that trust store database file if those contents > change. This is the problem we are running into. > > Note too that in this case the master sipxconfig instance is a client > (not a server). If that client does not have a way to re-read the > trust store we are out of luck. > >
I still think that the problem is the way we use XMl/RPC library (basically allowing it to use default keystore and trustore) and that it has very little to do with the way we are initializing jetty (which is only using the keystore to set up its SSL listener) ... But I don't have time to get to the gritty details of that at the moment. That said: all the options should be on the table. If someone sends the patch that would solve the problem by changing the way jetty is configured I won't reject it without review. 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
