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?
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.
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.
As I understand it, there are numerous problems with using client certificates in practice. Here are some of the issues I've heard:
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
