If only our ancestors didn't so royally screw that up.. they took the brilliant public-key crypto and even just through the bazillion different encoding schemes and various "cert store" madness have made its use entirely untenable. The whole "the service can't know the password" problem was entirely solved and look where we stand today.
A sane certificate management UI (not hidden beneath 5+ clicks, and not full of useless distractions like "software security token" that scare users away), key escrow protocol (opt-in), transparent certificate sync (yes, has downsides, but no worse than password sync), and some JS APIs to manage certs - that can do miracles. But that won't happen.
What's good about TLS is that it's ubiquitous and you don't need anything special to deploy it. Got nginx, Apache or Caddy? Add a single directive (e.g. ssl_verify_client for nginx) and you're almost there, all the validation is already implemented, just tie the keys to your accounts system.
It is new (tiny and well thought through) API but nobody used client certs anyway, as we found out in this very thread.
Also, I think Chrome is in the process of removing support for <keygen> (and client side certificates in general?), so whatever opportunity existed for making this common has now passed.
-I had to refresh certificate once per year, which is very inconvenient, as I would go to startssl.com once per year total
- Half of the time something would go wrong with keygen in firefox and it would not remember my certificate at all. This is when you discover that all the security is simply bypassed when you send email to support.
- And worst of all, it was not very secure at all -- a malware on my computer would totally steal a certificate and keysniff the password for it. Compare with Google Authenticator or SMS auth, where I would be safe as long as my cell phone is not compromized at the same time.
Firefox still works. No idea if people use it for auth, but it is popular when requesting a certificate.