RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1247758 - [RFE] Gracefully handle client certificate errors when using 'SSLVerifyClient require'
Summary: [RFE] Gracefully handle client certificate errors when using 'SSLVerifyClient...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: httpd
Version: 8.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.4
Assignee: Luboš Uhliarik
QA Contact: RHEL Stacks Subsystem QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-28 19:34 UTC by Nathan Kinder
Modified: 2023-09-14 03:02 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-01 03:02:44 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Nathan Kinder 2015-07-28 19:34:04 UTC 
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
  SSLRequireSSL
  SSLVerifyClient require
  SSLUserName SSL_CLIENT_CERT
  LookupUserByCertificate On
  ErrorDocument 403 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Certificate authentication did not pass.</body></html>'
</Location>
--------------------------------------------------------

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

--------------------------------------------------------
192.168.128.101 - - [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.
Comment 11 RHEL Program Management 2020-11-01 03:02:44 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 12 Red Hat Bugzilla 2023-09-14 03:02:42 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.