You are currently browsing the tag archive for the ‘Tomcat’ tag.

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

Today I compiled a 32-bit jsvc daemon tool linked to a 32-bit Java JDK on a 64-bit machine. Turns out I didn’t need it but am recording my notes in case someone else does need it.

I’m using the jsvc source that is bundled with Tomcat and Sun’s Java SE Development Kit 6u10 (jdk-6u10-linux-i586.bin).

$ JAVA_HOME=/usr/java/jdk1.6.0_10-32bit

$ cd /usr/local/apache-tomcat-5.5.23/bin/jsvc-src

$ CFLAGS=-m32 CPPFLAGS=-m32 CCASFLAGS=-m32 LDFLAGS="-L/usr/lib -L/lib" \
./configure --build=i686-pc-linux-gnu

$ make

make will error with

gcc -L/usr/java/jdk1.6.0_10-32bit/lib -L/usr/lib -L/lib -ldl -lpthread jsvc-unix.o 
libservice.a -o ../jsvc /usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl ....

Adjust that failing gcc command with the -m32 switch and compile manually.

$ cd native/
$ gcc -m32 -L/usr/java/jdk1.6.0_10-32bit/lib -L/usr/lib \
 -L/lib -ldl -lpthread jsvc-unix.o libservice.a -o ../jsvc

There should now be a 32-bit jsvc binary in the jsvc-src directory.

$ file jsvc
jsvc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped

Tip of the hat to a Tomcat mailing list thread started by Rob Tanner

Categories

September 2019
M T W T F S S
« May    
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Latest del.icio.us

Advertisements