> -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Monday, May 09, 2011 8:41 AM > To: [email protected] > Subject: Re: Can CXF's "http:conduit" be configured to deal with self- > signed certs or a custom verification? > > 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.
Considering the breadth and scope of most applications deployed to a single JVM on typical application servers, I'd consider this a risky approach. > 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. This sounds like a very good thing, as long as the proper hooks are made available.
