2 Replies Latest reply on Jul 8, 2003 3:04 PM by ljoncas

    SSL Client Auth not working

    ljoncas Newbie

      I am migrating our product from HP-AS to JBoss and am evaluating both the Jetty and Tomcat integrations. I have most of our functionality working, but I cannot get SSL with client auth to work (without client auth it is working fine).

      Under Jetty, the SSL request fails with no logged info on server (getting Jetty to log more is another issue I have).

      Under Tomcat I get this server exception (null cert chain):

      2003-07-07 07:33:54,120 [Thread-15] DEBUG threads.ThreadPool - Getting new thread data
      2003-07-07 07:33:54,479 [Thread-16] DEBUG net.PoolTcpEndpoint - Handshake failed
      javax.net.ssl.SSLException: null cert chain
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
      at com.sun.net.ssl.internal.ssl.ServerHandshaker.a(DashoA6275)
      at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(DashoA6275)
      at com.sun.net.ssl.internal.ssl.Handshaker.process_record(DashoA6275)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
      at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
      at java.io.OutputStream.write(OutputStream.java:61)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275)
      at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:290)
      at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:540)
      at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
      at java.lang.Thread.run(Thread.java:484)

      I also noticed that dlindsay42 recently reported the same problem with 3.2.1 and said that it had been working fine with 3.0.x, but there hasn't been any response to that post. Is this a known problem with 3.2.1? Or can anyone suggest how I can get this working?


        • 1. Re: SSL Client Auth not working
          dlindsay42 Newbie

          With a bit of help, I figured out the 'null cert chain' problem. The problem is with a known bug in tomcat 4.x (and the 5.x too.) See tomcat bug #1400 and #19610 in the bug database at http://jakarta.apache.org/tomcat/bugreport.html It basically says that tomcat can't handle a server keystore with more then one entry. (It's also claimed that the alias for that entry must be 'tomcat' though i used a different alias just fine with tomcat 4.x).
          To fix this, put only the server certificate in the keystore (the one that the connector points to) and then in the jdk directory under jre/lib/security/cacerts you can add any CA certificates that the server needs to know about. The tomcat people said they WONT FIX the problem since it affects such a small number of people. ha! The whole authentication system could be polished off a bit (support crl's, ocsp protocol, etc) without much work to make ssl the norm rather then a frustrating add-on. anyhow, I'll stop my ranting. Hope this helps.

          • 2. Re: SSL Client Auth not working
            ljoncas Newbie

            Thanks for the suggestions (and glad you got it working). They were very helpful.

            I already had 2 separate keystore files (one with just the server cert and one with all the client certs). And I didn't want to muck with the cacerts file. So I got it to work under Tomcat by doing this before starting JBoss:

            set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStore=<my_truststore_path>

            Under Jetty, this standard way of redefining the truststore didn't seem to have any effect. So with Jetty, the only way I could get it to work was to do 2 things:

            In the SunJsseListener config added the line

            And modified the keystore file (also specified in SunJsseListener config) to include both the server cert and the client certs!

            If anybody has a suggestion for how to configure Jetty to allow 2 separate keystore files AND/OR to allow both Tomcat and Jetty SSL configs to be based on the same artifacts, I'd love to hear about it.