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.
Im curious for Google's reasoning.
this post was submitted on 18 May 2025
101 points (98.1% liked)
Linux
8559 readers
429 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
This honestly is basic security in a number of ways. Separate PKI for every use-case is the standard. Eggs in on ebasket, yadablahwut.
The actual change shouldn't take long for LE to actually do, it's the implication of the thing though. I'd love to see a different tool for enrolling TLS services, or at least a better flow than the existing one.
This honestly is basic security in a number of ways. Separate PKI for every use-case is the standard.
So what is the PKI for client certificate authentication?
How do you mean?
What is the public key infrastructure for obtaining client authentication certificates that have a path of trust back to a root CA? You said separate PKI for every use case, so what is the intended PKI for this use case, if not CAs like LetsEncrypt?
The PKI in this context is just the platform that is managing the issuing and revocation of certificates not the underlying algorithms being used, if that's what you're asking.
So the LE systems that accept, check, and approve the initial request, and then handle the revocation when needed. Using a different stack for different use-cases is a best practice, simply because if one is compromised, it doesn't affect the other. In this case it's just splitting the standard LE web services and TLD services into two different stacks that do the same thing, but I assume would have isolated CAs, one for each use-case. This would mean a new root CA needs to be deployed out into the world in order to verify the TLS side, but maybe I'm missing something.
but maybe I’m missing something.
Yes, FTA:
May 13, 2026: the tlsclient ACME profile will no longer be available and no further certificates with the Client Authentication EKU will be issued.
...
Once this is completed, Let’s Encrypt will switch to issuing with new intermediate Certificate Authorities which also do not contain the TLS Client Authentication EKU.
...
After this change is complete, only TLS Server Authentication will be available from Let’s Encrypt.
Yes, that's the same thing. Removing it from one place, and just adding it to another. No big deal.
I honestly don't think many people were even using this feature compared to SSL certs. Anyone using TLS everywhere already has their own cert manager workflow, othey'd be using another system to do it ala k8s, or they'd be doing it at the network fabric instead of per-service. I can't think of many use-cases where regular users of LE would have a TLS-enabled public service they would need other random users to trust. I'm sure there's some, but nowhere on the scale of their SSL users.
Yes, that’s the same thing. Removing it from one place, and just adding it to another.
Adding it where?
I've read a lot of outcry about this wrt self-hosted mail servers.
Some say this is fatal, some say it has no effect. Both sides seem to have valid technical arguments. It would be nice to understand the effects better.