Hi On Mon, May 9, 2011 at 3:06 PM, KARR, DAVID (ATTSI) <[email protected]> wrote: >> -----Original Message----- >> From: Sergey Beryozkin [mailto:[email protected]] >> Sent: Monday, May 09, 2011 2:30 AM >> To: [email protected] >> Subject: Re: Can CXF's "http:conduit" be configured to deal with self- >> signed certs or a custom verification? >> >> Hi >> >> One thing which is possible to do with CXF is to have multiple >> HTTPConduit configurations provided, one >> conduit can use SSL configuration relying on a self-signed cert, the >> other one - configuration with a a proper certificate. >> Each conduit bean can have a name attribute specifying a URI pattern >> (reg ex), ex: >> >> <http:conduit >> name="https://localhost:.*/production/customerservice/.*";> >> ... >> </http:conduit> >> >> <http:conduit name="https://localhost:.*/test/customerservice/.*";> >> ... >> </http:conduit> >> >> At runtime, the conduit matching request URIs used by the client code >> will be activated. >> >> What I don't know is how to configure an individual HTTPConduit to >> trust self-signed certificates. I've talked to Colm and explained that >> all or most of CXF tests have server certs signed but we also do >> generate the certs which are used to sign the server certs but keep >> them in the trust store and then we have Conduit configuration >> pointing to relevant key and trust stores, as in this file for ex: >> >> http://svn.apache.org/repos/asf/cxf/trunk/distribution/src/main/release >> /samples/jax_rs/basic_https/src/main/resources/ClientConfig.xml >> >> It appears it is currently not possible to explicitly configure >> HTTPConduit with a custom SSLSocketFactory, but at least it is >> possible to tell it to use the default SSLSocketFactory which might've >> been setup using >> >> HttpsURLConnection.setDefaultSSLSocketFactory(SSLSocketFactory) >> >> I've found this info here: >> >> http://www.frightanic.com/tag/ssl/ >> >> If anyone has more info then share it with us please > > So it appears that at the present time I would have no way to do this, if I > needed it. Correct? Just to clarify, again, I don't presently need this, > but I just finished work on a REST client project where we were using > HttpClient, but I had to configure the socket factory this way. I'm trying to > move my development group towards more use of Spring and CXF. Internally, we > have many servers with differing requirements. I think it's likely we'll run > into this situation again sometime in the future. >
I think the fact that HttpConduit can not be configured to deal with self-signed certs is not a problem. It's a restriction but configuring HttpConduit to check the key store and trust store is not a problem. In fact such a configuration will be identical between test and production cases, the only difference will be the location of key & trust stores and thus the whole HttpConduit config can be parameterized and reused between concrete HttpConduit beans. I haven't tried it with HttpConduit, but it appears one can override a VM wide SSLSocketFactory and tell HTTPConduit to use it. A more fine grained SSLSocketFactory registration is likely not possible at the moment, possibly because it HTTPConnection which is used under the hood, as Willem noted. Actually I think we have a JIRA to do with supporting Apache HttpClient. Cheers, Sergey
