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 <https://github.com/letsencrypt/ceremony-demos/tree/2025-configs/outputs/2025> 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 <https://letsencrypt.org/certificates/> 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 <https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/>. Thanks again, Aaron Gable on behalf of Let's Encrypt -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErf%3DR5%2Bz8f578jV6OJnJ4PS1bYj90TGh9jca1nq0kmY1sA%40mail.gmail.com.
