cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Can CXF's "http:conduit" be configured to deal with self-signed certs or a custom verification?
Date Mon, 09 May 2011 15:41:28 GMT

On Mon, May 9, 2011 at 3:06 PM, KARR, DAVID (ATTSI) <> wrote:
>> -----Original Message-----
>> From: Sergey Beryozkin []
>> Sent: Monday, May 09, 2011 2:30 AM
>> To:
>> 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:
>> /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:
>> 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

View raw message