tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: interesting problem bug with client certificates?
Date Fri, 21 Feb 2003 07:33:19 GMT
Firstly I would *Strongly* recommend filing a bug report at
http://nagoya.apache.org/bugzilla, simply so that it doesn't get lost in the
traffic on this list.

The basic problem is that the JSSE that ships with JDK1.4 doesn't allow
simply sending back a re-handshake request.  It won't actually send it down
the wire until there is content to send as well.  This is what is confusing
Mozilla & Netscape (since Tomcat tries (it seems, unsuccessfully :(, to fake
the browser out when running under JDK1.4).

As I mentioned before, a short-term solution is to use PureTLS from
http://www.claymoresystems.com/puretls_main.html.  All you need to do is to
install the jars in $CATALINA_HOME/server/lib, and Tomcat will use it by
preference.

"Tony Dahbura" <tony.dahbura@eds.com> wrote in message
news:3E5558D1.E10B141E@eds.com...
> The problem does go away with jdk 1.3 using jsse software instead of jdk
1.4.
>
> How do we fix it for jdk 1.4?
>
> Tony
>
>
>
>
> Tony Dahbura wrote:
>
> > Bill:
> > Can you tell me how or point me to some docs on how to do the tcp traces
> > you are requesting?
> >
> > I can certainly run some test cases and deposit them in the bug report.
> >  Yes I am using jdk 1.4!
> >
> > Thanks,
> > Tony
> >
> > Bill Barker wrote:
> >
> > >"Tony Dahbura" <tony.dahbura@eds.com> wrote in message
> > >news:3E4BA723.78680724@eds.com...
> > >
> > >
> > >>Team:
> > >>I have noticed something very inconsistent within Tomcat 4.1.18.
> > >>
> > >>My application is using client certificates over ssl (these all occur
> > >>after I unlock and present my certificate (which btw is the same on
all
> > >>three of these browsers).
> > >>
> > >>When I access my protected resource with IE version 6.0 all works
fine.
> > >>
> > >>When I access my protected resource with Mozilla version 1.1 I receive
> > >>an error page from tomcat that says:
> > >>HTTP Status 400 - No client certificate chain in this request.
> > >>Description:The request sent by the client was syntactically incorrect
> > >>(No client certificate chain in this request).
> > >>If I hit reload it works fine.
> > >>
> > >>When I access my protected resource with Netscape Communicator I
receive
> > >>a blank page.
> > >>After hitting reload I am prompted for my certificate again and it
works
> > >>correctly.
> > >>
> > >>I believe this message is being generated by the following code in
> > >>org.apache.catalina.authenticator.SSLAuthenticator.java:
> > >>
> > >>// Retrieve the certificate chain for this client
> > >>        HttpServletResponse hres =
> > >>            (HttpServletResponse) response.getResponse();
> > >>        if (debug >= 1)
> > >>            log(" Looking up certificates");
> > >>        X509Certificate certs[] = (X509Certificate[])
> > >>
> > >>request.getRequest().getAttribute(Globals.CERTIFICATES_ATTR);
> > >>        if ((certs == null) || (certs.length < 1)) {
> > >>            certs = (X509Certificate[])
> > >>
> > >>request.getRequest().getAttribute(Globals.SSL_CERTIFICATE_ATTR);
> > >>        }
> > >>        if ((certs == null) || (certs.length < 1)) {
> > >>            if (debug >= 1)
> > >>                log("  No certificates included with this request");
> > >>            hres.sendError(HttpServletResponse.SC_BAD_REQUEST,
> > >>
sm.getString("authenticator.certificates"));
> > >>            return (false);
> > >>        }
> > >>
> > >>My question is why the inconsistent behavior between browsers?
Secondly
> > >>if I do not do cert authentication within my webapp but instead turn
it
> > >>on for the whole SSL context (using clientAuth) I do not get this
> > >>message with any of the above mentioned browsers.
> > >>
> > >>
> > >
> > >The special (internal to Tomcat) 'SSL_CERTIFICATE_ATTR' attribute
causes
> > >Tomcat to re-negotiate the handshake with the additional requirement of
a
> > >client cert if there isn't already a cert present (and this is why
> > >clientAuth works).
> > >
> > >In addition, for the JDK1.4 of JSSE, there are some tricks to get
around
> > >that version's refusal to re-negotiate until there is real traffic on
the
> > >Socket.  This is probably what is confusing Mozilla & Netscape.  You
can
> > >file a bug-report at http://nagoya.apache.org/bugzilla/, but it would
be
> > >more helpful (and very welcome :) if you could include the TCP traces
as
> > >well.
> > >
> > >I'm guessing that you are using JDK1.4.  I'm also guessing that
down-grading
> > >to JDK1.3.1.x+JSSE 1.0.2 would suddenly cause everything to start
working.
> > >Another option would be to use PureTLS (http://www.rtfm.com/puretls/).
I
> > >haven't tried it with JDK1.4.x, but it works well with JDK1.3.1.x.
> > >
> > >
> > >
> > >
> > >>Thanks,
> > >>Tony
> > >>
> > >>
> > >>
> > >>--
> > >>Tony Dahbura
> > >>Deployment Director
> > >>Opsware Business Practice
> > >>EDS Inc.
> > >>13900 Lincoln Park Drive
> > >>Suite 405/WH-OPS
> > >>Herndon, VA  20171
> > >>voice: 703.742.1280
> > >>fax: 703.742.1163
> > >>tony.dahbura@eds.com
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > >
> > >
> > >
>
> --
> Tony Dahbura
> Deployment Director
> Opsware Business Practice
> EDS Inc.
> 13900 Lincoln Park Drive
> Suite 405/WH-OPS
> Herndon, VA  20171
> voice: 703.742.1280
> fax: 703.742.1163
> tony.dahbura@eds.com




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message