5 ms·

Why are client certs not more popular? They seem like a pretty clean abstraction compared to all the API keys and JWT tokens floating around.

SoftTalker 1y ago
Users can’t manage them and nobody has come up with software that can. I have worked with PhDs who can’t even manage ssh keys.
- notpushkin 1y ago
  Tooling problem, as always.
- thayne 1y ago
  If only there was a standard protocol for trading credentials and a CSR or equivalent for a signed certificate. Kind of like ACME for client certs that uses login credentials instead of dns. And maybe then browser support for logging in using that to create a client cert instead of setting a cookie.
  - et1337 1y ago
    In case anyone misses the joke, I think this is what passkeys are.
- nirui 1y ago
  > PhDs who can’t even Not a good point. I've experienced PhDs who can't (even, some may add) write shell script. Maybe they just hate the syntax, or specifically the $ symbol, maybe both. But, they did do fine job otherwise and has successfully replaced me, a person who can write a bit shell script :(
  - SoftTalker 1y ago
    The point is that even very smart people in technical fields can just be bad at/not care/willfully refuse to use stuff like this. It's a non-starter for a general-purpose authentication mechanism if the user has to understand concepts such as "private" and "publc" keys. Even 2FA solutions like Google Authenticator are simple enough that you just need to scan a QR code but very few people use them and even fewer actually bother to print/save the backup emergency codes for use if they lose access to their auth device. People can (sometimes) handle passwords, and an emailed reset link if they forget.
edelbitter 1y ago
A really clean abstraction, but not any more once you try to correctly use it over traditional SSL toolkit APIs (e.g. CVE-2025-23419) or in conjunction with any of the the more interesting web scenarios (HTTP/3, rel="preconnect", CORS, CDNs..)
kmeisthax 1y ago
Because if you use a token, you don't have to pay for a certificate. TLS PKI is designed to do one thing and one thing only: bind a keypair to a domain name. This is great for authenticating servers and terrible for authenticating clients. The question that a server wants to ask of a client is not "is this server authorized to serve this domain name", it's "is this a key I authorized to access this resource". The latter question is not just "inappropriate for the TLS PKI", it's inappropriate for any public PKI[0]. The only appropriate PKI for client authentication is for each server to run its own private client PKI. If you insist on using client certs that are signed by the TLS PKI, then everyone who wants to connect to your API needs to buy a cert from a third-party that will provide no additional security for you or them, compared to the moral equivalent of ~/.ssh/authorized_hosts. If you have a particularly complicated server setup, then rolling your own client root would at least give you centralized issuance and revocation control. Ok, let's say you set up your API to use client certs. You've just massively complicated the most common use case for your API: pinging it from a web browser running your JavaScript. There is no API in the web standard for a random website to enroll a client cert in your browser, and you can't specify a client cert in HTTP fetch or anything. Client certs are instead managed with the same terrible UX as the root cert store, which is deliberately obfuscated for fairly obvious "keeping the user from hurting themselves" reasons. So now you have to give your users a cert file and guide them through a bunch of nonsense to install the cert. Furthermore, if any other website does this, now all your users have to pick which identity they want to use whenever they go to a website that wants client certs. They aren't bound to specific domain names like, say, password manager items can be. The only way you could avoid this... is by using a public client cert PKI, which means now all your users need to pay $$$ to a third party just to login to your website, which is a terrible idea. Tokens, passwords, and passkeys avoid all of this nonsense and give you exactly what you want: client authentication, nothing more or less. TLS client certs are the sort of thing an engineer cooks up because it sounds nice and symmetrical. Oh, servers have certs, why can't clients have certs? But in practice certs solve the wrong problem and carry too much baggage for clients. [0] Public public key infrastructure
- jeroenhd 1y ago
  Nobody is making you buy certificates to authenticate to an API. You'd get a certificate file the same way you'd get an API key, from whatever portal you're gaining access from. Nobody is trusting random PKI certificates to access APIs. You also don't need any special certificates. The authentication certificates you hand out to API clients can be self-signed if that's what you want, but you probably want an internal CA of some kind to hand out/revoke certificates the same way you have some kind of API key storage. You're right that the browser UI is pretty terrible. Especially on Firefox, I should add, which decides to maintain its own key store. On all other platforms you just open the certificate and hit next a few times and you should be good. As for picking the identity to use, there are easy ways in the TLS protocol to signal what certificates qualify, and there's no way you're going to have multiple certificates signed by the same Acme Corp Ltd. with private key 0xffaabb... Websites that aren't set up correctly will prompt users for a certificate to use, but that's the other websites' fault, as well as the browser's to be honest. Client certificates work fine. They work so well, that they've been reinvented and stuffed into JWT, but now in weird JSON. Various Kubernetes overlay systems use auto-provisioned client certificates to ensure confidentiality and authentication between pods (the cloud world calls it mTLS though).
jeroenhd 1y ago
They're used in a whole bunch of industries, but not in the sexy ones. Renewal is the most important issue. Certificate stores often suck and for tokens there are various existing protocols for re-issuing expiring ones. For certificates, you're stuck doing your own thing. For local applications, UI/UX of the system supposedly in charge of certs is often absolutely terrible. I've had the displeasure of working with Java key stores and I'd rather rewrite the auth mechanism than deal with that bullshit again. The use case they would perform excellently in (centrally managed corporate networks) are also the places where you will find terrible middleboxes that will kill any protocol they don't understand. TLS client certificates could've been what passkeys are today, and they could've been what OAuth2 tokens have become, but the terrible development experience killed them off before they could bloom. I mostly blame web browsers, who didn't bother improving their UI for certificates after the day they first implemented them. Hacking OAuth2 on top of HTTPS calls is pretty easy compared to figuring out how to refresh a user certificate.
- pixl97 1y ago
  Java keystores for user clients are just a nightmare. So much if my time is used up helping customers that don't understand how they work.
  - thayne 1y ago
    It's a nightmare for using a custom CA for server certs too. You can't just add a new CA, you have to rebuild the entire keystore. And then you need to do it again every time you update the JVM, or risk missing updates to the default keystore. For some reason the keystore is required to be protected by a password, even if it doesn't contain any secret keys. The documentation for the tools that manage keystores is incomplete and sometimes out of date. The whole thing is a relic from another time and could really use some modernization.
    - jeroenhd 1y ago
      There are workarounds for that, by specifying a custom key store file and overriding the socket factory to force it to load your keys. Unfortunately, most example code for SSL socket factories just disable TLS validation entirely. So yes, your custom CA now works reliably, but unfortunately so do self-signed certificates if you're not careful. Luckily, modern Java doesn't need keystores anymore. Unfortunately, half the world seems stuck on Java 8.
lhamil64 1y ago
I've wondered this too. I have a little home server with some self hosted services, and I use a client cert on the reverse proxy to add an extra layer of security before the user can even reach the app. This works fine when accessing things via the browser, but if you want to use something like a mobile app, it almost certainly won't have support for it. It's up to every single app dev to implement support for passing in a client cert on the http requests. I suppose a VPN is really the better answer here, but that's a pain if I want to give anyone else access and is less granular.
- deleted 1y ago
  [deleted]
tptacek 1y ago
There are a lot of reasons, but Colm MacCárthaigh has some particularly interesting ones: https://news.ycombinator.com/item?id=25380301 https://news.ycombinator.com/item?id=25380301
- nmadden 1y ago
  Adding some OAuth helps a bit: https://neilmadden.blog/2022/01/20/why-the-oauth-mtls-spec-is-more-interesting-than-you-might-think/ https://neilmadden.blog/2022/01/20/why-the-oauth-mtls-spec-i... (I quite like the combo of app-level OAuth plus mTLS service mesh for backend comms).
- ymyms 1y ago
  This is a goldmine of a thread. Thanks for linking it. In it at some point, you say, "I tend to be pretty chill about little islands of mTLS, like "all the Consul clients need a cert". That, to me, solves a practical problem. I am way less chill about attempts to create coherent PKI namespaces for all the components of an app, tied together with mTLS. People should use Macaroons!" along with some earlier bits about mTLS not affording much security if you have secure requests. I've been thinking about machine identity+authorization and thus far have been thinking about it in a way where a machine would have some firm identity (like an X.509 cert) and use it to authenticate (like using mTLS) to get an authorization token. Maybe I am putting words in your mouth, but do you sort of suggest skipping the identity part and just leaning into a full capability token? In this case macaroon, that acts as identity and then acts as authorization when attenuated and used?
pabs3 1y ago
The browser UI for them has always been bad, and has gotten worse over time.
dingaling 1y ago
> Why are client certs not more popular? They needed a cool name. I present: Passkeys
- silon42 1y ago
  Seems inferior and proprietary smelling.
devman0 1y ago
Client certs are strongly bound to the TLS handshake, and thus a connection, which makes them pretty unfriendly to a lot of proxy driven architectures, where as JWTs and Cookies can pass through proxies trivially, and are bound to requests not connections. There is some work being done around standardizing pass through of client cert information through proxies, but I'm not aware of any widespread support.
- cyberpunk 1y ago
  Istio passes the real client cert in a header through to the backend which makes it not too bad to validate in such cases (nginx or whatever can quite easily do this too)
  - devman0 1y ago
    Header passthrough is nice to have, but there isn't really a standard for it for TLS, and it isn't well supported by most applications that are interested in doing mTLS. Additionally there is a trust component required between proxy and application and while can be accounted for in the architecture between the two a JWT instead passes through nicely and can be independently validated by the application.

SoftTalker 1y ago

Users can’t manage them and nobody has come up with software that can. I have worked with PhDs who can’t even manage ssh keys.

notpushkin 1y ago
Tooling problem, as always.
thayne 1y ago
If only there was a standard protocol for trading credentials and a CSR or equivalent for a signed certificate. Kind of like ACME for client certs that uses login credentials instead of dns. And maybe then browser support for logging in using that to create a client cert instead of setting a cookie.
- et1337 1y ago
  In case anyone misses the joke, I think this is what passkeys are.
nirui 1y ago
> PhDs who can’t even Not a good point. I've experienced PhDs who can't (even, some may add) write shell script. Maybe they just hate the syntax, or specifically the $ symbol, maybe both. But, they did do fine job otherwise and has successfully replaced me, a person who can write a bit shell script :(
- SoftTalker 1y ago
  The point is that even very smart people in technical fields can just be bad at/not care/willfully refuse to use stuff like this. It's a non-starter for a general-purpose authentication mechanism if the user has to understand concepts such as "private" and "publc" keys. Even 2FA solutions like Google Authenticator are simple enough that you just need to scan a QR code but very few people use them and even fewer actually bother to print/save the backup emergency codes for use if they lose access to their auth device. People can (sometimes) handle passwords, and an emailed reset link if they forget.

edelbitter 1y ago

A really clean abstraction, but not any more once you try to correctly use it over traditional SSL toolkit APIs (e.g. CVE-2025-23419) or in conjunction with any of the the more interesting web scenarios (HTTP/3, rel="preconnect", CORS, CDNs..)

kmeisthax 1y ago

Because if you use a token, you don't have to pay for a certificate. TLS PKI is designed to do one thing and one thing only: bind a keypair to a domain name. This is great for authenticating servers and terrible for authenticating clients. The question that a server wants to ask of a client is not "is this server authorized to serve this domain name", it's "is this a key I authorized to access this resource". The latter question is not just "inappropriate for the TLS PKI", it's inappropriate for any public PKI[0]. The only appropriate PKI for client authentication is for each server to run its own private client PKI. If you insist on using client certs that are signed by the TLS PKI, then everyone who wants to connect to your API needs to buy a cert from a third-party that will provide no additional security for you or them, compared to the moral equivalent of ~/.ssh/authorized_hosts. If you have a particularly complicated server setup, then rolling your own client root would at least give you centralized issuance and revocation control. Ok, let's say you set up your API to use client certs. You've just massively complicated the most common use case for your API: pinging it from a web browser running your JavaScript. There is no API in the web standard for a random website to enroll a client cert in your browser, and you can't specify a client cert in HTTP fetch or anything. Client certs are instead managed with the same terrible UX as the root cert store, which is deliberately obfuscated for fairly obvious "keeping the user from hurting themselves" reasons. So now you have to give your users a cert file and guide them through a bunch of nonsense to install the cert. Furthermore, if any other website does this, now all your users have to pick which identity they want to use whenever they go to a website that wants client certs. They aren't bound to specific domain names like, say, password manager items can be. The only way you could avoid this... is by using a public client cert PKI, which means now all your users need to pay $$$ to a third party just to login to your website, which is a terrible idea. Tokens, passwords, and passkeys avoid all of this nonsense and give you exactly what you want: client authentication, nothing more or less. TLS client certs are the sort of thing an engineer cooks up because it sounds nice and symmetrical. Oh, servers have certs, why can't clients have certs? But in practice certs solve the wrong problem and carry too much baggage for clients. [0] Public public key infrastructure

jeroenhd 1y ago
Nobody is making you buy certificates to authenticate to an API. You'd get a certificate file the same way you'd get an API key, from whatever portal you're gaining access from. Nobody is trusting random PKI certificates to access APIs. You also don't need any special certificates. The authentication certificates you hand out to API clients can be self-signed if that's what you want, but you probably want an internal CA of some kind to hand out/revoke certificates the same way you have some kind of API key storage. You're right that the browser UI is pretty terrible. Especially on Firefox, I should add, which decides to maintain its own key store. On all other platforms you just open the certificate and hit next a few times and you should be good. As for picking the identity to use, there are easy ways in the TLS protocol to signal what certificates qualify, and there's no way you're going to have multiple certificates signed by the same Acme Corp Ltd. with private key 0xffaabb... Websites that aren't set up correctly will prompt users for a certificate to use, but that's the other websites' fault, as well as the browser's to be honest. Client certificates work fine. They work so well, that they've been reinvented and stuffed into JWT, but now in weird JSON. Various Kubernetes overlay systems use auto-provisioned client certificates to ensure confidentiality and authentication between pods (the cloud world calls it mTLS though).

jeroenhd 1y ago

They're used in a whole bunch of industries, but not in the sexy ones. Renewal is the most important issue. Certificate stores often suck and for tokens there are various existing protocols for re-issuing expiring ones. For certificates, you're stuck doing your own thing. For local applications, UI/UX of the system supposedly in charge of certs is often absolutely terrible. I've had the displeasure of working with Java key stores and I'd rather rewrite the auth mechanism than deal with that bullshit again. The use case they would perform excellently in (centrally managed corporate networks) are also the places where you will find terrible middleboxes that will kill any protocol they don't understand. TLS client certificates could've been what passkeys are today, and they could've been what OAuth2 tokens have become, but the terrible development experience killed them off before they could bloom. I mostly blame web browsers, who didn't bother improving their UI for certificates after the day they first implemented them. Hacking OAuth2 on top of HTTPS calls is pretty easy compared to figuring out how to refresh a user certificate.

pixl97 1y ago
Java keystores for user clients are just a nightmare. So much if my time is used up helping customers that don't understand how they work.
- thayne 1y ago
  It's a nightmare for using a custom CA for server certs too. You can't just add a new CA, you have to rebuild the entire keystore. And then you need to do it again every time you update the JVM, or risk missing updates to the default keystore. For some reason the keystore is required to be protected by a password, even if it doesn't contain any secret keys. The documentation for the tools that manage keystores is incomplete and sometimes out of date. The whole thing is a relic from another time and could really use some modernization.
  - jeroenhd 1y ago
    There are workarounds for that, by specifying a custom key store file and overriding the socket factory to force it to load your keys. Unfortunately, most example code for SSL socket factories just disable TLS validation entirely. So yes, your custom CA now works reliably, but unfortunately so do self-signed certificates if you're not careful. Luckily, modern Java doesn't need keystores anymore. Unfortunately, half the world seems stuck on Java 8.

lhamil64 1y ago

I've wondered this too. I have a little home server with some self hosted services, and I use a client cert on the reverse proxy to add an extra layer of security before the user can even reach the app. This works fine when accessing things via the browser, but if you want to use something like a mobile app, it almost certainly won't have support for it. It's up to every single app dev to implement support for passing in a client cert on the http requests. I suppose a VPN is really the better answer here, but that's a pain if I want to give anyone else access and is less granular.

deleted 1y ago
[deleted]

tptacek 1y ago

There are a lot of reasons, but Colm MacCárthaigh has some particularly interesting ones: https://news.ycombinator.com/item?id=25380301 https://news.ycombinator.com/item?id=25380301

nmadden 1y ago
Adding some OAuth helps a bit: https://neilmadden.blog/2022/01/20/why-the-oauth-mtls-spec-is-more-interesting-than-you-might-think/ https://neilmadden.blog/2022/01/20/why-the-oauth-mtls-spec-i... (I quite like the combo of app-level OAuth plus mTLS service mesh for backend comms).
ymyms 1y ago
This is a goldmine of a thread. Thanks for linking it. In it at some point, you say, "I tend to be pretty chill about little islands of mTLS, like "all the Consul clients need a cert". That, to me, solves a practical problem. I am way less chill about attempts to create coherent PKI namespaces for all the components of an app, tied together with mTLS. People should use Macaroons!" along with some earlier bits about mTLS not affording much security if you have secure requests. I've been thinking about machine identity+authorization and thus far have been thinking about it in a way where a machine would have some firm identity (like an X.509 cert) and use it to authenticate (like using mTLS) to get an authorization token. Maybe I am putting words in your mouth, but do you sort of suggest skipping the identity part and just leaning into a full capability token? In this case macaroon, that acts as identity and then acts as authorization when attenuated and used?

pabs3 1y ago

The browser UI for them has always been bad, and has gotten worse over time.

dingaling 1y ago

> Why are client certs not more popular? They needed a cool name. I present: Passkeys

silon42 1y ago
Seems inferior and proprietary smelling.

devman0 1y ago

Client certs are strongly bound to the TLS handshake, and thus a connection, which makes them pretty unfriendly to a lot of proxy driven architectures, where as JWTs and Cookies can pass through proxies trivially, and are bound to requests not connections. There is some work being done around standardizing pass through of client cert information through proxies, but I'm not aware of any widespread support.

cyberpunk 1y ago
Istio passes the real client cert in a header through to the backend which makes it not too bad to validate in such cases (nginx or whatever can quite easily do this too)
- devman0 1y ago
  Header passthrough is nice to have, but there isn't really a standard for it for TLS, and it isn't well supported by most applications that are interested in doing mTLS. Additionally there is a trust component required between proxy and application and while can be accounted for in the architecture between the two a JWT instead passes through nicely and can be independently validated by the application.