Re: TOMCAT AND TLS CLIENT AUTHN
Hi Bill and others: Thank you very much for you help. I am employing the SUN JDK 1.4.1_03 in Red Hat Linux 9.0, with Tomcat 4.1.24. When you say that there is a bug in JSSE/PureTLS, I assume that the bug is in the JDK, is that correct? Only to confirm all my steps. What I'm doing is to include my client cert like a trustcert in the server cert truststore... System.setProperty(java.protocol.handler.pkgs,com.sun.net.ssl.internal.www.protocol); System.setProperty(javax.net.ssl.trustStore,keyStore); System.setProperty(javax.net.ssl.keyStorePassword,keyStorePasswordCA); Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); I employ the same code in the client part, I get the following exception: bjavax.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.a(DashoA6275) at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_az.j(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275)ut Thanks in advance, Evaristo On Tue, 2003-07-22 at 05:41, Bill Barker wrote: Evaristo Camarero [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all: I'm running Tomcat 4.1.24 and I'm trying to configure TLS client authn. I have created a SSL connector (in server.xml) !-- Define a SSL Coyote HTTP/1.1 Connector on port 15445 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=15445 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=100 debug=0 scheme=https secure=true useURIValidationHack=false disableUploadTimeout=true Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory keystoreFile=../../certs/cheva/idp.keystore keystorePass=changeit clientAuth=true protocol=TLS / /Connector Now my question is what is the process tomcat employs to validate client certs. Validation of the certificate chain is handled by JSSE/PureTLS (although there is a bug in the current release of the PureTLS code that prevents it from working -- fixed in the next release).It will make certain that the Root signer cert is a recognized trusted cert, and that the user cert (and any intermediate certs) are all valid (including checking Basic-Contraints). At this point, the cert chain is available from Tomcat on request. It is up to your application/Realm to verify that the certificate is from somebody that you actually know. At the moment, the only Tomcat Realm that works with CLIENT-CERT authentication is MemoryRealm, but there are some patches in bugzilla for some of the other ones (I'm just too lazy to look up the bug numbers :). Have anybody tested this feature? Yes ;-). Thanks in advance, /Evaristo Camarero - 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: TOMCAT AND TLS CLIENT AUTHN
The bug is only in the PureTLS implementation (so unless you have installed the PureTLS jars, you won't see it). JSSE works fine. With a 4.1.x JVM, it is generally a-bad-idea to call addProvider or set Security related properties. The vendor should have set them correctly already (and, AFAIK, Sun does). I don't have enough info to debug your error, but at a guess, the Root signer of your client cert isn't included in your cacerts file. I believe that Sun only includes Verisign and Thwate in it's cacerts file (but I'm too lazy to look it up on java.sun.com :). If this is the case, then consult the 'keytool' documentation for how to add your signer to the cacerts file. Evaristo Camarero [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Bill and others: Thank you very much for you help. I am employing the SUN JDK 1.4.1_03 in Red Hat Linux 9.0, with Tomcat 4.1.24. When you say that there is a bug in JSSE/PureTLS, I assume that the bug is in the JDK, is that correct? Only to confirm all my steps. What I'm doing is to include my client cert like a trustcert in the server cert truststore... System.setProperty(java.protocol.handler.pkgs,com.sun.net.ssl.internal.ww w.protocol); System.setProperty(javax.net.ssl.trustStore,keyStore); System.setProperty(javax.net.ssl.keyStorePassword,keyStorePasswordCA); Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); I employ the same code in the client part, I get the following exception: bjavax.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.a(DashoA6275) at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_az.j(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275)ut Thanks in advance, Evaristo On Tue, 2003-07-22 at 05:41, Bill Barker wrote: Evaristo Camarero [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all: I'm running Tomcat 4.1.24 and I'm trying to configure TLS client authn. I have created a SSL connector (in server.xml) !-- Define a SSL Coyote HTTP/1.1 Connector on port 15445 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=15445 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=100 debug=0 scheme=https secure=true useURIValidationHack=false disableUploadTimeout=true Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory keystoreFile=../../certs/cheva/idp.keystore keystorePass=changeit clientAuth=true protocol=TLS / /Connector Now my question is what is the process tomcat employs to validate client certs. Validation of the certificate chain is handled by JSSE/PureTLS (although there is a bug in the current release of the PureTLS code that prevents it from working -- fixed in the next release).It will make certain that the Root signer cert is a recognized trusted cert, and that the user cert (and any intermediate certs) are all valid (including checking Basic-Contraints). At this point, the cert chain is available from Tomcat on request. It is up to your application/Realm to verify that the certificate is from somebody that you actually know. At the moment, the only Tomcat Realm that works with CLIENT-CERT authentication is MemoryRealm, but there are some patches in bugzilla for some of the other ones (I'm just too lazy to look up the bug numbers :). Have anybody tested this feature? Yes ;-). Thanks in advance, /Evaristo Camarero - 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]
TOMCAT AND TLS CLIENT AUTHN
Hi all: I'm running Tomcat 4.1.24 and I'm trying to configure TLS client authn. I have created a SSL connector (in server.xml) !-- Define a SSL Coyote HTTP/1.1 Connector on port 15445 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=15445 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=100 debug=0 scheme=https secure=true useURIValidationHack=false disableUploadTimeout=true Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory keystoreFile=../../certs/cheva/idp.keystore keystorePass=changeit clientAuth=true protocol=TLS / /Connector Now my question is what is the process tomcat employs to validate client certs. Have anybody tested this feature? Thanks in advance, /Evaristo Camarero - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TOMCAT AND TLS CLIENT AUTHN
Evaristo Camarero [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all: I'm running Tomcat 4.1.24 and I'm trying to configure TLS client authn. I have created a SSL connector (in server.xml) !-- Define a SSL Coyote HTTP/1.1 Connector on port 15445 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=15445 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=100 debug=0 scheme=https secure=true useURIValidationHack=false disableUploadTimeout=true Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory keystoreFile=../../certs/cheva/idp.keystore keystorePass=changeit clientAuth=true protocol=TLS / /Connector Now my question is what is the process tomcat employs to validate client certs. Validation of the certificate chain is handled by JSSE/PureTLS (although there is a bug in the current release of the PureTLS code that prevents it from working -- fixed in the next release).It will make certain that the Root signer cert is a recognized trusted cert, and that the user cert (and any intermediate certs) are all valid (including checking Basic-Contraints). At this point, the cert chain is available from Tomcat on request. It is up to your application/Realm to verify that the certificate is from somebody that you actually know. At the moment, the only Tomcat Realm that works with CLIENT-CERT authentication is MemoryRealm, but there are some patches in bugzilla for some of the other ones (I'm just too lazy to look up the bug numbers :). Have anybody tested this feature? Yes ;-). Thanks in advance, /Evaristo Camarero - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
