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]
