Long (default) and Short (alternate) Certificate Chains Explained

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:

https://decoder.link/sslchecker/

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

  1. your leaf certificate
  2. R3 signed by ISRG Root X1
  3. ISRG Root X1 signed by DST Root CA X3

Short/Alternate Chain

  1. your leaf certificate
  2. 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.

Related Public Poll

9 Likes
Replacing LE cert due to expiry issue
Public Poll: Which should be the default certificate chain issued by Let's Encrypt?
Warnings in Qualys SSL Server Test - caused by long chain?
R3 issue on Ubuntu 16
Invalid certificate chain
iOS/macOS Calendar (Nextcloud) "Cannot Connect Using SSL"
Why is letsencrypt not fixing DST Root CA X3 issue
Openssl verify fails with E1
Valid certificate deemed invalid in Android app
Certificate verify failed during renewal
Why is letsencrypt not fixing DST Root CA X3 issue
Why do Letsencrypt still add the expired root cert?
Urgent certbot does not update due DNS issue
Can't install successfully(?) issued cert in cPanel
Certificate not valid, expired root
Need some help with My cPanel DV Certificate
LetsEncrypt root certifcate not valid?
Certbot certonly renewed certificate, but openssl shows Certificate has expired
Maybe an intermediate certificate is missing?
Is your test certificate Following Best Practices
SSL certificate is invalid after renewal
Correct ca bundle to use
Users of old devices unable to use my website due to Sept. LE expiration
Ssl security not working with IIS for chrome
HTTPS issue when using letsecrypt
Old ISRG root certificate in chain after renewal
Some visitors cannot access site
Net:err_cert_authority_invalid
Root Certificate expired for Filezilla but not for Firefox
Warning: no valid certs found cafile stream: `/etc/letsencrypt/live/ ...etc
SSL certificate shows warning SSL_ERROR_BAD_CERT_DOMAIN on some browsers and works on others after renewal
SSL Certificate not trusted on mobile
Root certificate expired
Let's Encrypt on Sophos UTM does not work
Chain.pem with two entries - DST Root CA X3 deprecate
SSL not working on Windows 7 running Chrome
Why are LE full chain certs still bundled with ISRG Root X1
SSL not working on various modern browsers (Fine on others)
Check if "--preferred-chain "ISRG Root X1"" is active?
Expired certificate
SSL Expriry Issue
--preferred-chain not taking effect
Ssl encrypt is invalid in the mobile version of Mozilla and Chrome browsers
Ssl encrypt is invalid in the mobile version of Mozilla and Chrome browsers
Help with DST Root CA X3 Expiration
Problem with certificate generated with certbot in vcenter
Site not secure
Since end of September: Mac devices show cert problem on my domain, but not other lets'encrypt encrypted domains
Synolgy 918+ DSM 6.2.2 Update 4 cannot renew certificates
Old smartphones are getting an error message
Universities / enterprise blocking endpoints behind a LE certificate
Android Browser Showing Security Risk or Connection Not Secured

It is not that simple with many clients, they will look in caches of their trust stores instead of their actual stores, this leads to the problem we have seen posted here multiple times where a server administrator changes their server to use the short chain (usually by deleting the expired cert) and clients are still broken - for a while. Maybe up to 24 hours. Then suddenly everthing starts working.

In short, you can fix it and it's still broken. Then suddenly it's not.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.