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.

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:

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:

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:

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