hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: httpclient v4.2.1 and client certificates
Date Sat, 16 Feb 2013 21:35:33 GMT
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.


View raw message