my2cents

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 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);
  }
}
...

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:

• http://issues.apache.org/jira/browse/HTTPCLIENT-634
• http://issues.apache.org/jira/browse/HTTPCLIENT-683
• http://issues.apache.org/jira/browse/HTTPCLIENT-783
• http://www.mail-archive.com/httpclient-user@jakarta.apache.org/msg03530.html

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

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

A thread from the tomcat-users mailing list archive helped a lot: http://www.mail-archive.com/users@tomcat.apache.org/msg55080.html. I didn’t initially find that through a web search because I kept looking for something like “principal null Tomcat Apache mod_jk” instead of “REMOTE_USER null”.