Re: two way trust
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):
> >
> > > port="443" minProcessors="5" maxProcessors="75"
> > enableLookups="false"
> > acceptCount="100" debug="0" scheme="https" secure="true"
> > useURIValidationHack="false"
disableUploadTimeout="true">
> > > 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" />
> >
> >
> >
> > 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:
> > : 82 17 82 46 A4 94 00 54 A8 13 D7 88 B0 92 17 C1
...F...T
> > Server write key:
> > : 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]
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):
>
> port="443" minProcessors="5" maxProcessors="75"
> enableLookups="false"
> acceptCount="100" debug="0" scheme="https" secure="true"
> useURIValidationHack="false" disableUploadTimeout="true">
> 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" />
>
>
>
> 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:
> : 82 17 82 46 A4 94 00 54 A8 13 D7 88 B0 92 17 C1 ...F...T
> Server write key:
> : 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]
two way trust
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):
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:
: 82 17 82 46 A4 94 00 54 A8 13 D7 88 B0 92 17 C1 ...F...T
Server write key:
: 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]
