hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: httpclient v4.2.1 and client certificates
Date Sat, 16 Feb 2013 22:06:54 GMT
On Sat, 2013-02-16 at 23:35 +0200, Graham Leggett wrote:
> On 16 Feb 2013, at 9:42 PM, Graham Leggett <minfrin@sharp.fm> wrote:
> > I am currently struggling with a problem attempting to use a client certificate
to connect to a secure website using httpclient v4.2.1.
> > 
> > When SSL debugging is enabled, I can see that despite the following -D options being
passed, the keyStore is completely ignored:
> > 
> > -Djavax.net.ssl.trustStore=/path/to/cacerts -Djavax.net.ssl.keyStore=/path/to/certificate.p12
-Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.keyStoreType=PKCS12
> > 
> > The file /path/to/cacerts is read correctly, and the trust chain of the remote server
is correctly verified.
> > 
> > The file /path/to/certificate.p12 is completely ignored, and the remote server rejects
the connection claiming (correctly) that the certificate is missing.
> > 
> > Can anyone confirm whether a bug exists with httpclient and the ability to specify
a client certificate? All the docs I've read to date suggest that httpdclient reads javax.net.ssl.keyStore,
but the behaviour I am seeing would suggest this is broken.
> Some digging through the source has revealed the problem.
> It appears there are two classes that instantiate an HTTP connection, DefaultHttpClient
and SystemDefaultHttpClient. Despite both claiming to be "default" behaviour, the real default
behaviour is given by SystemDefaultHttpClient, which respects the -D parameters.
> DefaultHttpClient gives you semi-non-default behaviour. In this code the javax.net.ssl.keyStore
parameter is ignored, but javax.net.ssl.trustStore is respected. I am assuming that the idea
is that the caller would set the certs themselves rather than rely on system wide defaults,
using the various constructors for SSLSocketFactory.
> Regards,
> Graham
> --


Historically HttpClient does not take any system properties into account
by default given that it some managed environments access to system
properties is restricted. The semi-non-default behaviour is what you get
when creating an SSL context without any explicit trust / key material.
Generally the users of HttpClient are expected to supply an SSL context,
which is appropriate for their specific applications rather than
HttpClient trying to figure out some sensible defaults in various


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message