Let’s Encrypt mTLS Deprecation & 45-Day Certificates: Everything You Need to Know After the May 13 Update

On May 13, 2026, Let’s Encrypt locked its tlsclient ACME profile to new accounts and simultaneously switched its tlsserver profile to issue 45-day certificates. Any organization that relied on Let’s Encrypt certificates for mutual TLS (mTLS) - API authentication, device-to-server verification, or client identity - must migrate to an alternative certificate source before the final cutoff on July 8, 2026. For everyone else, 45-day renewals are now opt-in and will become the industry default by February 2028.

What Exactly Changed on May 13, 2026?

Two separate changes took effect on that date, and it is important not to conflate them. The first affects mTLS users specifically. The second affects every Let’s Encrypt user eventually.

First, the tlsclient ACME profile - which issues certificates carrying the TLS Web Client Authentication Extended Key Usage (EKU) - was frozen. Existing accounts that previously requested a tlsclient certificate can still renew under a grace period. But no new accounts can enroll, and the profile itself will be completely removed on July 8, 2026, per Let’s Encrypt’s official community announcement (December 2025).

Second, the tlsserver profile began issuing 45-day certificates. This is opt-in today, but it marks the start of a fixed, published timeline that ends with 45-day certificates as the universal default in February 2028.

Let’s Encrypt Certificate Lifetime Reduction Timeline

Why Is Let’s Encrypt Deprecating mTLS Certificate Support?

The root cause is an architectural decision inside the new Generation Y certificate hierarchy, which Let’s Encrypt generated during a key ceremony in September 2025. The new Generation Y intermediate CAs deliberately omit the TLS Web Client Authentication EKU. That omission is not an oversight - it reflects an upcoming CA/Browser Forum root program mandate that requires cleaner separation between server and client authentication purposes.

Because the Generation Y intermediates lack the client authentication EKU, any certificate issued through them cannot technically serve as a valid mTLS client certificate. Continuing to offer a separate tlsclient profile would mean maintaining the older Generation X hierarchy indefinitely, which contradicts Let’s Encrypt’s security roadmap.

Does This Affect Standard Website HTTPS Certificates?

No. If you use Let’s Encrypt certificates only for web server HTTPS - which covers the overwhelming majority of deployments - May 13 introduces no breaking change for you today. Your certificates continue to renew normally through the classic profile, with the existing 90-day validity, until February 2027.

The practical shift for most site owners is the certificate renewal cadence: once the classic profile moves to 64 days in February 2027, then to 45 days in February 2028, any automation that uses hardcoded renewal intervals (for example, a cron job set to renew every 60 days) will silently break. A 45-day certificate renewed at day 60 is already expired.

Trusted SSL Certificates

Need a Longer-Lived SSL Certificate?

Paid SSL certificates from trusted CAs offer 1-year validity, warranty protection, and dedicated support - no 45-day renewal cycles required. Compare DV, OV, and EV options from top providers.

No commission influence. Independent price & feature comparison.

Who Is Directly Impacted by the mTLS Deprecation?

Any system that uses a Let’s Encrypt certificate to authenticate a client to a server - rather than authenticating the server to a browser - is at risk. This includes internal API gateways using certificate-based authentication, IoT device fleets that authenticate to cloud endpoints, VPN configurations that rely on Let’s Encrypt client certs, and microservices architectures using mutual TLS (two-way SSL) for zero-trust authentication.

These deployments face a hard cutoff. After July 8, 2026, the tlsclient profile is gone entirely - not just locked to new users. Any certificate issued via that profile will still be valid until its expiration, but no renewal will be possible.

What Should mTLS Users Do Before July 8, 2026?

1. 1
   Audit your certificate inventory. Identify every certificate in your environment that carries the TLS Web Client Authentication EKU and was issued by Let’s Encrypt. Tools like openssl x509 -text or your PKI dashboard can confirm EKU values.
2. 2
   Choose an alternative CA. Commercial certificate authorities (Sectigo, DigiCert, GlobalSign) and private/internal PKI solutions both support client authentication certificates without the upcoming restrictions.
3. 3
   Update your ACME client configuration - or replace ACME automation entirely - to point to the new CA’s issuance endpoint or enrollment process.
4. 4
   Test in staging first. Rotate one non-critical service before migrating production. Confirm trust chains, certificate parsing, and renewal cadences all work correctly.
5. 5
   Complete migration before July 8, 2026. Allow a two-week buffer before any certificate in the old profile expires to avoid service interruption.

Let’s Encrypt Certificates vs. Paid CA Certificates for mTLS

How Does the 45-Day Certificate Change Compare to Google’s 90-Day Push?

Google proposed reducing SSL certificate validity to 90 days in 2023. Let’s Encrypt is now moving beyond that to 45 days, aligning with - and slightly exceeding - the CA/Browser Forum’s April 2025 vote to mandate 47-day maximum validity by March 2029. Let’s Encrypt chose 45 days rather than 47, implementing the change a full year ahead of the industry mandate.

