Client browser certificates seem to be a nice way to protect sites from intruders - it is impossible to guess and should be harder to steal. Of course, they do not solve all the problems, but they add security.

However, I didn't encounter any public sites using them. Are there sites that use them? Is there some flaw in them that precludes the usage even when security is important or some other reason why there's so little usage of them?

  • 6
    StartSSL.com uses them — instead of creating a name/password, it generates a client cert which is used for login [and must be backed up by the user or else they lose account access!]. At least in the Chrome browser it was a surprisingly pleasant experience. This is the only example I've personally encountered to date.
    – natevw
    Commented Oct 22, 2013 at 21:52
  • 2
    I do, for the moderators on a site I operate.
    – forest
    Commented Mar 22, 2018 at 0:35

12 Answers 12


Client side certificated just haven't had a good enough cost/benefit tradeoff. They are very confusing to users so support costs go up. And they are still just bits and thus "something you know" and are vulnerable to a range of software attacks on the browser, the distribution scheme, phishing etc.

Hardware token schemes (two-factor authn) are better for good authn. Single-sign-on (SSO) schemes, potentially federated, and potentially backed by hardware tokens, solve more issues and are easier to deploy.

Managing a lot of certificates would be far more complicated for a user than the current thorny multiple-password issue, and browsers don't offer good support for selecting the right certificate. And if a user uses a single cert for lots of sites, then there are privacy issues since use of the certificate identifies the user.

Over the decades, a lot of us have thought that the age of end-user PK-crypto was just around the corner, especially those like me enamored of the beauty of RSA. It just turns out that the way it has evolved, the help desk and development costs and subtleties and complexities and legal entanglements of real-world PKI keep eating up the benefits.

Equipment seems more expensive than bits, but not if the bits don't do the job, or effective use of them eats up productivity.

  • 1
    Almost nobody's using 2-factor auth either, but there at least I see the reason - distributing physical tokens has costs. Certs cost nothing though.
    – StasM
    Commented Jan 3, 2011 at 21:34
  • 2
    Some are turning to software 2-factor auth, like Google's password reset sends a OTP to your phone when you attempt to log in from a computer that it doesn't recognize, and others are exploring the possibility to use a smartphone instead of a hardware token (to reduce costs). Commented Feb 20, 2015 at 0:39

I use browser certificates for a handful of sites, but as you said mostly not public sites.

The main difficulty in Client Side Certificates is distributing them. That is, how can I securely give you the "all-powerful" certificate that will grant you access to my system, if I don't know you?
Corporate systems are easier, of course, as are systems open to a small circle of partners. But key distribution is always a difficult puzzle to solve. It's much harder than just sharing a password between two parties, considering the private key aspects, and the cert protection, ....

