Preview of Let's Encrypt's upcoming Root Ceremony

[Aaron Gable]

Hi MDSP!

It's 2025, which means that ISRG Root X1 is a decade old and ISRG Root X2 is five years old. As such, Let's Encrypt is now in the midst of planning the key ceremony which will generate our next generation of root and intermediate certificates. We'd like to share our plans with you today, to get your feedback on the plan and to see if your eyes can catch any potential gotchas that our designs and linters have missed.

The 2025 ceremony will include:

• The creation of a new RSA 4096 root, named Root YR
• The creation of a new ECDSA P-384 root, named Root YE
• Cross-signs of each of those new roots from our old roots, ISRG Root X1 and ISRG Root X2
• A renewal of the cross-sign of ISRG Root X2 from ISRG Root X1, for maximum compatibility
• Three new 2048-bit RSA intermediates under Root YR, named YR1, YR2, and YR3
• Three new ECDSA P-384 intermediates under Root YE, named YE1, YE2, and YE3

You can see preview versions of all of these certificates, in both text and PEM formats, here: ceremony-demos/outputs/2025 at 2025-configs · letsencrypt/ceremony-demos · GitHub

We welcome feedback on all aspects of the above, from glaring issues we're somehow blind to, to the smallest nitpicks. Thank you in advance!

---

For a little bit of background on what's changing between our previous hierarchies and this new one, read on:

1. We are generating two roots instead of just one at a time. This will allow us to move our RSA and ECDSA (and potentially future post-quantum) hierarchies forward in lockstep, without having to worry about different ages and levels of ubiquity between them.
2. Thanks to this generational approach, we've also adopted a new naming scheme. This new generation of our hierarchy is designated as "generation Y" (appropriately following our current "generation X"), with the roots named "Root YR" and "Root YE". The intermediates under each of those roots share their name plus a small integer, so the intermediates are named "YR1", "YR2", etc. Because we'll be able to reset the intermediate numbering every time we issue a new generation of roots, we expect the numbers to stay smaller than our current intermediate "R14".
3. Speaking of names, we're shortening those. Our new roots have a Subject Organization Name of simply "ISRG" (rather than the much longer "Internet Security Research Group"), and we have dropped the redundant "ISRG" from their Subject Common Names. This is part of our constant effort to minimize the number of bytes transmitted during every TLS handshake, to help save global bandwidth.
4. The cross-signs onto these new roots have 7-year validity periods, rather than the 5-year validity period used by our prior X2-by-X1 cross-sign. This is so that the cross-signs won't be quite on the verge of expiring when the time of our next root ceremony (presumably 2030) approaches.
5. We are not cross-signing the intermediates directly from ISRG Root X1, unlike our current ECDSA intermediates. Although this will increase the size of TLS handshakes, it is necessary that the chains presented by servers chain up to both our new and old roots, so that they will be trusted both by user-agents which don't yet trust the new roots and by faster-moving user-agents which remove trust in the old roots as soon as the new ones are distributed.
6. Finally, none of the new intermediates assert the tlsClientAuth Extended Key Usage. This is necessary for acceptance into root programs whose policies require that new applicant hierarchies be serverAuth-only as of this year. This means that all Subscriber certificates issued by this hierarchy will be serverAuth-only, as we already announced.

Thanks again,
Aaron Gable
on behalf of Let's Encrypt

[Aaron Gable]

Hi Sándor,

Good question! The first interpretation is correct. The authorityKeyIdentifier extension is merely RECOMMENDED to be present, but if it is present, then the keyIdentifier field of the extension MUST be present. Section 7.1.2.1.3 should not be interpreted as saying that the keyIdentifier field MUST be present in the certificate. Rather, it says that the keyIdentifier field MUST be present in the authorityKeyIdentifier extension.

For the record, we are choosing not to include the authorityKeyIdentifier extension in our self-signed Root CA Certificates because it is wholly redundant with the subjectKeyIdentifier extension in those same certificates. It is unclear to me why this extension is even RECOMMENDED for Root CA Certificates; in my personal opinion it should be NOT RECOMMENDED.

Aaron

On Wed, Jul 23, 2025 at 6:02 AM Szőke Sándor <szoke....@microsec.hu> wrote:

Hi Aaron,

 

thank you for sharing your plans with us.

We are also planning to set up new hierarchies in the near future, so it's great to see how others are planning to do this to minimize the risk of making sg. wrong.

 

I have reviewed your information and have only one question.

I see that you are not planning to include the authorityKeyIdentifier extension in your new root certificates.

 

CABF TLS BR says:

 

7.1.2.1.2 Root CA Extensions

Extension	Presence	Critical	Description
authorityKeyIdentifier	RECOMMENDED	N	See Section 7.1.2.1.3

 

