Why is nobody using SSL client certificates? (2008)

There&#x27;s one thing about client certs that people should be aware: They open up new security and privacy issues.<p>There have been a number of TLS protocol issues regarding client certificates that didn&#x27;t receive that much attention (Triple Handshake, SLOTH), because not that many people use clientcerts. That&#x27;s not really an argument against them, but it&#x27;s a hint that if we want to use them more widely things would probably need more scrunity in security analysis.<p>Another issue that worries me more: Client certificates can break privacy expectations. The reason is that the cert is not hidden from the traffic. This makes the traffic less privacy preserving than - let&#x27;s say - a simple password, because the password is hidden inside the TLS encryption stream, while the client certificate is not. I think users have a reasonable expectation that &quot;if I only surf HTTPS sites nobody sees any personally identifiable information from me, just the sites I&#x27;m surfing&quot;. Client certificates break this expectation.

We used to use client certificates to declare and pay our taxes online in France, about a decade ago.<p>They dropped the technology because no one savvy enough used the same computer long enough to be able to benefit from the feature more than a couple times. And you were still required to enter codes to match your forms with the administration&#x27;s data, so it felt a bit useless even at the time.

Would it be so crazy to have a standard javascript API that websites could use to store or remove certificates from the browser? With user validation of course.

There&#x27;s another advantage to SSL client certificates that this article doesn&#x27;t mention: it allows the <i>server</i> to know that the connection isn&#x27;t being intercepted by an attacker.<p>With passwords or even many 2FA solutions, an attacker can just replay them to the server, and the server has no way to know that they&#x27;re not coming directly from the client. But SSL client certificates cannot be replayed by the attacker, so if the server receives a valid connection with a SSL client certificate, it knows that it could only have come from a client with the corresponding private key.<p>There are proposals to also be able to authenticate the client in a non-replayable way with passwords (like TLS-SRP), but AFAIK they haven&#x27;t been implemented in any browser.

Is not just the UX of using the client certificate in the browser, there&#x27;s also the problem in the server: maintaining a CRL (Certificate Revocation List), or using OCSP (Online Certificate Status Protocol).<p>I&#x27;ve been forced to use it in some scenarios as client and, although I found it a little bit confusing at first, it works; but my experience on the server... is just awful to implement.

I think a more sensible approach should be similar to `authorized_keys` with `ssh`, where the server keeps a list of public keys for each user, and challenges the user to prove he&#x2F;she has the corresponding private key for authentication. TLS certificates are notoriously complicated. It may be necessary for server certificates, because the &quot;trust the key on the first connection&quot; is probably insecure when money is at stake, but I don&#x27;t see any advantages of client certificates over the ssh scheme.<p>If only it were standardized and widely supported.

Part of the problem with this approach is that it uses one single system to represent a number of claims about the client that should actually be treated separately. Identifying a user (who has history on a site) is different from identifying a hardware device, or a particular browser instance. Without knowing which particular claim the certificate is presenting it is hard to know how much to trust it. Just building a GUI does not solve this problem, and usage could create a false sense of security. If a machine is compromised is a client cert really any better than a cookie?

Spanish Tax Agency and Social Security both use SSL client certificates to authenticate citizens, and I guess that&#x27;s also true for other countries with smart cards as national id cards.<p>Works fine for authentication. Usually the problems arise when you have to sign something, which usually requires a Java Applet. That&#x27;s a real PITA.

A lot of the internal systems where I work use mutual SSL authentication instead of hard coding user accounts into API requests, it took some setting up between the various parts of the business but it&#x27;s made shifting information around securely a much simpler process. I&#x27;m not sure of how beneficial this would be for most everyday computer users, given the relative complexity getting it set up and lack of widespread knowledge about the technology and processes behind how it works, many users can grasp username+password but might struggle with SSL.

If I needed a client certificate to view my webmail it would be quite cumbersome to check my mail while borrowing a friend’s computer. A password is portable.

This sounds like a great idea. Is there a Ruby gem for Rails that would allow me to automatically create accounts for users when they visit my site, provision certificates for them, and log them in each time they visit?<p>Maybe if they use multiple computers, I could give them a certificate file that they could reupload to link the two computers as being for the same account. And a password might be available as a backup option.

A: It&#x27;s a pain in the rear.<p>We use them for device identification. It&#x27;s ok in those scenarios. But for user auth, you really need smart cards to make it work.

We tried to use Client Certs at LogNormal for API calls, but the problem is that if you enable Client Certs on an HTTP server, all requests will be asked for a cert, which, on a browser, pops up a scary &quot;Select certificate&quot; message. Since we used the same nginx boxes to front all requests, and routed them to appropriate servers on the back end, we couldn&#x27;t proceed.

I don&#x27;t understand why sites need to control this. This is a browser problem, just like remembering the password, listing them and removing them is a browser problem. Why would the website have anything to do with managing client certificates, other than bypassing browser vendors for more flexibility (and thus more problems) ?

I use client side TLS certificates for several things, but usually not in a browser.<p>This allows me to check on my server that there is no MITM between the user&#x2F;device and the server. The user may be inclined to click &quot;OK&quot; and proceed anyway when there is such a warning, but my server will refuse in that case.

I was authenticated this way with the StartSSL website if I remember correctly. While it sounds a good idea in theory, the UI part is indeed really really terrible and I had some trouble to find the right place myself so I can&#x27;t imagine for a non-technical user.

I would like to use client certificate with distributed sensors, but I can&#x27;t find a cloud provider that would accept them directly (and I would like to avoid using VMs and Linux myself, and let storage providers do it)

we use this very extensively for authentication by partners. If our partners want access to our internal technical documents etc. this is the only way to get them by identifying yourself via client certs. The bigger issue is how do we go browser neutral when generating the CSR. On IE we have to resort to ActiveX since the HTML-keygen is not implemented in IE while Firefox does, so we have to code for the two different browsers we support.

We use client certificates for our internal services.<p>Also you should know that Apple use this for its push notification system.<p>But I still think the technology is underrated.

Free SSL certs:<p><a href="https:&#x2F;&#x2F;www.startssl.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.startssl.com&#x2F;</a><p><a href="https:&#x2F;&#x2F;letsencrypt.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;letsencrypt.org&#x2F;</a>

What does this solve that cookies don&#x27;t?