Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <1361052414.19031.22.camel@ubuntu>
Subject: Re: httpclient v4.2.1 and client certificates
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
Date: Sat, 16 Feb 2013 23:06:54 +0100
In-Reply-To: <EFF5AFA2-4568-4EEA-920D-5B940BF8829F@sharp.fm>
References: <EA041396-E198-4166-A872-7F1C523BB5CA@sharp.fm>
	 <EFF5AFA2-4568-4EEA-920D-5B940BF8829F@sharp.fm>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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
> --
> 

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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org