Thanks Bill. Upon using keytool's self sign cert I was able to get two-way trust working. Previously I was using certificates generated from BouncyCastle, and it didn't work (it could be my BC code that was generating incorrect/incomplete certs, but with one way trust - the client needing to verify tomcat, it did work). Did anyone else experience problems when using BouncyCastle certs, and if so, was there a remedy to the situation, other than using keytool?
Steve ----- Original Message ----- From: "Bill Barker" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 15, 2003 9:19 PM Subject: Re: two way trust > There have been very many client-cert changes since 4.1.12. For using Sun's > JVM (which you seem to be using), you probably need to upgrade to at least > 4.1.24. For other vendors, you need to upgrade to 4.1.27. In particular, > 4.1.12 uses JSSE 1.0.x, so you need to upgrade to take advantage of JSSE > 1.1.x. > > As of 4.1.27, client-cert works fine by itself. It isn't feature-complete > in the sense that most of the Realms that ship with Tomcat can't handle > client-cert authorization. > > > "Steve Kwong" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Does Tomcat support two way trust (HTTPS) between the client and itself, > > where the server requests for a X509 certificate from the client > connecting > > to it? I read somewhere that this feature isn't complete in the 4.1.x > > version of Tomcat. > > > > I've tried setting the config file as follows (I'm running Jboss > > 3.0.4/Tomcat 4.1.12 on Win2K server): > > > > <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" > > port="443" minProcessors="5" maxProcessors="75" > > enableLookups="false" > > acceptCount="100" debug="0" scheme="https" secure="true" > > useURIValidationHack="false" disableUploadTimeout="true"> > > <Factory > > className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory" > > keystoreFile="E:\\jboss-3.0.4_tomcat-4.1.12\\bin\\TOMCAT.KS" > > keystorePass="TOMCAT" > > clientAuth="true" protocol="TLS" /> > > </Connector> > > > > > > I am able to connect to Tomcat using a simple java-based ssl program when > > clientAuth="false", but it fails when I set it to true. I've specified a > > trust store (and trust store password) containing all the valid CA certs , > > in an environment variable: CATALINA_OPTS. > > > > The trace of the execution is as follows: > > > > Client write key: > > 0000: 82 17 82 46 A4 94 00 54 A8 13 D7 88 B0 92 17 C1 ...F...T........ > > Server write key: > > 0000: E0 C4 6E A4 D8 0F 78 23 B7 B0 6A 97 98 46 AD 40 ..n...x#..j..F.@ > > ... no IV for cipher > > JsseJCE: Using JSSE internal implementation for cipher > RSA/ECB/PKCS1Padding > > *** CertificateVerify > > main, WRITE: TLSv1 Handshake, length = 134 > > main, WRITE: TLSv1 Change Cipher Spec, length = 1 > > JsseJCE: Using JSSE internal implementation for cipher RC4 > > *** Finished > > verify_data: { 195, 128, 75, 187, 144, 183, 187, 156, 108, 255, 102, 85 } > > *** > > main, WRITE: TLSv1 Handshake, length = 32 > > main, READ: TLSv1 Alert, length = 2 > > main, RECV TLSv1 ALERT: fatal, bad_certificate > > main, called closeSocket() > > main, handling exception: javax.net.ssl.SSLHandshakeException: Received > > fatal al > > ert: bad_certificate > > javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate > > at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275) > > at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(DashoA6275) > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275) > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275) > > > > > > Any ideas? > > > > Steve > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
