Chains of Trust

Last updated: January 8, 2026
இவ்வலைப்பக்கம் இன்னும் மொழிபெயர்க்கப்படவில்லை. நீங்கள் இங்கே பங்களிக்கலாம்.

This page describes all of the current and relevant historical Certification Authorities operated by Let’s Encrypt. Note that a CA is most correctly thought of as a key and a name: any given CA may be represented by multiple certificates which all contain the same Subject and Public Key Information. In such cases, we have provided the details of all certificates which represent the CA. If you’re looking for the Trust Anchor IDs associated with these CAs, see our page on Object Identifiers.

ISRG Certificate Hierarchy Diagram, as of January 2026

Root CAs

Our root key material is kept safely offline. We issue end-entity certificates to subscribers from the intermediates described in the next section. All root certificate Subjects have a Country field of C = US.

Note that Root CAs don’t have expiration dates in quite the same way that other certificates do. Although their self-signed certificates do contain a notAfter date, Root Programs and Trust Stores may decide to trust a Root CA beyond that date, or terminate trust in it before that date. As such, the end-of-validity dates given below are approximate, based on current Root Program policies.

These roots are not yet included in Root Program Trust Stores, but will be submitted for inclusion soon:

For additional information on the compatibility of our root certificates with various devices and trust stores, see Certificate Compatibility.

Subordinate (Intermediate) CAs

We currently maintain eight intermediates in active rotation. Subscriber certificates containing an ECDSA public key will be issued from one of the ECDSA intermediates; similarly, Subscriber certificates containing an RSA public key will be issued from one of the RSA intermediates. Subscriber certificates issued under the “classic” and “tlsclient” profiles will be issued from one of the first four intermediates listed (E7 through R13); conversely, Subscriber certificates issued under the “tlsserver” and “shortlived” profiles will be issued from one of the latter four intermediates (YE1 through YR2).

All intermediate certificate Subjects have a Country field of C = US.

Click below for details on additional intermediates which are not part of the active issuance hierarchy:

Backup

These intermediate CAs have currently-valid certificates, but are not being issued from. We may begin issuing Subscriber certificates from them at any time, without warning.

  • Let’s Encrypt E9
    • Subject: O = Let's Encrypt, CN = E9
    • Key type: ECDSA P-384
    • Valid until: 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): crt.sh, der, pem, txt
    • Certificate details (cross-signed by ISRG Root X1): crt.sh, der, pem, txt
    • CRL hostname: e9.c.lencr.org
  • Let’s Encrypt R14
    • Subject: O = Let's Encrypt, CN = R14
    • Key type: RSA 2048
    • Valid until: 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • CRL hostname: r14.c.lencr.org
  • Let’s Encrypt YE3
    • Subject: O = Let's Encrypt, CN = YE3
    • Key type: ECDSA P-384
    • Valid until: 2028-09-02
    • CA details: crt.sh, issued certs
    • Certificate details: der, pem, txt
    • CRL hostname: ye3.c.lencr.org
  • Let’s Encrypt YR3
    • Subject: O = Let's Encrypt, CN = YR3
    • Key type: RSA 2048
    • Valid until: 2028-09-02
    • CA details: crt.sh, issued certs
    • Certificate details: der, pem, txt
    • CRL hostname: yr3.c.lencr.org
Retired

