Let's Encrypt introduces Generation Y roots and intermediates

Generation Y is the new set of Let's Encrypt root and intermediate certificates, announced on 24 November 2025. Two roots, ISRG Root YR (RSA-4096) and ISRG Root YE (ECDSA P-384), sit above six intermediates that cannot be used for TLS client authentication. As of 3 June 2026 all server-certificate profiles issue from Generation Y or ISRG Root X2.

What happened

The Generation Y roots succeed ISRG Root X1 (RSA-4096) and ISRG Root X2 (ECDSA P-384), and each new root is cross-signed by its predecessor of the same key type. CAs replace their hierarchies periodically, to retire ageing keys and to adapt to new root program rules. Until the new roots are present in the trust stores of operating systems, browsers and devices, the cross-signature lets clients that trust only the older roots build a valid certificate chain.

None of the six new intermediates includes the clientAuth extended key usage. That matches Let's Encrypt's end of TLS client authentication and the Chrome Root Program's push for TLS-dedicated hierarchies.

Who is affected

For most sites, nothing visible changes: the ACME client downloads the new chain with each renewal and the web server serves it. Problems appear when:

• intermediates are pinned or hard-coded, for example through certificate pinning in a mobile app, firewall or monitoring rules that match a specific issuer name, or a chain file maintained by hand;
• the server sends only the leaf certificate or an outdated chain, which clients report as a missing intermediate certificate;
• clients use a custom or outdated trust store, as in older Java runtimes, embedded devices or minimal container images, and rely on the cross-signed path.

What you should do

Serve the full chain your ACME client writes, such as certbot's fullchain.pem, instead of concatenating certificates yourself. In addition:

• Do not pin intermediates. If pinning is unavoidable, pin something you control and keep a backup pin.
• Keep ca-certificates or the equivalent package up to date on servers and in container images.

Check which chain a server sends:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

Check which ISRG roots a Debian or Ubuntu system trusts:

ls /etc/ssl/certs | grep -i isrg

The chain builder rebuilds a correct chain from a leaf certificate, the SSL checker flags incomplete chains, and the certificate chains guide explains how clients build a path to a root. More on the CA itself is on the Let's Encrypt profile.