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 everywhere. Why cant we go back to that scheme? > > > > _______________________________________________ > 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