7.1.2.1.3 Root CA Authority Key Identifier

Field	Description
keyIdentifier	MUST be present. MUST be identical to the subjectKeyIdentifier field.
authorityCertIssuer	MUST NOT be present
authorityCertSerialNumber	MUST NOT be present

 

 

These requirements can be interpreted in two ways, so it may be useful to clarify this issue.

 

• According to the first interpretation, this extension is only RECOMMENDED according to section 7.1.2.1.2, and section 7.1.2.1.3 only needs to be followed if this extension is included in the root certificate. Therefore, it is not a problem if the root certificate does not contain the authorityKeyIdentifier extension.
• According to the other interpretation, both requirements must be met because they are at the same hierarchical level in the BR. The second requirement is not a sub-section of the first chapter and does not contain a clear statement that it only needs to be complied with if this extension is included in the root certificate. According to this logic, the authorityKeyIdentifier MUST be included in the certificate.

 

Which is the correct interpretation of the CABF TLS BR requirement? If it is the second one, it would probably be useful to add some clarifying additions to the second paragraph for greater clarity.

 

Kind Regards,

 

Sándor

 

 

From: 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: Saturday, July 19, 2025 12:31 AM
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Preview of Let's Encrypt's upcoming Root Ceremony

 

Hi MDSP!

It's 2025, which means that ISRG Root X1 is a decade old and ISRG Root X2 is five years old. As such, Let's Encrypt is now in the midst of planning the key ceremony which will generate our next generation of root and intermediate certificates. We'd like to share our plans with you today, to get your feedback on the plan and to see if your eyes can catch any potential gotchas that our designs and linters have missed.

The 2025 ceremony will include:

·         The creation of a new RSA 4096 root, named Root YR

·         The creation of a new ECDSA P-384 root, named Root YE

·         Cross-signs of each of those new roots from our old roots, ISRG Root X1 and ISRG Root X2

·         A renewal of the cross-sign of ISRG Root X2 from ISRG Root X1, for maximum compatibility

·         Three new 2048-bit RSA intermediates under Root YR, named YR1, YR2, and YR3

·         Three new ECDSA P-384 intermediates under Root YE, named YE1, YE2, and YE3

You can see preview versions of all of these certificates, in both text and PEM formats, here: ceremony-demos/outputs/2025 at 2025-configs · letsencrypt/ceremony-demos · GitHub

We welcome feedback on all aspects of the above, from glaring issues we're somehow blind to, to the smallest nitpicks. Thank you in advance!

---

For a little bit of background on what's changing between our previous hierarchies and this new one, read on:

1.      We are generating two roots instead of just one at a time. This will allow us to move our RSA and ECDSA (and potentially future post-quantum) hierarchies forward in lockstep, without having to worry about different ages and levels of ubiquity between them.

2.      Thanks to this generational approach, we've also adopted a new naming scheme. This new generation of our hierarchy is designated as "generation Y" (appropriately following our current "generation X"), with the roots named "Root YR" and "Root YE". The intermediates under each of those roots share their name plus a small integer, so the intermediates are named "YR1", "YR2", etc. Because we'll be able to reset the intermediate numbering every time we issue a new generation of roots, we expect the numbers to stay smaller than our current intermediate "R14".

3.      Speaking of names, we're shortening those. Our new roots have a Subject Organization Name of simply "ISRG" (rather than the much longer "Internet Security Research Group"), and we have dropped the redundant "ISRG" from their Subject Common Names. This is part of our constant effort to minimize the number of bytes transmitted during every TLS handshake, to help save global bandwidth.

4.      The cross-signs onto these new roots have 7-year validity periods, rather than the 5-year validity period used by our prior X2-by-X1 cross-sign. This is so that the cross-signs won't be quite on the verge of expiring when the time of our next root ceremony (presumably 2030) approaches.

5.      We are not cross-signing the intermediates directly from ISRG Root X1, unlike our current ECDSA intermediates. Although this will increase the size of TLS handshakes, it is necessary that the chains presented by servers chain up to both our new and old roots, so that they will be trusted both by user-agents which don't yet trust the new roots and by faster-moving user-agents which remove trust in the old roots as soon as the new ones are distributed.

6.      Finally, none of the new intermediates assert the tlsClientAuth Extended Key Usage. This is necessary for acceptance into root programs whose policies require that new applicant hierarchies be serverAuth-only as of this year. This means that all Subscriber certificates issued by this hierarchy will be serverAuth-only, as we already announced.

Thanks again,
Aaron Gable
on behalf of Let's Encrypt

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErf%3DR5%2Bz8f578jV6OJnJ4PS1bYj90TGh9jca1nq0kmY1sA%40mail.gmail.com.