Maybe someone can answer this, why are client certificates not more popular instead of something like VPN for work? I suppose even with client cert, you would still need to login, though if your computers login is already managed through AD/ldap or something and you enforce timeout logout policies you could argue that if you are logged into your machine that is good enough. Even if not, then a client cert plus a SSO token/session cookie should be good enough right?
I think it's because A) developers don't know about it, B) users don't understand it and C) the UI for it is quite terrible.
Implementing it requires some uncommon TLS configuration and a little cert work. Using it prompts uncommon native popups, slowing people down. Failure leads to weird redirects for which you can't really fall back to a login prompt because the auth happens on TLS level and a token in HTTP can't replace that.
Having to install a certificate per browser per device is kind of a pain, at least password managers solve that. There's no reason password managers couldn't also sync certificates, but the functionality simply isn't there yet.
TLS auth is definitely the cleanest solution from a technical point of view; the stateless HTTP layer doesn't need to track auth, it just gets the necessary information from the layers underneath it. Sadly, its lack of popularity means it's seen very little love from developers the last ten years.
> Failure leads to weird redirects for which you can't really fall back to a login prompt because the auth happens on TLS level and a token in HTTP can't replace that.
That's not true. nginx, for example, let's you return a custom response, which can easily be a 302 to the login page.
But I agree with all other points. On a sidenote, there's also the great option of using a CA for your client certificates while still using a normal CA for your https certificate - you don't have the worry of installing a root certificate on all clients and still have a nice, valid https connection in the browser. Unfortunately, hardly any tutorials pointed this out and used their own CA for everything instead.
> Unfortunately, hardly any tutorials pointed this out and used their own CA for everything instead.
I think this is one of the reasons so few people consider using TLS auth. There aren't many guides out there, and many of the ones that are easily accessible use a custom CA deployment that's an absolute pain to manage (custom TLS certs on websites with a custom ACME server or manual certificate generation, and so on).
Sometimes I feel like writing my own guide, but I'm not 100% confident that I'd get everything right.
I’ve been in this boat and have documented weird bugs and things that don’t work, but yet to write something about a working configuration.
I wanted to use mTLS for self hosted services and it took a while to come up with something that worked well in browsers, but apps on iOS and Android basically can’t use the certs making it fruitless.
I’ve used client certs for maybe 25 years. They are hard to configure. Most devs can’t get them working.
They also used to be expensive but I expect that’s dropped.
I’ve seen many “client certificate” solutions over the year that end up trying to do client management and crap out in many situations that are hard to fix (eg, user changes their environment and the cert is gone, now they can’t log in).
To make it easy enough to use, it ends up having all the flaws of our current sso environment. My friend had a company he was trying to start where he would automatically create and revoke client certificates for every device and session. But they were so ephemeral, they may as well have been cookies and it ended up being really cumbersome to try to keep track of certs on client devices.
VPN is easier to set up, manage, and troubleshoot. Connect to LDAP, set up groups, flip the switch, done. You'll have to use it for vendor or 3rd party access anyway, so may as well use it for the rest of the org.
