Let’s Encrypt YE1 and YR1 chain errors

Let’s Encrypt now signs certificates with a new set of intermediates, called Generation Y: YE1 and YE2 for ECDSA keys, YR1 and YR2 for RSA keys. They hang off two new roots, Root YE and Root YR, which, in Let’s Encrypt’s words on its certificate list, “are not yet included in Root Program Trust Stores”.

A client can only trust a chain that ends at a root it already has. So until the new roots are accepted, each one reaches clients as a cross-signed certificate: Root YE signed by ISRG Root X2, Root YR signed by ISRG Root X1. Your server has to send that cross-signed certificate along with the intermediate. Leave it out, and many clients fail with unable to get local issuer certificate.

The two default chains

Let’s Encrypt’s certificate list gives the chain each kind of certificate is served with by default (“EE” is your certificate):

The same page is blunt about shorter chains: “Chains which terminate at Root YE or Root YR are not expected to work with any of the major trust stores, as those roots have not yet been incorporated.” A server that sends only its certificate and the intermediate ends at exactly that point.

The extra link in the ECDSA chain serves older clients. ISRG Root X1 is trusted from Android 7.1.1, but ISRG Root X2 only from Android 14, and in Java from 8u401, 11.0.22 and 17.0.10 (certificate compatibility). The cross-signed X2 lets clients that have only X1 complete the chain.

What changed, and when

The revocation on May 13 mattered beyond Let’s Encrypt’s own servers. In its incident report, Let’s Encrypt “identified 688,413 unexpired certificates which were likely being presented in TLS handshakes alongside a chain including one of the revoked CA certificates”, and told their ACME clients to renew early. A chain saved before May 13 and reused by hand still contains a revoked certificate.

See what your server sends

openssl s_client -showcerts lists every certificate the server sent; s: is the subject and i: the issuer. This is letsencrypt.org itself on October 20, 2026, with the full ECDSA chain:

openssl s_client -connect letsencrypt.org:443 \
    -servername letsencrypt.org -showcerts </dev/null 2>/dev/null \
  | grep -E '^Certificate chain| [0-9]+ s:|   i:|Verify return code'

Certificate chain
 0 s:CN=letsencrypt.org
   i:C=US, O=Let's Encrypt, CN=YE2
 1 s:C=US, O=Let's Encrypt, CN=YE2
   i:C=US, O=ISRG, CN=Root YE
 2 s:C=US, O=ISRG, CN=Root YE
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
 3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
Verify return code: 0 (ok)
    Verify return code: 0 (ok)

Certificate 2 is the one to look for: s: is Root YE and i: is ISRG Root X2. For an RSA certificate, look for Root YR issued by ISRG Root X1.

Now a server that stops short. Let’s Encrypt’s test site valid.yr.test-certs.letsencrypt.org sends only its certificate and YR1, as a deliberate example:

openssl s_client -connect valid.yr.test-certs.letsencrypt.org:443 \
    -servername valid.yr.test-certs.letsencrypt.org -showcerts </dev/null 2>/dev/null \
  | grep -E '^Certificate chain| [0-9]+ s:|   i:|Verify return code'

Certificate chain
 0 s:
   i:C=US, O=Let's Encrypt, CN=YR1
 1 s:C=US, O=Let's Encrypt, CN=YR1
   i:C=US, O=ISRG, CN=Root YR
Verify return code: 20 (unable to get local issuer certificate)
    Verify return code: 20 (unable to get local issuer certificate)

The last issuer, Root YR, is nowhere in the output and in no trust store, so OpenSSL gives up. The same site loaded without complaint in macOS’s bundled curl, which uses Apple’s certificate checks. As with missing intermediates, a client that works proves little.

The certificate chain checker does the same from outside your network: it shows each certificate the server sends, names a Generation Y chain, and says whether the cross-signed Root YE or YR is in it.

Failures seen so far, and their fixes

The server sends only the certificate and the intermediate

Symptom: unable to get local issuer certificate (curl, OpenSSL, Python), UNABLE_TO_GET_ISSUER_CERT_LOCALLY (Node.js), while browsers work.

A community member tested curl on Debian 13, Ubuntu 26.04 and Fedora 44 against the YR test site above: all three failed with unable to get local issuer certificate, because their CA bundles contain ISRG Root X1 and X2 and nothing newer. Any client that verifies against a bundle like those, and doesn’t get the missing certificate some other way, fails the same way on a server that leaves out the cross-sign.

Fix: serve the chain Let’s Encrypt returns with the certificate, unchanged. ACME clients save it for you: with Certbot it is fullchain.pem, which starts with your certificate and continues with the intermediates. The usual cause is software that keeps only the first intermediate, or a chain file put together by hand. Point the server at the full chain file, reload it, and check again. If the client only ever gives you a short file, add the cross-signs yourself from Let’s Encrypt’s own downloads.

If the full public chain verifies and a Node.js application still reports UNABLE_TO_GET_ISSUER_CERT_LOCALLY, check what that Node.js process trusts and which endpoint it reaches: Node.js: bundled roots, and what adds to them.