There actually are solutions to this, of course, and I even use one for a "public" website. (It happens to be in the identity business, so it's worth the overhead to them...). That solution is based on primary authentication via password, and after I'm fully authenticated I have the option to download my certificate - assuming I know what to do with it.
Not much better, since the password channel is still open... but that at least gives me the possiblity of changing the password to something impossible and unusable, and have only the CSC....

But this is not trivial, and kinda complex to implement correctly. Distribution would still bug most users.

  • 1
    It doesn't have to be all-powerful - you can still ask for a password, for example. You can grant access to low-security areas with password alone and to high-security ones only with cert+password. That's just one model, of course.
    – StasM
    Commented Jan 3, 2011 at 7:57
  • @StasM - Well, yes, but again that just raises the complexity of implementation. And if you're doing that, why bother?
    – AviD
    Commented Jan 3, 2011 at 8:53

As I understand it, there are numerous problems with using client certificates in practice. Here are some of the issues I've heard:

  1. Getting client certs. It is a pain for users to initially get a client cert in the first place. Obviously, sites don't want to create unnecessary hurdles that users have to jump through before they can even begin to use their site. (Even having the site generate the client cert and provide it to the client is not a familiar operation for a user -- not to mention that it has security problems, since ideally, only the client should know the client's private key.) Modern browsers provide ways to create or import private keys and client certs, but the user experience is horrible.

  2. I've heard that some servers apparently don't support client certs well (e.g., http://osdir.com/ml/encryption.cryptlib/2005-09/msg00000.html).

  3. Mobility is a problem. Despite all their problems, passwords are very portable; client certs are not. Even if the client manages to generate a private key and get a client cert for it, if they want to start using a second computer, they'll have to do a complicated and confusing dance to transfer the private key and cert over to the second computer. If their first computer dies (or suffers a hard disk failure) and they have to re-install their OS or buy a new computer, and if the client hasn't backed up their private key, they will have no way to put their private key and cert onto their new computer; they're pretty screwed. A site can create a backup method of authentication so users who lost their private key can generate and submit a new private key, but this backup method of authentication can easily become the weakest link in the chain. It doesn't matter how strong your primary method of authentication is, if your backup method is easily defeated.

  4. It's not clear whether there is sufficient support from browsers for client certs. I don't know if all the various browsers out there (including mobile browsers) adequately support client certs.

  5. The PKI model is pretty well broken anyway. The assumption was that the CA would verify the identity of the user (e.g., their real name) before giving them a client cert, and the protocol was designed around this assumption. However today's CAs don't really verify identity. This creates a mismatch between the design assumptions and the reality.

  6. Client certs create privacy risks for users. In some browsers, they enable tracking of users across domains. (All browsers ensure that cookies carefully defend against this threat: only the domain that set the cookie can read it. However, browsers don't incorporate similar protections for SSL client certs.) I don't know if modern browsers have effectively addressed this problem, but it's an area where client certs are relatively immature, as far as I know.

  7. There are annoying technical problems, if the client generates and signs its own client cert. According to the TLS protocol, the server is supposed to first ask for a list of CAs that it's willing to accept; the client subsequently responds with a client cert issued by that CA, if it has one. (Note that this happens before the client has sent a HTTP request, any HTTP cookies, a username, or any other identifying information.) This means that, if you want to use client-issued (self-signed) client certs, then the server has to know the name of the CA that the client is using before the client even authenticates or identifies itself. That's tricky.

  8. Finally, the cherry on the pie: client certs don't solve the phishing problem. They prevent theft of the client's private key, but not other personal information. Bad guys can still set up a fake bank site (which discards any client certs sent to it). The phishing site won't learn the user's private key, but if the user thinks they've connected to the real bank site, they may type in their bank account number, SSN, PIN, etc., revealing that information to the attacker.

All of these translate to poor usability and increased support costs (e.g., helpdesk calls). In short, you can use client certs, at least in principle; it's just that, in practice, doing so is inconvenient for everyone and usability sucks.

More fundamentally, there is a chicken-and-egg problem: until many sites start to use client certs, browser manufacturers will not place a high priority on making client certs usable; and until browsers make client certs usable, sites won't adopt them. To put it another way, if we want to use client certs to solve the general authentication problem, we have to both convince all browser manufacturers to make major changes to browsers, and convince sites to adopt new technology. No benefits accrue to anyone until all these parties make coordinated changes. That's a huge hurdle to adoption.

There are better solutions for secure authentication on the web, involving HTTPS, secure persistent cookies, and email-based recovery. However that's getting beyond the scope of your question.

Last comment: The fundamental challenge in secure web authentication is usability, usability, usability. Making systems that work well for users -- and are secure, when used as ordinary users are likely to use them -- is very challenging, and is all that matters. Crypto is only a tiny piece of this problem.

  • 1
    The <keygen> element documented in the HTML5 spec (and supported by many browsers before) is a fairly usable way to generate+install secure keypairs on the client. Experience in Chrome was pretty seamless, at least, and I would hope FF as well.
    – natevw
    Commented Oct 22, 2013 at 21:57
  • 2
    The <keygen> element is deprecated in HTML5, according to W3C, WHATWG and MDN and has been disabled in Chrome as of version 49. Commented Apr 21, 2016 at 13:33

I think that mainly they aren't used because the average person (i.e., not you since you're asking this question) can't fathom their usage. There are a few commercial sites that use them but they're usually very special purpose or for automation. For example, Oracle uses client certificates to validate end users with valid support contracts for package updates. But even with highly technical users getting the proper key exchange can be challenging.

All of that being said, I use client certs to protect portions of my websites that I leave open to the public, and I think they are fantastic.

  • 1
    I see your point, but that can be all done in the browser... The user should just download/double-click the file and that's it. Browser extensions are very complex things but were made seamless to the user, for example.
    – StasM
    Commented Jan 3, 2011 at 7:41
  • 2
    All of that "in the browser" stuff takes quite a lot of code on the server side to implement.
    – bahamat
    Commented Jan 3, 2011 at 8:23

The Estonian National Identity Card is a smart card which contains a client certificate embedded on it. You can get smart card readers for it and use it at home to apply for government services or authenticate to the main Estonian banks. All the user sees is a card/pin prompt and next thing they know they're authenticated.


On of our client uses client certs to authenticate touch-screen kiosks systems. The systems are distributed to dealers, and each gets their CA root cert installed as well as a unique client cert.

The client cert is used to authenticate the kiosk system to the webserver, without requiring the dealer to perform manual authentication on startup of the device. If an individual system needs to be shut out it's easy for our client to revoke the cert.

  • See, here distribution is taken care of, it's trivial compared to delivering the kiosks... Though I would question the security of this system, after all anonymous users can access the kiosk directly - and possibly "borrow" the cert?
    – AviD
    Commented Jan 4, 2011 at 11:38
  • That's true, AviD. Of course the kiosk should be properly hardened to prevent that kind of access. If a cert is stolen, it can be revoked individually by the CA since that kiosk should be considered compromised. In this case the information on the webserver is not critical enough to require additional measures, so the client-cert is basically an alternative to a password. Commented Feb 18, 2014 at 9:21

The French Minister of the Economy published a public website for tax management (on-line tax payment, information on deadlines, forms downloading...) which uses SSL certificate for user authentication. The user registration (this role is attributed to a Registration Authority in PKI) which has been pointed by AviD♦ to be the main difficulty in a such project, has been solved since this administration has already enough information to identify the taxpayers.

  • The problem isnt just the initial identification, its distribution of certificates.
    – AviD
    Commented Jan 3, 2011 at 18:40
  • Yes I was unclear. I meant that the administration is able to to ensure that the identity of certificate requestor (i.e. the private holder) matches and the declared identity. Technically speaking there is a unique private number on the tax payment receipt (of the previous year) used as shared secret during the certificate generation process.
    – Jcs
    Commented Jan 3, 2011 at 20:52
  • 1
    Really? they consider this "unique tax payment number" to be a protected secret? Humph... Well, I guess its not worse than U.S. considering SSN to be a form of secure identification...
    – AviD
    Commented Jan 4, 2011 at 11:36

A variation of browser certificates are used in the HTTP/S based ActiveSync protocol.

Several email administrators use certificates to authenticate a mobile devices so that mobile email doesn't suddenly stop working when the user changes their password.


Client certificates have all the nicest quality for authentication. But because of a chicken and egg problem users have no reason to acquire a serious certificate (costs money and time because the delivery should be a face to face operation) because few sites use them, and site administrators have no reason to actively support them since their users generally have no certificate.

Corporate systems are different because if security requirement are high enough, the global cost of a PKI infrastructure is perfectly accectable.

But when you remember what is the real total cost and procedure for a national identity card (not speaking of a passport), adding a certificate established by a national administration would not add much and would nicely solve all authentication questions with institutional sites like administrations, banks, ... Of course I would not use that for merchant sites or little controlled forums


I work developing a site which offers smart card authentication. The user connects a USB card reader, goes to the site, and when he wants to log in, he inserts the card and supplies a PIN. The issue is that the system uses a Java Applet, and these applets are no longer supported by Chrome or by MS Edge. New middleware is being developed which does not use Java Applets, and it's a race against time as we can see all major browsers stopping Java Applets from interacting with hardware on your PC in the future.


If we expand on the OP scope to go past the browser. Client certificates can also be used in the non-browser context. For example Docker uses TLS and client certificates to secure their connections between a remote docker client to their daemons.

This would still need to be managed though, but it does not need to go through a full fledged CA, it can be an internal company CA to manage all the certificates used by the machines.


The HTML element exists to facilitate generation of key material, and submission of the public key as part of an HTML form. This mechanism is designed for use with Web-based certificate management systems. It is expected that the element will be used in an HTML form along with other information needed to construct a certificate request, and that the result of the process will be a signed certificate


  • 1
    As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Mar 20, 2022 at 21:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .