Let's Encrypt have just issued a bunch of new certificates including a new Root and several Intermediates. These will bring some significant advantages so let's dive in and take a look at what's coming!
A blog of two halves
I've been following along with interest as Let's Encrypt, and other CAs, come towards the end of life on their existing CA certificates, more specifically their Root CA Certificates. We had a bit of an issue with an expiring root recently that I did blog about and the next big victim to the relentless march of time is Let's Encrypt.
There are two main things to cover in this blog post and Let's Encrypt issuing new CA certificates is directly related to both of them. One of them is quite important and related to the fairly extensive 4-part series of blogs I recently published on CAs, CA Certificates and all of the problems and complexities that surround them.
The Impending Doom of Expiring Root CAs and Legacy Clients
The Complexities of Chain Building and CA Infrastructure
Cross-Signing and Alternate Trust Paths; How They Work
Finding alternate trust paths the easy way; Introducing Chain Builder
We have a big problem looming with the expiration of the current Root CA certificate that Let's Encrypt are cross-signed by and one of the changes to look at are about staving off that issue a little longer. The other one is that Let's Encrypt have previously issued ECDSA certificates but signed them with their RSA (only) chain. They are now introducing the ability to have ECDSA certificates issued by an ECDSA chain!
Extending the life on the cross-signature
Let's Encrypt came to life with a cross-sign from the IdenTrust DST Root CA X3 certificate. This is a fully trusted and well distributed Root CA that allowed Let's Encrypt to start issuing certificates immediately, all the way back in 2016. Let's Encrypt have a total of 4 Intermediate CA certificates signed, two that are no longer used, Let's Encrypt Authority X1 and Let's Encrypt Authority X2, the current Intermediate CA certificate Let's Encrypt Authority X3 and a backup Let's Encrypt Authority X4. As you can see by looking at the information on the X3 and X4 intermediates, they both expire in March 2021.
There's a very simple solution to an expiring Intermediate CA certificate and it's to issue a new one. There's no particular problem or hardship with issuing a new Intermediate CA and it happens quite frequently as you can see that they are only valid for 5 years anyway. The problem comes from the IdenTrust DST Root CA X3 expiring very soon, in September 2021.
Of course you can't issue an Intermediate CA with a longer lifespan than the Root CA that signed it so there is an upper limit here. Of course Let's Encrypt knew this problem was coming and have the ISRG Root X1 certificate ready to go and it has plenty of life left in it.
The problem with the ISRG Root X1 though is root distribution and I cover that in great detail in one of the blogs I linked at the start of this blog: The Impending Doom of Expiring Root CAs and Legacy Clients. The problem is that the ISRG Root X1 isn't quite ready to go yet as it hasn't been widely distributed and I've already written twice about this issue in Let's Encrypt to transition to ISRG root and Let's Encrypt postpone the ISRG Root transition. The IdenTrust Root is expiring and the ISRG Root isn't quite ready to go, it's a bit of a pickle!
The New RSA Intermediate CA Certificates
To tackle the pending expiration of the existing X3 and X4 intermediates, and to help with the Root CA expiration/distribution issue, two new Intermediate CA certificates have been issued; Let's Encrypt R3 and Let's Encrypt R4. These are basically direct replacements for X3 and X4 (with the R for RSA) and exist as an intermediate signed by the ISRG Root X1 and the IdenTrust DST Root CA X3.
Let's Encrypt R3 (ISRG signed)
Let's Encrypt R3 (IdenTrust signed)
Let's Encrypt R4 (ISRG signed)
Let's Encrypt R4 (IdenTrust signed)
As you can see from the certificates the R3 and R4 that are cross-signed are limited in their lifespan due to the IdenTrust Root CA expiring soon:
The same R3 and R4 certificates issued by the ISRG Root CA do not have the same limitations though.
This means that those who depend on the legacy IdenTrust Root CA can continue to serve a chain through the cross-signed R3 or R4 intermediates right up until the expiry of the IdenTrust Root CA. Everyone else will switch to the R3 chain soon when Let's Encrypt have said they will be changing the Intermediate CA certificate that they provide by default.
The New ECDSA Root and Intermediate Certificates
Another great thing to come with all of these changes is a whole new Root CA certificate and matching Intermediate CA certificates using ECDSA keys instead of RSA Keys. If any of you have followed my blog or attended my TLS Training course you will know that ECDSA keys are smaller, faster and more secure than their RSA counterparts, that's win, win, win! The new ISRG Root X2 and Let's Encrypt E1 and Let's Encrypt E2 intermediate certificates are all issued and ready to go but of course the issue is, again, root distribution of the X2 root. To combat this the X2 root is cross-signed by the X1 root so most clients will be able to chain through an almost exclusively ECDSA chain to the X1 and eventually they get the X2 root and the chain will end there. This means no further changes are required by server operators in the future but for now the ability to serve a chain that's exclusively ECDSA will be limited. The question may come up about cross-signing the E1 and E2 intermediates directly with the X1 root and whilst that shortens the served chain in the short term, it's not the best play in the long term as another chain switch would be required in the future.
I was going to create a diagram to show all of this but the actual diagram provided by Let's Encrypt is of course the best one there's going to be, so here it is:
That's how the new infrastructure looks and it's giving us basically the best of everything. Those who need the legacy IdenTrust root have new intermediates to get them all the way to expiry, we have new Let's Encrypt intermediates to replace the ones expiring soon and after much anticipation we now have ECDSA infrastructure becoming available.
Making things even faster!
Yes, that's right, there were actually quite a few sneaky performance advantages in this recent batch of changes too and some of them, I have to say, are pretty creative. First of all let's remember that every time you initiate a TLS connection the server must send certificates to the client for authentication. At a minimum this is going to require the server certificate and at least 1 intermediate certificate. This quite literally requires sending at least 2 files to the client to initiate the connection and those files have size which means bytes on the wire. If you can reduce the size of certificates you can initiate a connection faster!
ECDSA keys are smaller
As I said earlier, ECDSA keys are smaller than RSA keys and smaller keys in the certificates means smaller certificates. A 2048-bit RSA key is ~256 bytes in size compared to a ECDSA P-384 public key which is ~48 bytes, considerably smaller. This is the size reduction of the keys in the Let's Encrypt E1 and E2 intermediates compared to the X3/X4/R3/R4 intermediates. Depending on the key you use for your server certificate you could also have a similar size reduction in that although using an ECDSA key has always been possible with the previous X3/X4 RSA chain. You can further reduce the size of the key in the server certificate too as you will most likely be using P256 or x25519 for that.
Better naming
Alongside the keys we've just mentioned there is other data inside certificates too, like the information about the subject (the entity the certificate belongs to). Let's take a look at the subject field in the X3 Intermediate certificate.
C=US
O=Let's Encrypt
CN=Let's Encrypt Authority X3Now let's take a look at the subject for the new R3 intermediate.
C=US
O=Let's Encrypt
CN=R3That's a pretty easy way to save 24 bytes in the certificate without actually losing any useful information at all!
Reducing or removing fields
As with the subject information above there is even more data contained within a certificate and I've selected a few fields for us to look at within the X3 intermediate here.
Authority Information Access:
OCSP - URI:http://isrg.trustid.ocsp.identrust.com
CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.identrust.com/DSTROOTCAX3CRL.crl
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.root-x1.letsencrypt.orgAgain, taking a look at the new R3 intermediate (issued by ISRG Root X1) we can see a few changes.
Authority Information Access:
CA Issuers - URI:http://x1.i.lencr.org/
X509v3 CRL Distribution Points:
Full Name:
URI:http://x1.c.lencr.org/
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1Some of the URLs in there have been shortened quite a bit or even removed entirely, again saving valuable bytes on the wire.
Encrypt all the things!
All of the above changes are really important and if we want to encrypt the entire Web then we need to keep tackling the real problems that exist. The new R3/R4 cross-signs will allow people to keep using the legacy chain to support legacy devices right up until that's no longer possible. The new ECDSA chain will allow people to chase those performance advantages where it's really important. Making certificates smaller will benefit literally every single person that uses TLS every single day. All in all this a great set of improvements to the TLS ecosystem and I look forward to future changes from Let's Encrypt and other CAs that will follow suit.
Here's to making encryption on the Web even better! 🍾🥂💚🔒🌍