"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]
