You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bill Barker <wb...@wilshire.com> on 2003/08/16 06:19:36 UTC
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" <st...@intergate.bc.ca> wrote in message
news:005401c363a4$0b7c7cc0$6984c0c0@GUNDAMDOM...
> 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
Re: two way trust
Posted by Steve Kwong <st...@intergate.bc.ca>.
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" <wb...@wilshire.com>
To: <to...@jakarta.apache.org>
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" <st...@intergate.bc.ca> wrote in message
> news:005401c363a4$0b7c7cc0$6984c0c0@GUNDAMDOM...
> > 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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
Re: two way trust
Posted by Steve Kwong <st...@intergate.bc.ca>.
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" <wb...@wilshire.com>
To: <to...@jakarta.apache.org>
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" <st...@intergate.bc.ca> wrote in message
> news:005401c363a4$0b7c7cc0$6984c0c0@GUNDAMDOM...
> > 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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org