Let’s Encrypt Changes Its Root Certificates on May 13. Client Auth Ends July 8

On May 13, 2026, Let’s Encrypt completes the migration to its Generation Y certificate hierarchy by switching the default ACME profile to issue from the new roots. The tlsserver and shortlived profiles already moved to Generation Y on January 7, 2026. What changes on May 13 is the classic profile, which most hosting operators and their customers use without any explicit configuration. The same date begins an opt-in 45-day certificate option and closes the escape hatch for organizations still needing client authentication certificates. The client authentication certificates themselves disappear entirely on July 8. Hosting operators have less than four weeks to verify that renewal automation handles these transitions correctly.

The scale of this transition is significant. Let’s Encrypt is the largest certificate authority in the world by certificates issued, issuing approximately ten million certificates per day as of late 2025 and closing in on protecting one billion websites. HTTPS adoption globally reached approximately 80 percent, and close to 95 percent in the United States, with Let’s Encrypt as the primary driver. For a hosting provider, that means the overwhelming majority of SSL certificates in active use across a customer base are Let’s Encrypt certificates affected by these changes.

What Generation Y Is

Generation Y is a new PKI hierarchy consisting of two new root certificate authorities and six new intermediate CAs. The roots are ISRG Root YR, an RSA 4096-bit key with a 20-year validity period matching ISRG Root X1, and ISRG Root YE, using an ECDSA P-384 key, designed to succeed ISRG Root X2. The six intermediates are named YE1, YE2, YE3, YR1, YR2, and YR3, and issue the certificates that hosting operators and their customers actually see in TLS handshakes.

Two design decisions distinguish Generation Y from the current hierarchy. First, the Subject Organization field is shortened from “Internet Security Research Group” to “ISRG” and the Common Names drop redundant prefixes. These are deliberate byte reductions to shrink the size of TLS handshakes at scale. Second, and more operationally significant, the Generation Y intermediates do not include the TLS Web Client Authentication extended key usage. They are server authentication only. The existing Generation X intermediates included both server and client auth EKUs. This removal is what makes the July 8 client authentication deadline absolute rather than incremental.

Generation Y certificates are cross-signed by the existing Generation X roots, so any system that currently trusts the X1 or X2 roots will continue to work when it encounters a Gen Y certificate after May 13. The only systems that break are those that pin the intermediate certificate rather than the root, a configuration that is non-standard but not unheard of in tightly controlled enterprise environments.

The ACME Profiles and What Changes on May 13

Let’s Encrypt introduced named ACME profiles in January 2025, allowing subscribers to specify certificate properties in the order request. Four profiles currently exist. The default “classic” profile requires no configuration change and will switch to issuing from Gen Y intermediates on May 13 while keeping the 90-day validity period until February 2027. The “tlsserver” profile, which is Gen Y and server-auth-only, switches to 45-day certificates on May 13 for subscribers who explicitly select it. The “shortlived” profile issues 160-hour certificates (just over six days) from Gen Y intermediates and is already in general availability. The “tlsclient” profile maintains the Gen X hierarchy with client auth EKU and closes to new subscribers on May 13, then shuts down entirely on July 8.

The path from 90-day to 45-day certificates across the classic profile follows a staged timeline that runs through 2028. On February 10, 2027, the classic profile default drops from 90 days to 64 days. On February 16, 2028, it drops from 64 days to 45 days. The intermediate 64-day step is deliberate: a certificate that was previously 90 days and is now 64 days will still typically trigger auto-renewal, but calendar-based or hardcoded renewal scripts will encounter the change and need to be corrected before the final drop to 45 days.

Client Authentication: What Ends and Who It Affects

Let’s Encrypt’s removal of the client authentication EKU from its certificates is driven by a Google Chrome root program requirement taking effect in June 2026 that mandates separation of TLS client and server authentication into distinct PKIs. The practical effect: any system that uses a Let’s Encrypt certificate to authenticate a client to a server rather than authenticate a server to a client will stop working after July 8.

The affected use cases are narrower than standard HTTPS hosting. Mutual TLS configurations where client certificates are issued by Let’s Encrypt, XMPP server-to-server authentication using Let’s Encrypt certs, and any application that validates the clientAuth EKU on an incoming certificate are the primary categories at risk. Operators who added Let’s Encrypt certificates to internal services and relied on clientAuth for access control need to migrate to a different CA for those certificates before July 8. Let’s Encrypt opened the tlsclient profile in October 2025 as a temporary migration window; organizations not already enrolled in it by May 13 cannot access it.

Six-Day Certificates and IP Address Certificates

Both reached general availability on January 15, 2026. The 160-hour short-lived certificates use the “shortlived” ACME profile and qualify under CA/Browser Forum Baseline Requirements as short-lived subscriber certificates, meaning they are not required to contain OCSP or CRL revocation information. A certificate that expires in six days is effectively self-revoking, which eliminates the revocation infrastructure dependency that creates latency and availability issues for standard certificates. Let’s Encrypt has stated no plans to make short-lived certificates the default.

IP address certificates are also issued exclusively through the shortlived profile and support both IPv4 and IPv6 SANs. The constraint to the shortlived profile is deliberate: Let’s Encrypt’s stated rationale is that IP addresses are more transient than domain names, making frequent revalidation important. Validation methods are limited to HTTP-01 and TLS-ALPN-01; DNS-01 is not supported for IP addresses. Certbot 5.3.0, released in March 2026, adds the –ip-address flag for requesting IP address certificates, with webroot plugin support added in Certbot 5.4.0, released March 10, 2026.

What This Means for a Hosting Provider and What to Do Now

For a hosting company, certificate failures are one of the few technical problems that customers notice immediately and personally. A browser displaying a security warning on a customer’s website is visible to the site’s visitors, damages the customer’s reputation, and the customer’s first call goes to the hosting provider. The May 13 and July 8 changes create three distinct situations where that outcome becomes possible if the team is not prepared.

Renewal automation. Most ACME clients renew certificates a fixed number of days before expiry, typically 30 days. For 90-day certificates this works: renewal triggers after two-thirds of the certificate’s life, leaving enough margin. For a 45-day certificate, renewing 30 days early means the certificate is renewed after only 15 days in service. Automation may treat this as an error, skip the renewal, or fail quietly. The certificate then expires without being replaced. The correct fix is renewal logic based on a fraction of the certificate’s lifetime rather than a fixed day count. The preferred long-term solution is ACME Renewal Information, RFC 9773, which lets Let’s Encrypt recommend the renewal window directly to the client. Certbot 4.1 and later support this. acme.sh, which is widely used in hosting automation, does not support ARI as of April 2026. The immediate risk on May 13 is low: the classic profile stays at 90 days. The real deadline for this fix is February 10, 2027, when the classic profile moves to 64 days. That date should be in the team’s roadmap now.

Client authentication, deadline July 8. Most hosting customers do not use Let’s Encrypt certificates for mutual TLS or client authentication; this was never a common use case in standard web hosting. However, any managed customer environment that does rely on Let’s Encrypt for client auth stops working on July 8 with no fallback. Identify those customers now. Let’s Encrypt recommends migrating these cases to a private CA. Finding them proactively is far less costly than responding to support tickets after the deadline.

Intermediate certificate pinning. Certificates issued after May 13 will chain to the new Generation Y intermediates. Any customer system or internal platform that pins the intermediate certificate rather than the root will fail on its first renewal after May 13. This is not common in standard hosting environments but does occur in tightly controlled enterprise deployments. Certificates issued before May 13 continue to chain correctly until their natural expiry, so this is an audit task, not an emergency response.