All tools

Guides Certificates

Let’s Encrypt YE1 and YR1 certificates

Updated 10 min read

Short answer

YE1 and YE2 (ECDSA) and YR1 and YR2 (RSA) are Let’s Encrypt’s intermediates, the certificates that sign its certificates today. They’re genuine, and the official files are below.

Most systems need no download. A server sends the intermediate with its certificate, plus a cross-signed Root YE or YR that links the chain to ISRG Root X1 or X2, which devices already trust.

What to do: download only for a device that keeps its own store of CA certificates, such as some firewalls, or to repair a chain file that lost them. Which files you need says which ones.

The certificate chain checker shows which intermediate signed a site, and whether its server sends the cross-signed Root YE or YR. Check a chain

Every file below is Let’s Encrypt’s own, from its Chains of Trust page. PEM is text that starts with -----BEGIN CERTIFICATE----- (what a form asking for “Base64” wants); DER is the same certificate in binary.

The intermediates sign certificates. Each new certificate gets one of the active ones for its key type, chosen at random, so nothing can count on YE1 rather than YE2. Let’s Encrypt does it on purpose, to discourage pinning one.

Certificate Signs Valid until Download
YE1 ECDSA certificates Sep 2, 2028 PEM · DER
YE2 ECDSA certificates Sep 2, 2028 PEM · DER
YR1 RSA certificates Sep 2, 2028 PEM · DER
YR2 RSA certificates Sep 2, 2028 PEM · DER
YE3 ECDSA, backup Sep 2, 2028 PEM · DER
YR3 RSA, backup Sep 2, 2028 PEM · DER

YE3 and YR3 aren’t in use yet, but in Let’s Encrypt’s words, “We may begin issuing Subscriber certificates from them at any time, without warning.” Anything that keeps its own copies needs them too.

The cross-signs link the new roots to the ones devices already trust. A server sends them after the intermediate.

Certificate Signed by Valid until Download
Root YE ISRG Root X2 Sep 2, 2032 PEM · DER
Root YR ISRG Root X1 Sep 2, 2032 PEM · DER
ISRG Root X2 ISRG Root X1 Sep 2, 2032 PEM · DER

The roots, self-signed. The dates are Let’s Encrypt’s, which it calls approximate, “based on current Root Program policies”.

Certificate In trust stores Download
ISRG Root X1 Yes, until about Jun 4, 2030 PEM · DER
ISRG Root X2 Yes, until about Sep 4, 2035 PEM · DER
Root YE Not yet PEM · DER
Root YR Not yet PEM · DER

To download them all into an empty folder and print each one’s SHA-256 fingerprint:

for f in int-ye1 int-ye2 int-ye3 int-yr1 int-yr2 int-yr3 \
    root-ye-by-x2 root-yr-by-x1 root-x2-by-x1 root-ye root-yr; do
  curl -sSO "https://letsencrypt.org/certs/gen-y/$f.pem"
done
curl -sSO https://letsencrypt.org/certs/isrgrootx1.pem
curl -sSO https://letsencrypt.org/certs/isrg-root-x2.pem
for f in *.pem; do
  openssl x509 -in "$f" -noout -fingerprint -sha256 \
    | sed "s/^sha256 Fingerprint=/$f  /"
done
int-ye1.pem  A2:37:2D:06:43:1E:97:16:36:5E:EE:D4:7E:C0:20:35:14:97:D1:82:FC:C0:38:E4:57:E5:81:68:A0:3C:AC:07
int-ye2.pem  97:65:8D:E8:C6:8D:FA:98:AC:E1:E5:02:8A:63:D5:4A:1A:AE:91:1B:3E:21:47:10:76:C6:85:0C:D0:8C:BA:B4
int-ye3.pem  82:BC:FC:48:2C:C1:9F:71:E6:F9:8F:4A:02:76:16:EB:DA:6D:47:09:6D:40:8B:33:61:60:D1:C0:EF:8B:99:5A
int-yr1.pem  13:94:96:34:D9:9C:D6:FD:6A:A8:0B:C0:34:FE:FA:CC:EB:19:69:FE:EF:98:65:86:71:3E:CD:BB:05:75:8D:3F
int-yr2.pem  23:8B:85:A0:09:9C:65:B9:70:47:7D:57:24:F1:A1:D4:75:CE:50:58:CF:FE:4E:FA:87:33:89:9B:DB:86:3C:47
int-yr3.pem  35:50:0C:B6:3B:8D:97:69:52:8D:65:D8:72:20:F5:1C:06:98:07:A5:95:AC:BF:2F:B6:EC:A3:8F:BE:0A:4B:D2
isrg-root-x2.pem  69:72:9B:8E:15:A8:6E:FC:17:7A:57:AF:B7:17:1D:FC:64:AD:D2:8C:2F:CA:8C:F1:50:7E:34:45:3C:CB:14:70
isrgrootx1.pem  96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6
root-x2-by-x1.pem  EE:5F:7A:BD:69:81:BB:02:55:63:2C:D8:F4:92:83:45:1B:4B:18:84:4D:12:04:0B:44:EE:00:F0:7B:8F:E2:C6
root-ye-by-x2.pem  0F:C0:90:1C:CA:2B:AE:9E:9F:DB:B0:2D:50:D0:2F:10:94:F7:B3:66:72:08:69:91:B9:E8:97:62:6D:C4:85:F0
root-ye.pem  E1:4F:FC:AD:5B:00:25:73:10:06:CA:A4:3A:12:1A:22:D8:E9:70:0F:4F:B9:CF:85:2F:02:A7:08:AA:5D:56:66
root-yr-by-x1.pem  07:26:39:D0:B1:40:D5:BF:FA:E1:6A:D9:C3:F6:CC:60:86:04:06:21:F5:1E:E6:1A:6D:46:A8:91:5C:07:CF:76
root-yr.pem  E5:7B:7E:6F:15:0C:41:91:02:E8:D5:C0:55:72:9F:F9:67:B9:D1:A8:29:BF:00:CE:C8:9C:A6:04:EB:F4:A8:6F

