Five years ago, Let's Encrypt broke out of its private beta and launched a public beta that allowed administrators to request a valid certificate that could be used for encryption with SSL (now TLS). After starting the private beta with 26,000 certificates issued, it has now grown to supporting over 230 million sites and has issued over a billion certificates.
The success of Let's Encrypt was in only provisioning certificates with a limited lifetime – 90 days, to be precise. Before Let's Encrypt, certificates were generally created for an expiry of a year or two. This generally led to people forgetting about renewing the certificates, causing problems when the certificate subsequently expired, such as the Certificate Expiration problem on Azure in 2013. By enforcing a short certificate lifespan, it encouraged the development of automated solutions to acquire and renew certificates periodically. The ACMEv1 protocol was defined and created, and open-source utilities such as Certbot provided an easy means for an operating system to acquire and renew such certificates. The ACMEv1 protocol is now deprecated and the ACMEv2 protocol is now standardised as IETF RFC 8555 and now many ACMEv2 clients are available.
From the start, Let's Encrypt used a top-level certificate (known as the ISRG Root X1 certificate authority root), whose sub-CAs (X1... X4, R3/R4 etc.) that were cross-signed by IdenTrust, which means the certificates are accepted by existing web browsers. This certificate used 4096 bit RSA key and had an expiry in 2025, and although it's still got life left, it will become necessary to replace it with a stronger key in the future.
As a result, in September this year, Let's Encrypt created a new root certificate ISRG Root X2, using ECDSA. The main advantage of using ECDSA is that it results in a much smaller data set, and therefore a fewer number of packets sent in order to obtain the security handshake. In addition, the new root certificate has been submitted to the browsers who look after the certificate stores; although it has not been included in wide systems yet as much as the ISRG Root X1. The ISRG Root X2 certificate is cross-signed with ISRG Root X1 to allow for certificate validation in the interim.
The problem is that the DST X3 certificate, which is currently used by Let's Encrypt to issue certificates, is due to expire in September 2021. As a result, the plans are in place to move towards the ECDSA root for future certificate issuance, but not by default yet. From January 11 next year, the API that serves certificates will return metadata for the certificates to a chain of trust through to the ISRC Root X1 certificate, instead of to the DST X3 certificate.
The ACMEv2 protocol provides an 'alternate' link, which can be used to rollback to the current behaviour, but the key problem is dealing with older operating systems that either don't have the correct root certificate, or don't have support for either the SHA-256 or ECDSA protocols that are used in the process of verifying a certificate. This includes older versions of operating systems, and in particular the blog post highlights that Android operating systems below 7.1 may not be able to process certificates returned by this mechanism. Alternatively, installing a more recent browser such as Firefox Mobile will work, or embedding the Let's Encrypt CA into your app.
More information about the certificates provided by Let's Encrypt can be found on their certificates page, and the community support site has more information about the upcoming changes.
In the space of five years, Let's Encrypt has changed the way in which encrypted communications happen through the automated generation of certificates and the clients and API to make it happen. By moving towards their own root, and moving to a more compact key representation, it will be possible to optimise the setup connection of encrypted data streams as well as moving towards a stronger encryption model.
The changeover on 2021-01-11 to the API will potentially impact older Android clients, and the expiration date of the DST X3 certificate in 2021-09-30 next year is something to watch out for. Bear in mind that the new API will start to return the new root certificate chain but there may be up to 90 days before all existing certificates will be rotated and replaced, so it may be that nothing is visible until February or March.