On Sat, 2013-02-16 at 23:35 +0200, Graham Leggett wrote: > 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 > -- >
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 contexts. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