The underlying security rationale is consistent: shorter lifetimes reduce the window during which a compromised private key or a mis-issued certificate can be exploited. They also compensate for weaknesses in revocation mechanisms like CRL and OCSP, which many clients do not check reliably. For a deeper look at how organizations prepared for 90-day certificates, the same automation principles apply here - just with tighter margins.

What Is ACME Renewal Information (ARI) and Why Does It Matter Now?

ACME Renewal Information (ARI) is a protocol extension that lets a CA signal to your ACME client exactly when to renew a certificate - rather than relying on a fixed interval like "every 60 days." With 45-day certificates, ARI becomes functionally critical. Certbot 4.1.0 (released June 2025) added ARI support; earlier versions do not have it.

If you run Certbot below version 4.1.0, upgrade now. If you use a different ACME client, check its changelog for ARI support. Hardcoded renewal scripts - regardless of which client you use - must be updated to follow the certificate’s actual validity period, not a static number of days.

Does the Generation Y Root Change Affect Certificate Trust?

No - not for end-users or browsers. The new Generation Y roots are cross-signed by the existing Generation X roots (X1 and X2). Any device or browser that trusts Let’s Encrypt today will continue to trust certificates issued under Generation Y without any configuration change. Certificate authorities routinely use cross-signing to maintain backward compatibility during root transitions.

The practical implication is that the Generation Y rollout is operationally invisible to most website visitors. The impact concentrates entirely on the issuing side: the absence of the client authentication EKU in Generation Y intermediates is what triggers the mTLS deprecation.

Frequently Asked Questions

Will my existing Let’s Encrypt mTLS certificates stop working on May 13, 2026?

No, not immediately. Certificates already issued before May 13 remain valid until their expiration date. The May 13 freeze prevents new accounts from accessing the tlsclient profile. The complete shutdown - when no renewals are possible - is July 8, 2026. Plan your migration to complete well before that date.

Do I need to do anything right now for my standard website certificate?

Not urgently, but proactively. The classic ACME profile stays at 90-day certificates until February 2027. The action to take now is to verify your automation does not use a hardcoded renewal interval and that your ACME client is up to date. Certbot 4.1.0+ with ARI support is the recommended baseline.

What alternatives exist for mTLS client authentication after the deprecation?

Commercial CAs (Sectigo, DigiCert, GlobalSign, Entrust) all issue client authentication certificates. Private PKI solutions - including Microsoft AD CS, HashiCorp Vault PKI, or AWS Private CA - are the standard choice for internal mTLS at scale, since they remove external CA dependencies entirely and give you full lifecycle control.

What is the CA/Browser Forum’s role in driving these certificate lifetime reductions?

The CA/Browser Forum is the industry body that sets the Baseline Requirements all publicly trusted CAs must follow. In April 2025, the Forum voted to mandate a maximum of 47-day certificate validity by March 2029. Let’s Encrypt chose to move to 45 days ahead of that mandate. All publicly trusted CAs will need to comply with the Forum’s timeline, so these changes will affect paid CAs as well, though with a later rollout.

Can I opt into 45-day certificates before they become the default?

Yes. The tlsserver ACME profile now issues 45-day certificates as of May 13, 2026. To opt in, configure your ACME client to use the tlsserver profile. This is recommended for teams that want to test their automation under the shorter validity period before the mandatory transition in February 2028. Enable ACME Renewal Information (ARI) in your client before opting in.

How does the 7-hour authorization reuse window in 2028 affect certificate issuance?

Today, after Let’s Encrypt validates that you control a domain, it allows certificate issuance for that domain for 30 days without re-validation. By February 2028, that window drops to 7 hours. This means automated renewal pipelines must be capable of completing a full ACME challenge and issuance cycle at renewal time - not just requesting a certificate against a cached authorization. Systems with slow DNS propagation or restrictive firewall rules on HTTP-01 challenges may need infrastructure adjustments.

The Bottom Line on Let’s Encrypt’s May 13 Update

The May 13, 2026 changes split into two distinct operational concerns. For mTLS users, the clock is running: the tlsclient profile disappears entirely on July 8, 2026, and there is no extension. Migrating to a commercial CA or private PKI is not optional - it is the only path forward.

For the broader audience using Let’s Encrypt for web HTTPS, the immediate risk is low but the preparation window is finite. Automation that works today may silently fail in February 2027 when the classic profile drops to 64-day certificates, and it will definitely fail by February 2028 at 45 days if hardcoded renewal intervals are not corrected.

The key insight: treat this as scheduled infrastructure maintenance, not an emergency. Teams that upgrade ACME clients, enable ARI, and remove hardcoded renewal intervals now will navigate both the 2027 and 2028 transitions without incident. The teams that wait for certificates to expire will learn the hard way that 45 days passes faster than they expect.

Next step: Run certbot --version today. If it returns anything below 4.1.0, schedule the upgrade within the next 7 days.