Having successfully enabled Hudson security with authentication against an LDAP server, I wanted to tweak the configuration to use a secure connection.

I tried using the ldaps scheme, ‘ldaps://ds1.crashingdaily.com’, as per the inline documentation but was confronted with the error “Syntax of this field is SERVER or SERVER:PORT”. I puzzled over this message for awhile, triple checked the syntax, consulted the support forums and then the source code to confirm that the syntax was indeed supported. Finally, I ignored the error, saved the configuration and tried a login. Then Hudson spit out a helpful exception in its Tomcat log:

hudson.security.AuthenticationProcessingFilter2
onUnsuccessfulAuthentication
INFO: Login attempt failed
org.acegisecurity.AuthenticationServiceException: Unable to connect to
LDAP server; nested exception is javax.naming.CommunicationException:
simple bind failed: ds1.crashingdaily.com:636 [Root exception is
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]; nested exception is
org.acegisecurity.ldap.LdapDataAccessException: Unable to connect to
LDAP server; nested exception is javax.naming.CommunicationException:
simple bind failed: ds1.crashingdaily.com:636 [Root exception is
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]
	at
org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser
(LdapAuthenticationProvider.java:238)

The key phrase to me there was ‘unable to find valid certification’. I suspected the Java classes used to negotiate the ldap connection were balking at my self-signed certificate coming from the ldap server. This wasn’t really a failure of Hudson specifically but rather a common issue for many language libraries and SSL applications. Typically the solution is as simple as pointing the library and/or application at the Certificate of Authority (CA) that was used to self-sign the server’s SSL cert. A quick Google search turned up sufficient information for me to import our CA into a keystore for Tomcat’s JVM.

For starters, I made a copy of the cacerts that ships with the JDK. This keystore contains a set of common, trusted CA certs. I don’t need them for Hudson but they may come in handy for future use.

$ cp $JAVA_HOME/jre/lib/security/cacerts /usr/local/tomcat/conf/

Now, I need to get the CA certificate for the ldap server. I have that file around here somewhere but rather than digging it up it’s simple to just get it from the ldap server using openssl.

$ openssl s_client -connect ds1.crashingdaily.com:636 -showcerts

This openssl command prints a list of certificates from the server, the last certificate is the CA. I copy that last certificate to a file, my-ca.crt, and import it into the cacerts keystore.

$ $JAVA_HOME/bin/keytool -import -alias myca -keystore cacerts \
-trustcacerts -file my-ca.crt

The -alias is not too important, it just has to be unique in the keystore. You can list the keys in the store with

$ $JAVA_HOME/bin/keytool -list -keystore  cacerts

Then I add a system property for Tomcat’s JVM that specifies the trustStore as my new cacert. For example, this can be added to the CATALINA_OPTS environment variable if you use the catalina.sh script that ships with Tomcat.

-Djavax.net.ssl.trustStore=/usr/local/tomcat/conf/cacerts

I restart the Tomcat instance for my Hudson installation and now Hudson is able to authenticate over a secure channel.

Related:

Apache Tomcat 5.5 SSL Configuration HOW-TO
Troubleshooting javax.net.ssl.SSLHandshakeException

Advertisements