Chains of Trust

หน้าเว็บนี้ยังไม่ได้รับการแปล คุณสามารถมีส่วนช่วยได้ ที่นี่

ปรับปรุงครั้งสุดท้าย:

Note: This section describes Let’s Encrypt’s hierarchy as of June 6, 2024. For the hierarchy in use prior to June 6, see below.

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.

ISRG Certificate Hierarchy Diagram, as of June 2024

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.

  • ISRG Root X1
    • Subject: O = Internet Security Research Group, CN = ISRG Root X1
    • Key type: RSA 4096
    • Validity: until 2030-06-04 (generated 2015-06-04)
    • CA details: crt.sh, issued certs
    • Certificate details (self-signed): crt.sh, der, pem, txt
    • Certificate details (cross-signed by DST Root CA X3): crt.sh, der, pem, txt (retired)
    • Test websites: valid, revoked, expired
  • ISRG Root X2
    • Subject: O = Internet Security Research Group, CN = ISRG Root X2
    • Key type: ECDSA P-384
    • Validity: until 2035-09-04 (generated 2020-09-04)
    • CA details: crt.sh, issued certs
    • Certificate details (self-signed): crt.sh, der, pem, txt
    • Certificate details (cross-signed by ISRG Root X1): crt.sh, der, pem, txt
    • Test websites: valid, revoked, expired

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 four 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.

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

  • Let’s Encrypt E5
    • Subject: O = Let's Encrypt, CN = E5
    • Key type: ECDSA P-384
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): der, pem, txt
    • Certificate details (cross-signed by ISRG Root X1): der, pem, txt
  • Let’s Encrypt E6
    • Subject: O = Let's Encrypt, CN = E6
    • Key type: ECDSA P-384
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): der, pem, txt
    • Certificate details (cross-signed by ISRG Root X1): der, pem, txt
  • Let’s Encrypt R10
    • Subject: O = Let's Encrypt, CN = R10
    • Key type: RSA 2048
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): der, pem, txt
  • Let’s Encrypt R11
    • Subject: O = Let's Encrypt, CN = R11
    • Key type: RSA 2048
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): der, pem, txt

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 E7
    • Subject: O = Let's Encrypt, CN = E7
    • Key type: ECDSA P-384
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): der, pem, txt
    • Certificate details (cross-signed by ISRG Root X1): der, pem, txt
  • Let’s Encrypt E8
    • Subject: O = Let's Encrypt, CN = E8
    • Key type: ECDSA P-384
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): der, pem, txt
    • Certificate details (cross-signed by ISRG Root X1): der, pem, txt
  • Let’s Encrypt E9
    • Subject: O = Let's Encrypt, CN = E9
    • Key type: ECDSA P-384
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): der, pem, txt
    • Certificate details (cross-signed by ISRG Root X1): der, pem, txt
  • Let’s Encrypt R12
    • Subject: O = Let's Encrypt, CN = R12
    • Key type: RSA 2048
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): der, pem, txt
  • Let’s Encrypt R13
    • Subject: O = Let's Encrypt, CN = R13
    • Key type: RSA 2048
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): der, pem, txt
  • Let’s Encrypt R14
    • Subject: O = Let's Encrypt, CN = R14
    • Key type: RSA 2048
    • Validity: until 2027-03-12
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X1): der, pem, txt
Retired

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

  • Let’s Encrypt E1
    • Subject: O = Let's Encrypt, CN = E1
    • Key type: ECDSA P-384
    • Validity: until 2025-09-15
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): crt.sh, der, pem, txt
  • Let’s Encrypt E2
    • Subject: O = Let's Encrypt, CN = E2
    • Key type: ECDSA P-384
    • Validity: until 2025-09-15
    • CA details: crt.sh, issued certs
    • Certificate details (signed by ISRG Root X2): crt.sh, der, pem, txt
  • Let’s Encrypt R3
    • Subject: O = Let's Encrypt, CN = R3
    • Key type: RSA 2048
    • Validity: until 2025-09-15
    • 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 R4
    • Subject: O = Let's Encrypt, CN = R4
    • Key type: RSA 2048
    • Validity: until 2025-09-15
    • 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 X1
    • Subject: O = Let's Encrypt, CN = Let's Encrypt Authority X1
    • Key type: RSA 2048
    • Validity: expired 2020-06-04
    • 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
    • Validity: expired 2020-06-04
    • 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
    • Validity: expired 2021-10-06
    • 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
    • Validity: expired 2021-10-06
    • 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
Delegated OCSP Responder

This keypair was previously used to sign OCSP responses regarding the status of Let’s Encrypt’s intermediates on behalf of Let’s Encrypt’s root, so that the root could remain safely offline. We no longer issue OCSP responses for our intermediates; we instead periodically issue CRLs from our root to convey the revocation status of our intermediates.

  • ISRG Root OCSP X1
    • Subject: O = Internet Security Research Group, CN = ISRG Root OCSP X1
    • Key type: RSA 2048
    • Validity: until 2025-06-10
    • Certificate details (signed by ISRG Root X1): crt.sh, der, pem, txt
    • Certificate details (signed by ISRG Root X1): crt.sh (expired)

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.

