DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17350>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17350 SSL Handshake problem with Certificates Summary: SSL Handshake problem with Certificates Product: Tomcat 4 Version: 4.1.18 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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). Tomcat is running on jdk 1.4. 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. Some comments from the mail list include: 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/ 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). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
