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)
> > >
> > >
> > > > >port="15445" minProcessors="5" maxProcessors="75"
> > >enableLookups="true"
> > >acceptCount="100" debug="0" scheme="https"
> > secure="true"
> > >useURIValidationHack="false"
> > disableUploadTimeout="true">
> > >> > className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
> > >keystoreFile="../../certs/cheva/idp.keystore"
> > >keystorePass="changeit"
> > >clientAuth="true" protocol="TLS" />
> > >
> > >
> > > 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
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)
> >
> >
> > >port="15445" minProcessors="5" maxProcessors="75"
> >enableLookups="true"
> >acceptCount="100" debug="0" scheme="https"
> secure="true"
> >useURIValidationHack="false"
> disableUploadTimeout="true">
> >> className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
> >keystoreFile="../../certs/cheva/idp.keystore"
> >keystorePass="changeit"
> >clientAuth="true" protocol="TLS" />
> >
> >
> > 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
"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) > > > port="15445" minProcessors="5" maxProcessors="75" >enableLookups="true" >acceptCount="100" debug="0" scheme="https" secure="true" >useURIValidationHack="false" disableUploadTimeout="true"> >className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory" >keystoreFile="../../certs/cheva/idp.keystore" >keystorePass="changeit" >clientAuth="true" protocol="TLS" /> > > > 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]
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) 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]
