Let’s Encrypt will be issuing new intermediates and a new root certificate in the coming months. We’re publishing our proposed issuances so we can get feedback from the community and root programs about these plans and potentially make them better.
Goals:
- We want to offer an all-ECDSA hierarchy, for smaller TLS certificate chains and faster verification by clients.
- We need to generate new RSA intermediates to replace Let’s Encrypt Authority X3 and Let’s Encrypt Authority X4, which have cross-signs expiring in March 2021.
- We want to get additional cross-signatures on some of our intermediates from IdenTrust’s DST Root X3. This will extend our trust on older devices (including Android pre-7.1). The new cross-signs will expire September 2021.
Some questions for discussion:
Should we generate just the P-384 root, or also a P-256 root? The latter would make ECDSA chains use slightly fewer bytes on the wire. But since roots are long-lived it’s somewhat preferable to use the stronger P-384 curve.- What should the names be? As an initial proposal, I’m tweaking our existing naming scheme to use Xn to identify the new root, but Yn to identify new intermediates. And replacing “Authority” with “Intermediate” for the intermediates. Should certificate names also mention their key type? I’m leaning “no” since it’s easy to find that in the certificate itself. But including it in the name makes it easier to see the purpose of a given certificate if you are only looking at a list of Subject DNs. Also I’m proposing to use “Let’s Encrypt” in the new root certificate’s name to match our intermediates and the most commonly recognized name for our service.
- Should we get additional cross-signs from DST Root X3 on the new ECDSA intermediates? I’m thinking “no”, since the ECDSA hierarchy is mainly intended to be forward-looking rather than emphasizing backwards compatibility. We will, however, be bootstrapping the new ECDSA root from our own ISRG Root X1, which is already in modern root stores.
Planned Certificates:
Subject: CN = Let’s Encrypt Root X2, O = Let’s Encrypt, C = US
Key type: ECDSA P-384
Signed by: self-signed
Expires: September 17 2040 16:00
Purpose: New root. Submit to root programs.
Subject: CN = Let’s Encrypt Root X2, O = Let’s Encrypt, C = US
Key type: ECDSA P-384
Signed by: ISRG Root X1
Expires: June 4 2035 11:04 (expiration of ISRG Root X1)
Purpose: Cross-signature of new root from our existing root. Allows building a chain with broad compatibility.
Subject: CN = Let’s Encrypt Root OCSP X2, O = Let’s Encrypt, C = US
Key type: ECDSA P-384
Signed by: Let’s Encrypt Root X2
Expires: September 15 2025 16:00
Purpose: Delegated OCSP signer, signing responses for intermediates.
Subjects: CN = Let’s Encrypt Intermediate E1 & E2, O = Let’s Encrypt, C = US
Key type: ECDSA P-384
Signed by: Let’s Encrypt Root X2
Expires: September 15 2025 16:00
Purpose: E1 will be our primary issuance certificate for ECDSA leaf certificates. E2 will be used for disaster recovery in case we lose the ability to issue with E1.
Subjects: Let’s Encrypt Intermediate R3 & R4, O = Let’s Encrypt, C = US
Key type: RSA 2048
Signed by: ISRG Root X1
Expires: September 15 2025 16:00
Purpose: These will replace “Let’s Encrypt Authority X3” and “Let’s Encrypt Authority X4.” R3 will be our primary issuance certificate for RSA leaf certificates, and R4 will be used for disaster recovery.
Cross-signs: We will have R3 and R4 cross-signed by DST Root X3 so that subscribers who need compatibility with older Android devices can continue to serve them until the September 30 2021 expiration of DST Root X3.
[Edit 2020-07-21: Changed Y1 & Y2 -> E1 & E2. Also changed Y3 & Y4 -> R1 and R2. This make the names reflect the type of key in the certificates]
Makes sense if you want to keep your root included in all the major browsers. 
