# Let's Encrypt introduces Generation Y roots and intermediates

> New roots ISRG Root YR (RSA-4096) and ISRG Root YE (ECDSA P-384), cross-signed by their predecessors, plus six intermediates without clientAuth.

Source: https://ssl.sh/news/lets-encrypt-generation-y-hierarchy/
Last updated: 2026-11-10

Generation Y is the new set of Let's Encrypt [root](https://ssl.sh/glossary/root-certificate/) and [intermediate](https://ssl.sh/glossary/intermediate-certificate/) 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](https://ssl.sh/glossary/cross-signing/) 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](https://ssl.sh/glossary/trust-store/) of operating systems, browsers and devices, the cross-signature lets clients that trust only the older roots build a valid [certificate chain](https://ssl.sh/glossary/certificate-chain/).

None of the six new intermediates includes the clientAuth [extended key usage](https://ssl.sh/glossary/extended-key-usage/). That matches Let's Encrypt's [end of TLS client authentication](https://ssl.sh/news/lets-encrypt-ends-tls-client-authentication/) and the Chrome Root Program's push for [TLS-dedicated hierarchies](https://ssl.sh/news/chrome-dedicated-tls-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](https://ssl.sh/glossary/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](https://ssl.sh/errors/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:

```bash
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:

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

The [chain builder](https://ssl.sh/tools/chain-builder/) rebuilds a correct chain from a leaf certificate, the [SSL checker](https://ssl.sh/tools/ssl-checker/) flags incomplete chains, and the [certificate chains guide](https://ssl.sh/learn/certificate-chains/) explains how clients build a path to a root. More on the CA itself is on the [Let's Encrypt profile](https://ssl.sh/cas/lets-encrypt/).