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 1248191 - Client-certificate prompting is inconsistent
Summary: Client-certificate prompting is inconsistent
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firefox
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Martin Stransky
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-29 20:03 UTC by Nathan Kinder
Modified: 2019-08-23 06:22 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-23 06:22:27 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Nathan Kinder 2015-07-29 20:03:53 UTC 
I am using Firefox 38 with the OpenSC PKCS11 module to perform client certificate authentication against an Apache httpd server.  The httpd configuration has client-certificate authentication as "optional", which allows the web application to support falling back to alternate authentication methods if the user does not have a certificate or if there is some other certificate related problem.

It seems that Firefox caches the fact that a site asked for a
client-certificate and one was not present for the duration of the
Firefox process.  If I start a new Firefox process and access httpd that
is using 'SSLVerifyClient optional', I'll be prompted to provide my
certificate.  The first time I access that site without a certificate
present, Firefox remembers it and will never prompt me to provide a
certificate again for that site unless I restart the browser.

I've recorded a video showing this behavior, which is consistent.  In
the video, I'll first start a fresh browser process, then will access
the site with no certificate available.  The ErrorDocument setting will
redirect me to the form as expected.  I then insert my smart card and
try to access the site again.  I'm never prompted, and it redirects me
to the form.

I then restart the browser, but this time I insert my smart card before
accessing the site.  I'm prompted to unlock my card and select a
certificate, and authentication is successful.  I then log out of the
web application and remove my smart card, then access it again.  The
fallback to form auth works.  If I insert the card again, I'm not
prompted for the certificate and it falls back to the form.

The video showing this behavior is located here:

  https://nkinder.fedorapeople.org/smartcard-fallback-fail.webm

I am not yet sure if this is a smart card specific issue, or if it would also occur using certificates stored in the NSS database used by Firefox.
Comment 3 Nathan Kinder 2015-07-29 20:18:04 UTC 
The relevent mod_ssl configuration that I'm using is as follows:

<Location /users/extlogin>
  SSLRequireSSL
  SSLVerifyClient optional
  Require ssl-verify-client
  ErrorDocument 401 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Certificate authentication did not pass.</body></html>'
  ErrorDocument 403 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Certificate authentication did not pass.</body></html>'
</Location>
Comment 4 Nathan Kinder 2015-07-29 21:18:43 UTC 
I see this problem when using certificates in the NSS database, so it's not a smart card specific problem. I've recorded two videos to demonstrate the problem.

In the first video, I already have a certificate loaded in the NSS database when I start Firefox.  I access the site and get prompted for my certificate.  In this case, I choose "cancel" and am sure to tell Firefox to not remember this decision.  It falls back to form-based auth as I expect it to.  I then attempt to access the site again, but I'm never prompted for my certificate this time.  I would not expect Firefox to remember that I clicked "cancel".  I then restart Firefox and access the site, and it prompts me for my certificate again.  This time I select my certificate and click "OK" (again telling it to not remember this decision), which authenticates me successfully.  I log out and access the site again, and it lets me in immediately via client certificate auth with no prompt, despite the fact that it should not remember this decision.  Here is the video for this:

  https://nkinder.fedorapeople.org/softcert1.webm

In the second video, I have no certificates loaded in the NSS database when I start Firefox.  I access the site, and it gets redirected to the login form as expected.  I then import a client certificate and key and attempt to access the site again.  Despite the fact that I have a certificate available now, I'm never prompted for it.  If I restart Firefox and access the site again, I'm prompted for my certificate and can log in as expected.  Here is the video for this:

  https://nkinder.fedorapeople.org/softcert2.webm

The behavior in both of these cases seems wrong.
Comment 5 Kai Engert (:kaie) (inactive account) 2015-07-31 14:14:43 UTC 
Nathan, we need to consider the TLS session, with potentially a TLS session cache, and the isolation of TLS from the web application.

Modern browsers combined with HTTP 1.1 keep sockets open to improve performance.

At the same you connected first, a TLS handshake was performed, which included the client cert authentication. Once that TLS session had been established, it was very likely kept open, because there was no need to close it.

The requirement to present a client certificate only happens when a TLS handshake happens. But in your example, there was no need for a new TLS handshake from the browser's perspective.

In addition to the TLS handshake, you have your web application that runs inside the TLS layering. The web application runs after the TLS negotiation has completed.

How does the web application know that authentication has already taken place?

I know how that worked with the apache web server in the past, and I suspect in your environment it works similarly.

If the web application code is aware that TLS client authentication is a possible authentication mechanism, then your web code probably queries the web server for the status. In apache, a set of environment variables were used, that the web code could query.

If the webserver saw that TLS authentication has completed (the client presented a certificate that was accepted according to the webserver configuration), then the webserver set environment variables, that will be effective for the scripts that are executed for this page.

(The webserver might theoretically use other means to signal the presence of completed TLS authentication to the web page scripts, I don't know if any different ways to signal that are nowadays being used, but for simplication, I'll continue to talk about environment variables.)

This means, if you navigate to the page again, and the browser continues to use the existing TLS session with the already completed TLS client authentication, then the webserver will continue to set the environment variables for the page scripts. That means, the next time you load your web page, the web page will still find information that authentication is in place.

Now, what happens when you click "sign out" inside your web application?

I don't know what your web application does. I suspect that it uses some sort of session cookies, or session form values, that are being carried along while you use the web application.

Because your application also supports form authentication, I assume your web scripts can look for either the environment variables that signal completed TLS authentication, or look for valid user/password credentials provided in form values. Once one or the other check succeeds, you probably set a session cookie.

At the time you click "sign out", I guess only the session cookie will be deleted. But when you load again, you'll still see the TLS authentication is present, and will continue to treat the session as "signed in".

In order to get the effect that you expect, you'd have to find a way to influence the TLS session from inside your web script code. I don't know if that's possible. It would require that your server scripting environment offered a mechanism that the web script code can use to signal the server to invalidate the current TLS session and require it to perform a new TLS handshake on the next interaction for this server.
Comment 6 Kai Engert (:kaie) (inactive account) 2015-07-31 14:25:54 UTC 
The TLS session also explains the behavior in your second video.

Because your server has already allowed the TLS session to complete without presenting a client certificate, the TLS session is still alive after you sign out from the web application. The TLS session is still used when you load the page again (the socket is still alive and will continue to be used).

You'd have to find a way to force the server or the browser to invalidate the current TLS session. If you had a way to do that, the next time you load the page a new TLS handshake would happen, and the server would again ask the browser for the optional client cert.
Comment 7 Joe Orton 2015-08-25 07:28:02 UTC 
It should be technically possible to expose a hook into mod_ssl to flush the session cache, although threading such hooks through to (various) application layers is difficult.

But since the trigger here is client-side, it is the insertion of the smart-card which should trigger the browser to discard the TLS session, wouldn't the correct solution be client-side?

If Firefox sees a smartcard insertion and a certificate becomes available which already has an association with a site to which there is an kept-alive TLS connection, couldn't it terminate the connection and flush the cached session entry?  (At least in theory?)
Comment 8 Martin Stransky 2019-08-23 06:22:27 UTC 
Sorry we don't have a fix for that.
Note You need to log in before you can comment on or make changes to this bug.