Let’s Encrypt also serves each certificate from its own address on lencr.org, such as ye1.i.lencr.org (what those addresses are). We fetched the intermediates and cross-signs from there too: every fingerprint matched the files above, and ISRG Root X1’s also matched the copy in macOS’s /etc/ssl/cert.pem. A copy from anywhere else should match as well.

Which files you need

A server or appliance that serves the certificate

Usually none. Your ACME client saved the whole chain when the certificate was issued (with Certbot, fullchain.pem), and that is what the server should send. Download only when that file came out short: your certificate and the intermediate, with nothing after it. Then add, after the intermediate:

Your certificate was signed by Add after the intermediate, in this order
YE1, YE2 or YE3 root-ye-by-x2.pem, then root-x2-by-x1.pem
YR1, YR2 or YR3 root-yr-by-x1.pem

Which one signed your certificate tells you which row is yours, and Repair a short chain file shows the steps. Never add the self-signed ISRG Root X1 or X2: clients already have them, so the server doesn’t send them.

A firewall with its own certificate store

Some firewalls build chains from their own store of CA certificates, so they can’t complete a Generation Y chain until they have its pieces. Sophos documented this for Sophos Firewall on September 21, 2026 (KBA-000048864): the firewall “may fail to provide a complete certificate chain” because “required intermediate certificates are not installed”.

  • Sophos Firewall: Sophos released a hotfix; restart the firewall if it is still affected. Without the hotfix, its workaround is to upload, as PEM, Root YE and Root YR in both versions (self-signed and cross-signed) and YE1, YE2, YR1 and YR2 to the firewall’s CA store.
  • Other firewalls: look for the vendor’s update first. Copies you add by hand need YE3 and YR3 too, and need replacing whenever Let’s Encrypt changes its intermediates.
  • A firewall that inspects traffic and blocks sites signed by YE1: check the site’s chain first. If the site leaves out its cross-signed Root YE or YR, that is a common misconfiguration for the server to fix. It can explain the block if the firewall has no other path to a root it trusts, though not every client fails on it. If the checker shows the full chain, that is what reached us, not proof that the firewall’s store is out of date. Compare what the firewall saw with a client that works first; if it was given the full chain and still can’t build a path, update its store or ask the vendor.

A Windows server

Don’t trust the self-signed Root YE or Root YR on it. Certify The Web, which makes an ACME client for Windows, explains that Windows picks the chain IIS serves from the certificates the server trusts. A server that trusts the new roots serves a chain that ends at them, and clients that don’t have them yet fail; curl reports unable to get local issuer certificate. How to check what a Windows server sends.

Your own computers and phones

Usually nothing. A supported system kept up to date trusts ISRG Root X1 or X2, and a server set up correctly sends the rest. Which roots a device trusts depends on its platform and its updates, and an application may not use the system’s store at all: curl’s, for one, depends on how it was built. Don’t install Root YE or YR on your computers or phones.

If a browser or curl reaches a site and an application on the same device fails, the site may be sending a short chain, but that difference alone doesn’t show it. Compare the two:

  • Where each one connects: the exact hostname and port, and the network path, such as a VPN, a proxy or a firewall that inspects traffic. OpenSSL’s s_client sets the address it connects to, the name it sends and the name it verifies separately, so a test can reach somewhere the application doesn’t.
  • The application, its version and where it runs, and its exact error, word for word.
  • The certificates the failing client was given, if it can show them. The list a server sends is not the path a client builds from it and its own store: openssl s_client -showcerts prints only what the server sent, not a verified chain.

