Bug 1247758 - [RFE] Gracefully handle client certificate errors when using 'SSLVerifyClient require'
[RFE] Gracefully handle client certificate errors when using 'SSLVerifyClient...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: httpd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Luboš Uhliarik
BaseOS QE - Apps
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2015-07-28 15:34 EDT by Nathan Kinder
Modified: 2018-04-04 03:36 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nathan Kinder 2015-07-28 15:34:04 EDT
When using the 'SSLVerifyClient require' directive to enforce client certificate authentication, common errors such as accessing the protected location from a browser that doesn't have a client certificate available are not handled in a graceful way.  Currently, it seems that mod_ssl simply terminates the SSL/TLS handshake.  This results in ugly error messages for the user in the browser.

The fact that the handshake is terminated also means that we are unable to catch the error by using the 'ErrorDocument' directive.  Ideally, mod_ssl would simply return a 4xx error when no client certificate is available, which we would be able to catch.  This would allow us to present a more useful error page, or to fallback to an alternate authentication method such as a login form or Kerberos protected location.  This is exactly the methdo we use in CLoudForms and Satellite right now to allow Kerberos authentication to fallback to forms-based authentication.  We are unable to do this with client certificate authentication unless mod_ssl fails more gracefully.  Here is an example of the configuration that I would like to be able to use from a Satellite 6 test system of mine:

<Location /users/extlogin>
  SSLOptions +StdEnvVars +ExportCertData -FakeBasicAuth
  SSLVerifyClient require
  LookupUserByCertificate On
  ErrorDocument 403 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Certificate authentication did not pass.</body></html>'

With this configuration, I see the following in the httpd access log when I access this location from a browser without a client certificate:

-------------------------------------------------------- - - [28/Jul/2015:12:22:40 -0700] "GET /users/extlogin HTTP/1.1" 403 123 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0"

Despite the fact that this shows a 403 response, the 'ErrorDocument' directive does not take effect.  Forefox also doesn't actually receive a 403, but gets this ugly message:

Secure Connection Failed

An error occurred during a connection to satellite.example.test. SSL peer was unable to negotiate an acceptable set of security parameters. (Error code: ssl_error_handshake_failure_alert)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

    Please contact the website owners to inform them of this problem.

As a potential workaround, I also tried to set 'SSLVerifyClient optional'.  This does allow my 'ErrorDocument' directive to work properly when I do nto have a client certificate available in the browser.  The problem here is that I never get prompted to supply a client certificate in the browser when I do have one available.  The 'optional' setting is documented to not work properly with all browsers, so I think this unfortunate behavior is expected.

We should add the ability to return a different HTTP response message when we have a problem with client certificate authentication in mod_ssl.  This would make mod_ssl much more useful for supporting websites that want to use client certificate authentication, especially those that want to allow failover to additional authentication methods.  If we are concerned about this changing the behavior here from a backwards compatibility perspective, adding a new directive that allows the response behavior to be controlled could be an approach that would be acceptable.

Note You need to log in before you can comment on or make changes to this bug.