I have recently figured out that Lets Encrypt provides "invalid" certificate chain in it's certificates that are pointing to the root certificate that has expired a month ago (they did it apparently to support old android devices that do not fully validate the root certificate validity).

Certificates obviously work for most of the use cases though because there is a newer CA root certificate that OS/browsers do trust. That means that we can see 2 certification paths like on this image:

enter image description here

What I am wondering is what is the algorithm/protocol to figure out if one can trust such certificates where one path is trusted, while the other one is not (there probably can be multiple ones as well). Is it enough that at least one is trusted, or maybe the shortest?


There is no universal algorithm because there is no such standard. Every certificate chaining engine (CCE) implementation uses its own algorithm to select the best chain.

However, most CCE implementations exclude invalid chains if at least one valid chain is found.

If multiple valid chains found, then CCE uses its own algorithm to select the best one. One can decide shortest, other can select with longest validity. There are multiple variables with different weights which can affect the resulting chain.

  • It seems though almost all modern OS/browsers would work with lets encrypt, meaning that at least in this case they would all agree on using the first chain from the image. So even though no universal algorithm exists, there is some common ground? Oct 28 '21 at 9:41
  • 1
    Sure. No one would select invalid chain when there is valid one. It is something every implementation has (or should have) in common. But inner sorting algorithm may vary.
    – Crypt32
    Oct 28 '21 at 9:47
  • 1
    There is such a standard algorithm, it is specified in RFC 5280, section 6. Oct 28 '21 at 15:15
  • 1
    That section explains how to build and validate every singe chain. It doesn't tell how to decide if one chain is better than another (if both are valid, for example).
    – Crypt32
    Oct 28 '21 at 15:17
  • Agreed, I'm also not certain from that algorithm whether path 2 above is valid or not if the ISRG Root X1 is considered a trust anchor. It should be. I would have written the algorithm text differently. Oct 28 '21 at 15:40

I guess you haven't been paying very close attention; we've already had the following Qs https://serverfault.com/questions/1079199/client-on-debian-9-erroneously-reports-expired-certificate-for-letsencrypt-issue
about the LetsEncrypt/DST expiration and problems with things using OpenSSL 1.0.2 (including distros like RedHat/CentOS and Debian/Ubuntu and builds or instances of things like apt curl wget nodejs/npm python etc) which doesn't replace the expired DST bridge with the valid ISRG root if the DST root is (also) still in the truststore. Also see officially https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ and https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.