A short chain’s fix belongs on the server. Server or client? walks through telling the two apart.

Which one signed your certificate

Ask the server for its certificate and read the issuer. This is Let’s Encrypt’s test site for Root YE:

host=valid.ye.test-certs.letsencrypt.org
openssl s_client -connect $host:443 -servername $host </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -ext authorityInfoAccess
issuer=C=US, O=Let's Encrypt, CN=YE1
Authority Information Access: 
    CA Issuers - URI:http://ye1.i.lencr.org/

CN=YE1 names the intermediate. CA Issuers is the address where clients can fetch it, the same certificate as int-ye1.pem. For a certificate file on disk, run the second line alone: openssl x509 -in cert.pem -noout -issuer.

Check a file you downloaded

Compare its fingerprint with the list above:

curl -sSO https://letsencrypt.org/certs/gen-y/int-ye1.pem
openssl x509 -in int-ye1.pem -noout -subject -issuer -enddate \
  -fingerprint -sha256
subject=C=US, O=Let's Encrypt, CN=YE1
issuer=C=US, O=ISRG, CN=Root YE
notAfter=Sep  2 23:59:59 2028 GMT
sha256 Fingerprint=A2:37:2D:06:43:1E:97:16:36:5E:EE:D4:7E:C0:20:35:14:97:D1:82:FC:C0:38:E4:57:E5:81:68:A0:3C:AC:07

A form that wants “Base64” or PEM won’t take a .der file. To convert one:

openssl x509 -inform DER -in int-ye1.der -out int-ye1.pem
head -n 1 int-ye1.pem
-----BEGIN CERTIFICATE-----

Repair a short chain file

Let’s Encrypt’s test site valid.ye.test-certs.letsencrypt.org sends only its certificate and YE1, on purpose. Saving what it sends gives exactly the short file this section repairs:

host=valid.ye.test-certs.letsencrypt.org
openssl s_client -connect $host:443 -servername $host -showcerts \
    </dev/null 2>/dev/null \
  | sed -n '/BEGIN CERT/,/END CERT/p' > served.pem
openssl verify -CAfile isrgrootx1.pem -untrusted served.pem served.pem
C=US, O=Let's Encrypt, CN=YE1
error 20 at 1 depth lookup: unable to get local issuer certificate
error served.pem: verification failed

Run it in the folder you downloaded the certificates to. -CAfile isrgrootx1.pem trusts ISRG Root X1 and nothing else, as a client with an older store would. Add the two cross-signs from the table after the intermediate, and check again:

cat served.pem root-ye-by-x2.pem root-x2-by-x1.pem > fullchain.pem
openssl verify -CAfile isrgrootx1.pem -untrusted fullchain.pem fullchain.pem
fullchain.pem: OK

On your own server, start from your certificate and the intermediate your ACME client saved instead of served.pem, point the server at the new file, and reload it. Then fix whatever wrote the short file, or the next renewal brings it back. On pfSense in June 2026, community members found that the ACME package’s exported fullchain.cer under /conf/acme/ held two certificates, while the working copy under /tmp/acme/ held all four.

Two versions of each new root

Root YE and Root YR each exist twice, with the same name and key:

  • Self-signed, the version that will go into trust stores. Let’s Encrypt’s announcement says it will submit the new roots “for inclusion in the Apple, Chrome, Microsoft, Mozilla, and other root programs”. Until they are in, “Chains which terminate at Root YE or Root YR are not expected to work with any of the major trust stores” (Chains of Trust).
  • Cross-signed, by ISRG Root X2 (Root YE) or X1 (Root YR), the version that makes the new chains work today. This is the one a server sends.

The cross-signs in use today were issued on May 13, 2026. The first ones lacked a required extension and were revoked that day, so a copy saved earlier is the revoked one. Check a copy’s start date:

openssl x509 -in root-ye-by-x2.pem -noout -subject -issuer -startdate -enddate
subject=C=US, O=ISRG, CN=Root YE
issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X2
notBefore=May 13 00:00:00 2026 GMT
notAfter=Sep  2 23:59:59 2032 GMT

Why the new chains fail when a server leaves the cross-sign out, and every failure seen so far, is in Let’s Encrypt YE1 and YR1 chain errors.

Sources

The sources were checked on October 25, 2026, except the last three, added on October 30, 2026. The certificates were downloaded and every command run on October 25, 2026, with OpenSSL 3.6.4.

Keep reading