httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Risacher <>
Subject mod_ssl breaks connection if peer doesn't send client certificate
Date Fri, 05 Aug 2005 19:52:38 GMT

If SSLVerifyClient is 'require', but the client doesn't send a
certificate (e.g. Netscape won't send an expired user cert), then
mod_ssl breaks the connection before any response can be sent. This
message appears in the error log: "Re-negotiation handshake failed:
Not accepted by client!?"

When this happens, the user cannot get an error document that might
explain how to fix the condition, and (for Netscape and IE) leaves the
browser confusingly with the new URL in the URL bar, but displaying
the last sucessfully loaded page.

I conclude that this is a bug in mod_ssl.  I think the problem is that
if SSLVerifyClient is 'require', then OpenSSL is set to
SSL_VERIFY_PEER_STRICT.  When OpenSSL fails to verify the client cert,
it terminates the SSL connection, and therefore no response can be
sent (even 403 FORBIDDEN).

I suggest that mod_ssl should use SSL_VERIFY_PEER when SSLVerifyClient
is set to 'require', and let ssl_hook_Access() return HTTP_FORBIDDEN
when the cert validation fails.  Alternatively, there could be a new
value for SSLVerifyClient that has that behavior.

Adding a new value for SSLVerifyClient has better backwards
compatibility, but personally I beleive that the current behavior
(dropping the connection without an error response) is sufficiently
broken that httpd shouldn't ever do that.  Any thoughts on which of
these is better?


View raw message