Select client certificate dialog for x509 authentication

Question

I have an application written in Java + Spring running on Wildfly 10. I have set up basic x509 authentication using my RootCA and client certificates.

Based on client's certificate CN I can handle multiple user roles.

What I would like to achieve is some way, how to dynamically select client certificate which should be used. There is a dialog which is shown while accessing the https (this is a system dialog - from firefox). But this dialog is shown just once, then even after logout the dialog is not shown again and last client certificate is selected automatically.

Even when I unselect remember this decision, this certificate will be selected again.

It is rejecting to upload screenshot here, so there is url: https://imgur.com/a/PklHR

Answer 1

TL;DR: There is (currently) no ironclad way to force reauthentication using new client certificates from the server side, however, it can be done manually by the user in most cases.

As mentioned in the bugs I listed earlier, this behavior occurs due to Firefox and Chrome remembering the SSL state, which includes any client certificates used for authentication. The user can clear this cache manually by restarting the browser, or clearing active logins. While there is still no method to remotely trigger the clearing of the browser's SSL cache, there have been several creative methods to work around this problem.

One method to force the browser to ask for client certificates again would be to force TLS renegotiation, which would involve exchanging TLS Client Hello and Server Hello messages again. As an example, here is a case where Apache used TLS renegotiation to "upgrade" the connection when the user requested a resource requiring client certificates.

Due to my unfamiliarity with the Spring Framework, I don't know exactly how this would be accomplished in your specific case, however, I'm fairly certain it can be done in Java. You might take a look at the TLS 1.2 RFC section on the Hello Request message, which would prompt the client to respond with a Client Hello message, effectively restarting the handshake.

At this point however, if the client had already authenticated with a certificate, the browser would still remember and send it anyway. The server may be able to force the client to present a different certificate by pruning the accepted CA list it sends in the certificate_authorities section of it's Certificate Request message. This, will obviously not work if the new certificate you want to use is issued by the same CA as the old certificate.

I've also seen cases where custom logic was used to fail the SSL connection if the same certificate was presented again, but that doesn't resolve the browser's certificate memory issue. It just prevents the user from using the site again until either restarting or clearing the active logins, as mentioned above. Hope that helps.