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):
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:
: 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]
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):
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:
: 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]
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:
: 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]
