If you're wondering about the long/default and short/alternate certificate chains and their relationship to the recent DST Root CA X3 expiration, you're in the right place.
Which chain am I using?
You can check here:
What are these chains?
The certificate chain is the list of certificates that you receive from your ACME client when you acquire/renew a certificate. This list includes your leaf certificate, which corresponds to a private key that you hold, and one or more intermediate certificates. At present, there are two chains available...
Long/Default Chain
- your leaf certificate
- R3 signed by ISRG Root X1
- ISRG Root X1 signed by DST Root CA X3
Short/Alternate Chain
- your leaf certificate
- R3 signed by ISRG Root X1
As you can see, the long/default chain includes an additional intermediate certificate. What might be confusing is that that intermediate certificate appears to be a root certificate. This requires further explanation, which is presented below.
Why use one chain or the other?
Section contributed by @schoen and edited by @griffin
Let's Encrypt created the two chain options because of trade-offs in compatibility with older software connecting to websites/services that are secured with Let's Encrypt certificates following the expiration of the self-signed DST Root CA X3 certificate on September 30, 2021 at 02:01:15 PM GMT/UTC.
-
The long chain (recommended for most websites/services) maintains compatibility with older Android clients at the cost of losing compatibility with some clients using older versions of OpenSSL and other libraries. The incompatible clients are often servers connecting to an API secured with a Let's Encrypt certificate, but may also include some other operating systems. The long chain is likely to be flagged as invalid by security scanning tools, which can cause headaches for audits even though there is no actual security risk.
-
The short chain maintains compatibility with some clients using older versions of OpenSSL and other libraries at the cost of losing compatibility with older Android clients. The short chain is likely to be flagged as valid by security scanning tools.
Unfortunately, some devices may be compatible with one of the chains but not the other, so both choices may have disadvantages. Most devices that are incompatible with one chain or the other are running software that is no longer receiving security updates from their vendors; devices that still receive updates have usually been offered an update that eliminates these incompatibilities. Unfortunately, devices that are no longer being updated are also still widespread on the Internet.
There are also some older devices that are no longer compatible with either chain. These devices include all those running software listed in the second section of:
For incompatible devices, there is often a way that the device owner can manually upgrade an individual device to restore compatibility (e.g. by manually adding the ISRG Root X1 certificate to the local trusted certificates list (trust store) or installing a different web browser). However, a server administrator usually cannot restore compatibility to clients by itself.
Handling the DST Root CA X3 Expiration
The standard RSA root certificate used by Let's Encrypt is the self-signed ISRG Root X1 certificate. However, not all devices have that root certificate installed, primarily due to it being a fairly young root certificate (June 4, 2015 at 11:04:38 AM GMT/UTC). To extend compatibility, Let's Encrypt decided to also use a cross-signed ISRG Root X1 certificate signed by the self-signed DST Root CA X3 certificate, a much older root certificate (September 30, 2000 at 09:12:19 PM GMT/UTC). While both versions of the ISRG Root X1 certificate contain the same public key, the cross-signed version is an intermediate certificate intended to be served in tandem with the R3 intermediate certificate to enable verification of the certificate chain if the self-signed ISRG Root X1 certificate is not installed, but the self-signed DST Root CA X3 certificate is installed. With the expiration of the self-signed DST Root CA X3 certificate on September 30, 2021 at 02:01:15 PM GMT/UTC, only devices that ignore said expiration, such as some older Android devices, still benefit from the compatibility extension effort. Since the self-signed DST Root CA X3 certificate is expired, requests for its certificate revocation list (CRL) will result in failures that can be safely ignored.
The full operation is as follows:
- For the long chain, many clients/browsers will work down the chain from the leaf certificate until they encounter the R3 intermediate certificate signed by ISRG Root X1 and look for the self-signed ISRG Root X1 trust anchor in their trust stores. If said trust anchor is found, the chain validation will succeed. Otherwise, they will proceed to the ISRG Root X1 intermediate certificate and look for the self-signed DST Root CA X3 trust anchor in their trust stores. If said trust anchor is found on an older Android device, the expiration of the self-signed DST Root CA X3 trust anchor will be ignored and the chain validation will succeed. Otherwise, the chain validation will fail.
- For the short chain, clients/browsers will work down the chain from the leaf certificate until they encounter the R3 intermediate certificate signed by ISRG Root X1 and look for the self-signed ISRG Root X1 trust anchor in their trust stores. If said trust anchor is found, the chain validation will succeed. Otherwise, the chain validation will fail.