Client Certificate Authentication & Browser Pitfalls

Client Certificate Authentication & Browser Pitfalls (W4I)

Convener: Vivek Gupta

Notes-taker(s): Vivek Gupta

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

We are providing an Authentication service for our customer's all internal applications (about 500). The service provide various type authentications e.g. Username/Password, Kerberos, RSA, Certificate.

Certificate Authentication is quite different than other type of authentications because, the authentication process starts during the SSL/TLS connection establishment.

We found that when a user wants to switch to Certificate authentication after the SSL/TLS connection establishment, the browsers behave differently.

SSL/TLS renegotiation can be used for getting the client certificate if you want to perform the Certificate authentication after the SSL/TLS connection establishment.

All the browsers cache the SSL/TLS connection for some time. During that time, if you perform the SSL/TLS Renegotiation and ask for client certificate, the browsers do not provide the client certificate.

We need to close the SSL connection at the browser end and then re-establish the new SSL connection to the same server and ask for then client certificate.

The API to close the connections varies from Browser to browser. In Firefox, you use window.crypto.close() to close the connection. In IE, you have to use documen.execCommand("ClearAuthenticationCache") to close SSL connection. IE however deletes all the session cookies also with this command. So this command in IE does more harm than just closing the connection.

Browser like Chrome, Opera, and Safari do not have any APIs to close SSL connection. Safari infact doesn't support SSL/TLS renegotiation.

One way to resolve this situation is to off-load the Client certificate authentication to another Server instance (or URL) that is protected by Client Certificate authentication. This way the browser will create whole new SSL connection to a new URL and provide client certificate. The problem with this approach is maintenance cost and a whole new proprietary API/System to handle this certificate authentication.

It will be nice to have standard and same Crypto functions available in browser. I guess W3c crypto is trying to resolve this issue.