These intermediate CAs are no longer being used to issue Subscriber certificates. Those which still have valid certificates may be producing CRLs.

  • Let’s Encrypt E1
    • Subject: O = Let's Encrypt, CN = E1
    • Key type: ECDSA P-384
    • Valid until: 2025-09-15 (expired)
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): crt.sh, der, pem, txt
    • CRL hostname: e1.c.lencr.org
  • Let’s Encrypt E2
    • Subject: O = Let's Encrypt, CN = E2
    • Key type: ECDSA P-384
    • Valid until: 2025-09-15 (expired)
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): crt.sh, der, pem, txt
    • CRL hostname: e2.c.lencr.org
  • Let’s Encrypt E5
    • Subject: O = Let's Encrypt, CN = E5
    • Key type: ECDSA P-384
    • Valid until: 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): crt.sh, der, pem, txt
    • Certificate details (cross-signed by ISRG Root X1): crt.sh, der, pem, txt
    • CRL hostname: e5.c.lencr.org
  • Let’s Encrypt E6
    • Subject: O = Let's Encrypt, CN = E6
    • Key type: ECDSA P-384
    • Valid until: 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): crt.sh, der, pem, txt
    • Certificate details (cross-signed by ISRG Root X1): crt.sh, der, pem, txt
    • CRL hostname: e6.c.lencr.org
  • Let’s Encrypt R3
    • Subject: O = Let's Encrypt, CN = R3
    • Key type: RSA 2048
    • Valid until: 2025-09-15 (expired)
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • Certificate details (cross-signed by IdenTrust): crt.sh, der, pem, txt
    • CRL hostname: r3.c.lencr.org
  • Let’s Encrypt R4
    • Subject: O = Let's Encrypt, CN = R4
    • Key type: RSA 2048
    • Valid until: 2025-09-15 (expired)
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • Certificate details (cross-signed by IdenTrust): crt.sh, der, pem, txt
    • CRL hostname: r4.c.lencr.org
  • Let’s Encrypt R10
    • Subject: O = Let's Encrypt, CN = R10
    • Key type: RSA 2048
    • Valid until: 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • CRL hostname: r10.c.lencr.org
  • Let’s Encrypt R11
    • Subject: O = Let's Encrypt, CN = R11
    • Key type: RSA 2048
    • Valid until: 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • CRL hostname: r11.c.lencr.org
  • Let’s Encrypt Authority X1
    • Subject: O = Let's Encrypt, CN = Let's Encrypt Authority X1
    • Key type: RSA 2048
    • Valid until: 2020-06-04 (expired)
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • Certificate details (cross-signed by IdenTrust): crt.sh, der, pem, txt
  • Let’s Encrypt Authority X2
    • Subject: O = Let's Encrypt, CN = Let's Encrypt Authority X2
    • Key type: RSA 2048
    • Valid until: 2020-06-04 (expired)
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • Certificate details (cross-signed by IdenTrust): crt.sh, der, pem, txt
  • Let’s Encrypt Authority X3
    • Subject: O = Let's Encrypt, CN = Let's Encrypt Authority X3
    • Key type: RSA 2048
    • Valid until: 2021-10-06 (expired)
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • Certificate details (cross-signed by IdenTrust): crt.sh, der, pem, txt
  • Let’s Encrypt Authority X4
    • Subject: O = Let's Encrypt, CN = Let's Encrypt Authority X4
    • Key type: RSA 2048
    • Valid until: 2021-10-06 (expired)
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • Certificate details (cross-signed by IdenTrust): crt.sh, der, pem, txt

Chains

When an ACME client downloads a newly-issued certificate from Let’s Encrypt’s ACME API, that certificate comes as part of a “chain” that also includes one or more intermediates. Usually this chain consists of just the end-entity certificate and one intermediate, but it could contain additional intermediates. The idea is that, by presenting this whole chain of certificates to a website visitor’s browser, the browser will be able to validate the signatures all the way up to a root that browser trusts without having to download any additional intermediates.

Sometimes there’s more than one valid chain for a given certificate: for example, if an intermediate has been cross-signed, then either one of those two certificates could be the second entry, “chaining up to” either of two different roots. In this case, different website operators may want to select different chains depending on the properties that they care about the most.

Each of the active intermediates above documents which chain is offered by default, and which (if any) additional chains may be requested by ACME clients. In general, chains which terminate at ISRG Root X1 have the largest size but also the greatest compatibility with older clients. Chains which terminate at ISRG Root X2 (only offered for ECDSA certificates) are smaller, but will only work with clients that have received an update to their trust store after 2022 or so. Chains which terminate at Root YE or Root YR will are not expected to work with any of the major trust stores, as those roots have not yet been incorporated.

Subscribers who wish to use one of the alternate chains can reference their ACME client’s documentation for instructions on how to request the alternate chain (for example, certbot’s --preferred-chain flag).

© 2026 Internet Security Research Group