In 2024 Q1, Let's Encrypt plans to issue new intermediate keys and certificates. The exact date and time is to be determined. Most ACME clients will automatically configure new intermediate certificates, so no subscriber action should be needed.
Motivation
Previously in 2020, Let’s Encrypt issued six new certificates: one root (ISRG Root X2), four intermediates, and one cross-sign. Those new certificates were part of our larger plan to improve privacy on the web, by making ECDSA end-entity certificates widely available, and by making overall certificate sizes smaller. The existing R3, R4, E1, and E2 intermediate certificates are now more than halfway through their 5 year validity period, so it is time to issue new intermediates to replace them.
New Keys and Certificates
These new intermediates will differ from our previous batch in four ways:
We will be generating 5 RSA and 5 ECDSA intermediates, instead of 2 each. We plan to automatically rotate issuance between multiple intermediates for improved redundancy.
We will be shortening their validity period from 5 years to 3 years, to reflect our commitment to issue new intermediates every 2 years.
They will use SHA256 to compute their Subject Key Identifiers instead of SHA1.
They will only contain the Baseline Requirements Domain Validated Reserved Certificate Policy Identifier (OID 2.23.140.1.2.1).
The five RSA intermediates will be issued from ISRG Root X1, and the five ECDSA intermediates will be issued from ISRG Root X2. In addition, the five ECDSA intermediates will be cross-signed by ISRG Root X1, to allow efficient chain-building even for clients which do not yet have ISRG Root X2 in their trust stores.
In Summary
We will be generating 10 new intermediate keys.
5x 2048 bit RSA keys
5x P-384 ECDSA keys
We will be issuing 15 certificates, each with a validity period of 3 years.
5x RSA intermediate certificates signed by ISRG Root X1
5x ECDSA intermediate certificates signed by ISRG Root X2
5x ECDSA intermediate certificates cross-signed from ISRG Root X1
A demo of this upcoming ceremony, and many of our historical ceremonies, can be found here. You can view the example intermediate certificate PEM and text output here. Please assist us in reviewing these outputs for compliance and correctness. Let us know if you see any errors or oddities that our linting has missed.
I'm curious about the (repeated) choice of key sizes for RSA vs. ECDSA, with P-384 ECDSA intermediates matching the size of their corresponding root, and far exceeding the strength of 2048-bits RSA intermediates and even 4096-bits RSA root certificates.
Is this a conscious choice, or mandated by CAB or other standards?
We don't currently intend to have the string "Int" in the Common Name of the new certificates:
Subject: C = US, O = (FAKE) Let's Encrypt, CN = (FAKE) E5
The "int" is just in the filenames, not in the actual contents. You're suggesting that the CN be Int E5?
These are separate, unrelated events. DST Root CA X3 has cross-signed our ISRG Root X1, which will be issuing (or cross-signing) all of the new intermediates. So the longer compatibility chain will still be valid even for certs issued from these new intermediates. The deprecation timeline outlined in the post you linked remains the same.
Given how frequently our intermediate certificates are sent over the internet, we're deeply concerned with the size of the certificates and their signatures. Using a larger RSA key would greatly increase the number of bytes sent over the wire in every TLS handshake, and the expert consensus is that RSA 2048 will remain unbroken for the whole lifetime of these new intermediates. But ECDSA keys are so much smaller that we can afford to use a higher-security key without increasing the certificate size too much.
This is a continuation of the same decision we made last time, to only issue E1, E2, R3, and R4. We've gone back and forth on this a lot, but the general idea is to make it so that if someone does a simple typo (changing either E to R, or one number to another) it's much easier to catch that typo because the result is likely to be a certificate name that doesn't actually exist.
Like @aarongable mentioned, we're using the same cryptographic algorithms as the existing E1, E2, R3, and R4 intermediates. The list of acceptable algorithms is mandated by the CA/Browser Forum section 7.1.3.
Correct that we're skipping those ranges. When we first issued the Let's Encrypt Authority X[1-4] intermediates we chose sequential numbering for the Subject Name. When we issued E1, E2, R3, and R4 we began a disjointed scheme instead. From a support perspective, image a scenario where a relying party posts, "I can't issue for R99", and a poster on the community forum may respond, "Let's Encrypt doesn't even offer R99. I think you meant E99 instead which does exist. By the way, here's your potential real issue [etc]." The goal there is less time getting to a proper solution rather than a few back and forth messages.
That's cool, it reminds me a lot of aircraft terminal/gate numbering at some airports where the numeric part of the gate number is unique airport-wide, but the terminal letter is also incorporated into the number (so you couldn't have both gate A10 and B10 at the same airport).
I just ask that the number "3" never be used again. Having "DST Root CA X3", "Let's Encrypt Authority X3", and "R3" caused a lot of confusion when the last intermediates were made. In particular, please never make a "ISRG Root X3" even though you'll be tempted to.
Yeah, giving these certs/keys actual names, like from the names of animals, or atomic elements, or characters from one's favorite sci-fi series, or whatever might make the most sense. (And might help mitigate the thought some might have that getting intermediate "6" is newer or more improved in some way than intermediate "5" when it's really just based on which data center processed the request in some way.) Let's Encrypt already seems to like naming projects after things from nature (between "Boulder", "Oak", "Sapling", and recently "Hickory"); I certainly wouldn't be opposed to naming certificates after types of trees or types of rocks or whatever as well.
That's where the name ACME comes from. Boulder was actually originally going to be named Anvil, but it turned out there was already some software (I guess in a possibly confusingly-adjacent field) named Anvil.
The production CT logs are (currently) a combination of trees that intersect with Pokemon professor names. We were going for very woody names. For test logs we wanted to set them completely apart so we went with Testflume and Sapling so there would be, hopefully, no connection to the mighty production logs/trees.
If you named some intermediates based on regular Pokemon, and then with a certain size donation to Let's Encrypt got access to having certs signed by an intermediate with a "shiny" or "rare" Pokemon name, then we just might be able to increase Let's Encrypt's budget significantly.
(Would need to get some sort of sponsorship from The Pokemon Company for permission to use the names, but I'm sure that's the least of the problems with this plan…)
Thanks to some great feedback we received on MDSP, we have updated the ceremony to use a SHA-256 hash truncated to the first 160 bits (the same length as a SHA-1 hash) for the SubjectKeyIdentifier, so that we can simultaneously stop using SHA-1 and not increase the size of the new certificates.
