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…
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:
- Today: Let’s Encrypt already excludes the Client Authentication EKU on our
tlsserverACME profile. You can verify compatibility by issuing certificates with this profile now. - October 1, 2025: Let’s Encrypt will launch a new
tlsclientACME profile which will retain the TLS Client Authentication EKU. Users who need additional time to migrate can opt-in to this profile. - February 11, 2026: the default
classicACME profile will no longer contain the Client Authentication EKU. - May 13, 2026: the
tlsclientACME 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.
For some background information, all certificates include a list of intended uses, known as Extended Key Usages (EKU). Let’s Encrypt certificates have included two EKUs: TLS Server Authentication and TLS Client Authentication.
- TLS Server Authentication is used to authenticate connections to TLS Servers, like websites.
- TLS Client Authentication is used by clients to authenticate themselves to a server. This feature is not typically used on the web, and is not required on the certificates used on a website.
After this change is complete, only TLS Server Authentication will be available from Let’s Encrypt.
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.
Read the original article
Comments
By raxxorraxor 2025-05-1415:301 reply > Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs
Can someone explain the reason for these changes? Personally I am a fan of clients not doing any form of authentication and I immediately think of something unconstructive like web integrity.
By evanjrowley 2025-05-1418:511 reply Client authentication certificates are good for Mutual TLS (mTLS): https://en.m.wikipedia.org/wiki/Mutual_authentication
I think mTLS is great, but I wonder about the rationale for this change... If my front-end services are using a certificate to serve client requests, why shouldn't that same certificate also be used to authenticate them to backend services? Sure, a private CA seems like a reasonable thing to use here, but what makes PKI certs unreasonable for client authentication? Is it because we want to prevent client computer names from showing up in certificate transparency logs?
By raxxorraxor 2025-05-1514:191 reply I miswrote my comment, I mean that I am skeptical of client auth, otherwise auth is of course sensible. But I think you understood that and client auth surely can make sense.
I assume this is for x509 certs specifically? I usually use simple ssh keys to identify users and servers towards each other, never really thought about entire certificate chains.
I would assume the number of devices potentially needing certificates is probably too much for PKI, but it would still be nice to know their reasoning.
By evanjrowley 2025-05-1514:54 I suppose they might want to stop issuing client auth certificates because it means anyone with a PKI-signed cert could potentially authenticate as a client to a server. With PKI being a series of trust relationships among CAs, there's effectively no control over what gets accepted vs. rejected. I suppose from that perspective only private CAs make sense.
If you want to try using a private CA for x509 certificates to do SSH client authentication, I know of a couple solutions that make it easy to do:
Smallstep: https://smallstep.com/docs/tutorials/ssh-certificate-login/
Infiniscal: https://infisical.com/docs/documentation/platform/ssh/overvi...
You can also do it the hard way. For example, here's how it can be done to SSH into Cisco network gear: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9...
