Let’s Encrypt will no longer include the “TLS Client Authentication” Extended Key Usage (EKU) in our certificates beginning in 2026. Most users who use Let’s Encrypt to secure websites won’t be affected and won’t need to take any action. However, if you use Let’s Encrypt certificates as client certificates to authenticate to a server, this change may impact you.
To minimize disruption, Let’s Encrypt will roll this change out in multiple stages, using ACME Profiles:
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.
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.
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.
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.
Im curious for Google’s reasoning.
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.
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.
Yes, FTA:
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.
Adding it where?