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" <[EMAIL PROTECTED]> wrote in message
> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> >
> >
> >>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
> >>[EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >

--
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
[EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to