You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/02/24 23:52:58 UTC
DO NOT REPLY [Bug 17350] New: -
SSL Handshake problem with Certificates
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: tomcat-dev@jakarta.apache.org
ReportedBy: tony@dahbura.com
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org