Self-signed SSL certificates with Apache HttpClient

frightanic — Mon, 05 Apr 2010 09:14:24 +0000

When you need to support self-signed SSL certificates in your Apache HttpClient based application you can use the contributed EasySSLProtocolSocketFactory as described in the HttpClient docs.

Instead of using HttpClient’s HostConfiguration object directly you’d modify its protocol socket factory in your code like so:

...
if (config.isAllowSelfSignedCertificates()) {
  ProtocolSocketFactory factory = new EasySSLProtocolSocketFactory();
  try {
    URI uri = new URI(config.getBaseUrl());
    int port = uri.getPort();
    if (port == -1) {
      port = 443;
    }
    Protocol easyHttps = new Protocol(uri.getScheme(), factory, port);
    hostConfiguration.setHost(uri.getHost(), port, easyHttps);
  } catch (URISyntaxException e) {
    throw new IOException("could not parse URI " + config.getBaseUrl(), e);
  }
}
...

Somewhere you’d instantiate a HttpClient object. Then you get its host config through HttpClient#getHostConfiguration() – I stored this in the hostConfiguration variable. The if, the config variable, checking for port, etc. is all my own code and has nothing to do with HttpClient directly.

There is one caveat, though! Never use absolute URIs against the HttpClient 3.x with the EasySSLProtocolSocketFactory in place! If you did you’d get the dreaded

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I found that the HttpClient 3.x has the following code in its executeMethod() method:

...
if (hostconfig == defaulthostconfig || uri.isAbsoluteURI()) {
  // make a deep copy of the host defaults
  hostconfig = (HostConfiguration) hostconfig.clone();
  if (uri.isAbsoluteURI()) {
      hostconfig.setHost(uri);
  }
}
...

So, in my case (absolute URI) the modified host config (uses EasySSLProtocolSocketFactory) is cloned.

Problem: since the so called “deep copy” isn’t a proper deep copy the copy’s protocol’s socket factory is no longer EasySSLProtocolSocketFactory but the standard SSLProtocolSocketFactory instead!

Update

Apparently, this behavior is “well known and documented”. Since I couldn’t find anything in the HttpClient 3.x documentation I tried Google again and made note of the following JIRA issues and one particular mailing list entry:

Please note that HttpClient 4.x does not have this limitation!

No principal in request after Apache basic authentication with mod_jk

frightanic — Fri, 11 Sep 2009 21:08:46 +0000

Yet another software configuration issue that I wasted a few hours at today.

Environment

Apache 2.2.13 connect to Tomcat 5.5 with mod_jk (ajp13). Apache requires basic-auth for “/” i.e. for all URLs it serves. Just to be 100% precise, Tomcat runs as a WTP server “inside” Eclipse. However, the fact that it’s not a standalone instance has no effect to either the problem or the solution.

Problem

I noticed that request.getUserPrincipal() returned null in my Servlet filter although basic-auth in Apache was successful. By raising the mod_jk log level to debug (JkLogLevel debug) and looking at the mod_jk.log I could confirm, however, that mod_jk at least passed the remote user along in the request.

Solution

Set tomcatAuthentication=”false” for the AJP/1.3 connector in server.xml. The parameter is explained in the Tomcat connector documentation: “If set to true, the authentication will be done in Tomcat. Otherwise, the authenticated principal will be propagated from the native webserver and used for authorization in Tomcat. The default value is true.”