Originally published at https://monstadomains.com/blog/lets-encrypt-certificate-changes/
On 8 July 2026, Let’s Encrypt quietly retired the last certificate profile capable of issuing a TLS Client Authentication extension. There was no outage and no press conference, just a configuration flag flipped at the busiest certificate authority on the internet. That date closed the first chapter of the Let’s Encrypt certificate changes now moving through every site that relies on free automated TLS, and the next chapters land in February 2027 and February 2028.
The Let’s Encrypt Certificate Changes That Landed In July
The July retirement completed a removal that started on 11 February 2026, when Let’s Encrypt stripped the TLS Client Authentication Extended Key Usage from its default profile and offered a temporary tlsclient profile as a grace period. That grace period is over. Certificates issued now authenticate a server to a browser and do nothing else. For most site operators the shift is invisible. For anyone who had repurposed a free public certificate to authenticate an API client, a VPN endpoint, or a mutual TLS link between internal services, the Let’s Encrypt certificate changes broke something real, and no public CA will hand that capability back.
The organisation was explicit that it no longer issues certificates containing the TLS Client Authentication EKU. The wording matters. This is not a deprecation with a quiet fallback, it is a hard stop, and the Let’s Encrypt certificate changes here were driven by browser root program policy rather than by internal preference.
Inside The Generation Y Root Hierarchy
Underneath the profile shuffle sits a much larger piece of infrastructure work. Let’s Encrypt introduced a new root hierarchy called Generation Y, made up of two new Root CAs and six new Intermediate CAs, cross signed by the existing Generation X roots, ISRG Root X1 and ISRG Root X2. Cross signing keeps older devices working while the new roots accumulate the years of trust store distribution they need. The Generation Y rollout is the structural half of the Let’s Encrypt certificate changes, and it is the half most people will never see.
Why Two Roots And Six Intermediates
Redundancy is the honest answer. A certificate authority serving hundreds of millions of domains cannot afford a single chain failure, so the hierarchy is built with spare capacity and separate RSA and ECDSA paths. Critically, the new intermediates omit the TLS Client Authentication EKU entirely. That design decision is what makes the July retirement permanent rather than reversible, and it ties the two halves of the Let’s Encrypt certificate changes together.
Why Client Authentication Had To Be Removed
Browser root programs, Chrome’s in particular, have spent years arguing that a certificate should do exactly one job. A certificate that can vouch for a server and also vouch for a client is a certificate whose misuse is harder to reason about and harder to revoke cleanly. Root programs are now mandating that separation, and public certificate authorities are complying. Let’s Encrypt simply moved first and absorbed the complaints early.
The February 2027 Deadline For Every Public CA
Under Chrome root program rules, public certificate authorities must stop supporting TLS client authentication by February 2027. Commercial CAs including Sectigo and DigiCert have published their own migration guidance pointing at the same deadline. Anyone treating the Let’s Encrypt certificate changes as one vendor’s unilateral decision is reading the story wrong. This is an industry wide reset, and Let’s Encrypt users are simply living through it around eight months ahead of everyone else.
Certificate Lifetimes Drop From 90 Days To 45
The second track of the Let’s Encrypt certificate changes is validity. The 90 day certificate that defined the service for a decade is being cut in half. Since 13 May 2026 the tlsserver profile has issued 45 day certificates on an opt in basis. On 10 February 2027 the classic default profile drops to 64 days with a 10 day authorisation reuse window, and on 16 February 2028 it drops again to 45 days with authorisation reuse of just seven hours. Those dates come straight from Let’s Encrypt’s own announcement.
The stated reasoning is blunt. Reducing how long certificates are valid for, the organisation wrote, helps improve the security of the internet by limiting the scope of compromise and making certificate revocation technologies more efficient. Revocation on the web has never worked reliably. Expiry always has. The Let’s Encrypt certificate changes are a bet that a certificate which dies on its own is safer than one somebody has to remember to kill.
What The Let’s Encrypt Certificate Changes Reveal About Automation
Read the timeline as a whole and one message dominates. Manual certificate management is finished. At 45 days a calendar reminder is not a strategy, it is a scheduled outage with a date attached. The Let’s Encrypt certificate changes are less a request than an ultimatum: automate renewal properly, or accept that your site will eventually serve an expired certificate to every visitor who arrives.
Let’s Encrypt recommends implementing ACME Renewal Information, known as ARI, so clients renew on timing the authority suggests rather than on a fixed guess. For anyone not using ARI, it advises triggering renewal around two thirds of the way through the certificate lifetime. Its upcoming features page tracks every dated milestone in public. Both recommendations exist because the Let’s Encrypt certificate changes compress the margin for error to almost nothing.
The Wider CA Browser Forum Timeline
None of this happens in isolation. The CA/Browser Forum has already locked in a staged reduction of maximum certificate validity across every publicly trusted authority. Since 15 March 2026 the ceiling has been 200 days. On 15 March 2027 it falls to 100 days, and after 15 March 2029 it lands at 47 days. Commercial certificates are on the same trajectory as free ones, which means paid renewal cycles offer no escape route. The Let’s Encrypt certificate changes are simply the most visible expression of a shift touching every certificate on the public web.
Validation Reuse Windows Are Shrinking Too
Less discussed but equally disruptive is domain control validation reuse. Under the Forum’s schedule, reuse of a validation result drops to 100 days from March 2027 and to 10 days after March 2029. Let’s Encrypt goes further still, cutting authorisation reuse to seven hours by 2028. Proving control of your domain becomes a near continuous process rather than an annual formality, and the Let’s Encrypt certificate changes make that shift concrete first. If you want to see what your current certificate actually chains to, an SSL checker tool shows the path in seconds.
The Privacy Side Of The Let’s Encrypt Certificate Changes
There is a quieter thread here worth pulling. Let’s Encrypt removed OCSP URLs from its certificates in May 2025 and shut down expiration notification emails in June 2025, deleting the addresses associated with ACME accounts from its production database. OCSP checks leaked browsing behaviour back to the authority. Expiry notices required it to hold an identifier tied to a human being. Both are gone. The Let’s Encrypt certificate changes have steadily stripped away reasons for a certificate authority to know anything about you, which is the correct direction of travel and rarer than it should be.
That matters if you run a site you would rather not have traced back to a person. Certificate Transparency logs already publish every hostname you certify, so wildcard certificates and careful subdomain hygiene protect you more than any CA relationship will. Our earlier look at shorter certificate lifetimes covers that trade off in more depth.
How To Respond To The Let’s Encrypt Certificate Changes
Start with an inventory. Find every certificate you are responsible for, note its issuer and profile, and flag anything still relying on client authentication, because that is already broken rather than about to break. Confirm your ACME client supports ARI and short lifetimes, since older Certbot builds and bundled control panel clients often do not. Move renewal to two thirds of lifetime and alert on renewal failure rather than on expiry. Then force a test renewal now instead of discovering the problem at 3am in February 2027. The Let’s Encrypt certificate changes reward preparation and punish drift.
The Takeaway
Three things are worth carrying away from this. Client authentication from public certificate authorities is over, and July’s retirement made that final rather than theoretical. Certificate lifetimes are heading to 45 days on dates that are already published, so automated renewal is now a requirement rather than a nicety. And the quiet removal of OCSP and notification emails shows the Let’s Encrypt certificate changes trimming data collection along the way, which deserves more credit than it gets.
If you are auditing your setup this month, MonstaDomains pairs privacy respecting SSL certificates with domains that never ask for your identity in the first place.


