On February 11, Let's Encrypt removed the "TLS Client Authentication" Extended Key Usage from the default certificate profile it issues. Most site operators won't notice anything — the change specifically affects certificates used for mutual TLS setups, where the same certificate authenticates a server to visitors and also authenticates that server as a client connecting to some other backend system.
Why this happened
The change traces back to a Chrome Root Program policy requiring that certificate hierarchies trusted for server authentication be dedicated to that single purpose. Mixed-use certificates — ones that could serve as both a server credential and a client credential — no longer fit that model. Let's Encrypt is one of several major CAs adjusting its default issuance to comply.
Who actually needs to act
If you've never deliberately configured mutual TLS using a Let's Encrypt certificate, this almost certainly doesn't affect you — the change is invisible for the standard "secure my website" use case this site covers most often. If you do run an mTLS setup built on a Let's Encrypt certificate presenting as both server and client, you'll need two separate certificates going forward, or a move to a private CA for the client-authentication side — see our guide to mutual TLS if you're unfamiliar with how that dual-authentication setup works — which is generally the more architecturally correct approach for that use case anyway.
The broader pattern
This is one piece of a wider industry shift toward narrowly-scoped, single-purpose certificates rather than flexible, do-everything ones — a trend that shows up repeatedly across this year's certificate policy news, including Chrome's own broader clientAuth distrust timeline, covered separately.
This is our own summary and analysis of publicly reported news, written independently — not a reproduction of any single source's article. Where we reference a specific announcement, we link to it or name the organization directly.