SSL Labs reports a revoked certificate in the chain

Symptom: after a reissue in May 2026, SSL Labs showed a revoked certificate in the chain of certificates from YR2 (thread).

The server wasn’t sending the Root YR cross-sign: the person who reported it traced it to a PHP ACME client setup where “only the first intermediate Cert is stored”. The test then fetched the missing certificate on its own and found the old, revoked cross-sign. The answer in that thread is the general rule: “The chain is returned by Let’s Encrypt and you should just use it.”

Fix: the same as above. Serve the full chain from the ACME response. If you copied a chain before May 13, 2026, replace it.

The chain contains an expired ISRG Root X2 cross-sign

Symptom: failures on clients that don’t trust ISRG Root X2 directly, starting around May 28, 2026 (thread).

Some providers sent the 2020 cross-signed ISRG Root X2, which expired on September 15, 2025, instead of the current one valid until 2032. Cloudflare provisioned chains like this for a short time (thread); its status page put the incident at June 2 to 3, 2026 and reported it resolved.

Fix: if you manage the chain, take it fresh from your ACME client, not from an old bundle. If a provider manages it, check what it serves with openssl s_client and report it to them. The certificate before ISRG Root X1 should be valid until September 2, 2032.

Windows and IIS serve a chain ending at Root YE or Root YR

Symptom: a Windows server sends a chain whose last certificate is the self-signed Root YE or Root YR.

Community members report that IIS builds the chain it serves from the Windows certificate stores, not from the file you import: “services like IIS will serve the new chain if the server trust store trusts the new [self-signed] roots”. They add that this “is not configurable in IIS”, and that a “Preferred Chain” option has no effect. We haven’t seen Let’s Encrypt staff confirm it in that thread.

Fix: test the server from outside, as above. If it ends at Root YE or YR, look for those roots among the server’s trusted root certificates; a Windows server that trusts them builds the short chain, which other clients can’t use.

What not to do

• Don’t hand-edit chains. Let’s Encrypt can change intermediates without notice: of the backups YE3 and YR3, it says “We may begin issuing Subscriber certificates from them at any time, without warning” (certificate list). A chain or a pinned intermediate written by hand is out of date the day that happens.
• Don’t send Root YE or Root YR self-signed. No major trust store accepts it yet, so it ends the chain at a root nobody trusts.
• Don’t add Root YE or YR to clients to make an error go away. It can mask a short chain for that client. Read the exact error and tell server from client first, keep clients on supported versions with current CA bundles (that is how they get ISRG Root X2), and fix the server if what it sends leaves out the cross-sign.
• Don’t rely on the new intermediates for client authentication. They have no TLS client authentication usage; the announcement says so.

After the fix

1. Reload the server, and confirm the reload happened.
2. Run openssl s_client -showcerts again: look for Root YE issued by ISRG Root X2, or Root YR issued by ISRG Root X1, and Verify return code: 0 (ok).
3. Test from a client that doesn’t repair chains, such as curl on Linux. Browsers and macOS can hide the problem.
4. If several servers or a CDN serve the name, check each one.

Where these certificates come from, and why devices fetch them from addresses like yr1.i.lencr.org, is in What is lencr.org, and is it malware?. For every other chain error, see Fix “unable to get local issuer certificate”; to read a certificate’s dates, Check SSL expiry: openssl, curl, browser.

Sources

All sources were checked on October 20, 2026. The openssl and curl output comes from our own tests on that date, with OpenSSL 3.6.4 and macOS’s bundled curl 8.7.1. The link to our Node.js section was added and checked on October 26, 2026; the sources below weren’t checked again then.

• Chains of Trust, Let’s Encrypt, last updated July 8, 2026: the Generation Y roots and intermediates, default chains, trust store status and backup intermediates.
• New “Generation Y” Hierarchy of Root and Intermediate Certificates, Let’s Encrypt, November 24, 2025: the announcement, and no client authentication usage.
• Upcoming Changes to Let’s Encrypt Certificates, Let’s Encrypt Community Support: production on January 7, 2026.
• 2026.05.08 Gen Y Cross-Certified Subordinate CAs missing serverAuth EKU, Let’s Encrypt Community Support, and Mozilla bug 2038351: the incident, replacement cross-signs, revocation and early renewals.
• Upcoming Let’s Encrypt Profile Changes On May 13, 20th, and 27th, Let’s Encrypt Community Support.
• Certificate Compatibility, Let’s Encrypt, last updated January 19, 2025, checked again on October 30, 2026: which Android and Java versions trust ISRG Root X1 and X2.
• Let’s Encrypt Community Support threads: chain validation under Linux distributions, revoked certificate in chain from YR2, expired ISRG Root X2 cross-sign, Cloudflare’s expired X2 cross-sign (with Cloudflare’s status incident) and Windows and the YE/YR hierarchy.
• Where are my certificates?, Certbot documentation.