On 16 Feb 2013, at 9:42 PM, Graham Leggett <[email protected]> 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 --
smime.p7s
Description: S/MIME cryptographic signature