Subscriber certificates with RSA public keys are issued from our RSA intermediates, which are issued only from our RSA root ISRG Root X1 (i.e. they are not cross-signed). Therefore, all RSA subscriber certificates have only a single chain available:

RSA Subcriber Cert ← RSA Intermediate (R10 or R11) ← ISRG Root X1

Subscriber certificates with ECDSA public keys are issued from our ECDSA intermediates, which are issued both (i.e. are cross-signed) from our RSA root ISRG Root X1 and our ECDSA root ISRG Root X2. Therefore we offer two chains for these certificates:

ECDSA Subcriber Cert ← ECDSA Intermediate (E5 or E6) ← ISRG Root X1

ECDSA Subcriber Cert ← ECDSA Intermediate (E5 or E6) ← ISRG Root X2

The first chain, up to ISRG Root X1, provides the greatest compatibility because that root certificate is included in the most trust stores. The second chain, up to ISRG Root X2, consumes fewer bytes of network bandwidth in each TLS handshake. We provide the first chain by default, to ensure the widest compatibility. Subscribers who wish to prioritize size over compatibility can reference their ACME client’s documentation for instructions on how to request the alternate chain (for example, certbot’s --preferred-chain flag).






Note: This section describes Let’s Encrypt’s hierarchy as it historically has been, prior to the the changes on June 6, 2024.

ISRG Certificate Hierarchy Diagram, as of December 2020

Root Certificates

Our roots are kept safely offline. We issue end-entity certificates to subscribers from the intermediates in the next section. For additional compatibility as we submit our new Root X2 to various root programs, we have also cross-signed it from Root X1.

We’ve set up websites to test certificates chaining to our active roots.

Intermediate Certificates

Under normal circumstances, certificates issued by Let’s Encrypt will come from “R3”, an RSA intermediate. Currently, issuance from “E1”, an ECDSA intermediate, is possible only for ECDSA subscriber keys for allowlisted accounts. In the future, issuance from “E1” will be available for everyone.

Our other intermediates (“R4” and “E2”) are reserved for disaster recovery and will only be used should we lose the ability to issue with our primary intermediates. We do not use the X1, X2, X3, and X4 intermediates anymore.

IdenTrust has cross-signed our RSA intermediates for additional compatibility.

Cross Signing

Intermediates

Each of our intermediates represents a single public/private key pair. The private key of that pair generates the signature for all end-entity certificates (also known as leaf certificates), i.e. the certificates we issue for use on your server.

Our RSA intermediates are signed by ISRG Root X1. ISRG Root X1 is widely trusted at this point, but our RSA intermediates are still cross-signed by IdenTrust’s “DST Root CA X3” (now called “TrustID X3 Root”) for additional client compatibility. The IdenTrust root has been around longer and thus has better compatibility with older devices and operating systems (e.g. Windows XP, Android 7). You can download “TrustID X3 Root” from IdenTrust (or, alternatively, you can download a copy from us).

Having cross-signatures means that each of our RSA intermediates has two certificates representing the same signing key. One is signed by DST Root CA X3 and the other is signed by ISRG Root X1. The easiest way to distinguish the two is by looking at their Issuer field.

When configuring a web server, the server operator configures not only the end-entity certificate, but also a list of intermediates to help browsers verify that the end-entity certificate has a trust chain leading to a trusted root certificate. Almost all server operators will choose to serve a chain including the intermediate certificate with Subject “R3” and Issuer “ISRG Root X1”. The recommended Let’s Encrypt client software, Certbot, will make this configuration seamlessly.

Roots

Similar to intermediates, root certificates can be cross-signed, often to increase client compatibility. Our ECDSA root, ISRG Root X2 was generated in fall 2020 and is the root certificate for the ECDSA hierarchy. It is represented by two certificates: one that is self-signed and one that is signed by ISRG Root X1.

All certificates signed by the ECDSA intermediate “E1” will come with a chain including an intermediate certificate whose Subject is “ISRG Root X2” and whose Issuer is “ISRG Root X1”. Almost all server operators will choose to serve this chain as it offers the most compatibility until ISRG Root X2 is widely trusted.

OCSP Signing Certificate

This certificate is used to sign OCSP responses for the Let’s Encrypt Authority intermediates, so that we don’t need to bring the root key online in order to sign those responses. A copy of this certificate is included automatically in those OCSP responses, so Subscribers don’t need to do anything with it. It is included here for informational purposes only.

Our newer intermediates do not have OCSP URLs (their revocation information is instead served via CRL), so we have not issued an OCSP Signing Cert from ISRG Root X2.

Certificate Transparency

We are dedicated to transparency in our operations and in the certificates we issue. We submit all certificates to Certificate Transparency logs as we issue them. You can view all issued Let’s Encrypt certificates via these links: