Ending TLS Client Authentication Certificate Support in 2026
34 comments
·May 18, 2025bjornsing
jeroenhd
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
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
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.
aragilar
The other challenge is proxies. When the backend that cares about client cert is behind a proxy you need to dig into the less-familiar parts of the proxy and try to work out either how to pass the certificate on or extract the information from it.
benced
Java KeyStore is so awful, I cannot believe it became a thing. It single-handedly disqualified Spinnaker (the Netflix K8s deployment thing) for me.
tptacek
There are a lot of reasons, but Colm MacCárthaigh has some particularly interesting ones:
nmadden
Adding some OAuth helps a bit: 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).
edelbitter
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..)
devman0
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.
pabs3
The browser UI for them has always been bad, and has gotten worse over time.
dingaling
> Why are client certs not more popular?
They needed a cool name. I present: Passkeys
lhamil64
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.
null
SoftTalker
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.
nirui
> 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 :(
thayne
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
In case anyone misses the joke, I think this is what passkeys are.
notpushkin
Tooling problem, as always.
CaliforniaKarl
> This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs.
flowerthoughts
> This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs. Many uses of client authentication are better served by a private certificate authority, and so Let’s Encrypt is discontinuing support for TLS Client Authentication ahead of this deadline.
Makes sense, even if inconvenient. Client auth is something LE can't provide as much validation of, compared to server certs.
Based on this: https://googlechrome.github.io/chromerootprogram/#322-pki-hi...
> To align all PKI hierarchies included in the Chrome Root Store on the principle of serving only TLS server authentication use cases, the Chrome Root Program will "phase-out" multi-purpose roots from the Chrome Root Store.
Rationale lacking.
egberts1
Aaaaaw shoot.
There goes my private WireGuard client-side TLS certificate for tunneled SSH.
Just need to bashify all the certificate creation ... again.
arccy
mkcert is pretty painless
throwaway81523
CA.pl has 9 lives.
GauntletWizard
I strongly disagree with this change. You should probably never accept client certificates signed by Let's Encrypt, but I think that it normalized something very healthy in the ecosystem: issuing one certificate that acted as both server and client certificate. I have spent surprisingly little time on making this work in the TLS ecosystems of my clients, automatically building per-service TLS certificates - allowing a robust internal infrastructure of whitelisting client services while being simple enough for devs to implement themselves.
What I really wanted to do, and have proof of concept'd with only slightly more time, is per pod certificates, identifying a service account. It looks like this is progressing in mainline - https://github.com/kubernetes/enhancements/issues/4317 - albeit very slowly.
ymyms
I am also bummed out by this change. I really like the idea of using a certificate as a single identity for a service. Things could connect to a service using normal TLS but the service could also authenticate itself to other services using mTLS.
After this change I'd need a separate certificate for the service to use for mTLS.
ChrisArchitect
more discussion: https://news.ycombinator.com/item?id=44003349
throwaway984393
[dead]
null
null
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.