Web · guide

What is an SSL certificate chain, and why one link goes missing

By Alberto Gulotta · Updated 23 September 2026 · 9 min read

Two symptoms send people to the phrase what is an SSL certificate chain: a site that works in one browser and throws a security warning in another, and a checker that calls the certificate valid and the chain incomplete. They are the same fault seen from two angles, and both certificate authorities quoted below point at the same link.

The ordering is the part worth holding on to, because it explains the whole mechanism in one move. Nothing in the chain vouches for itself. Your certificate is trusted because the intermediate signed it, the intermediate is trusted because the root signed it, and the root is trusted because it is already sitting in the device — put there by whoever made the browser or the operating system. Trust is not transmitted by your server; it is met halfway.

Once that is clear, the failure mode stops being mysterious. Your server sends what it was given. If it sends only your certificate, the device at the other end is left holding a signature from an intermediate it may never have seen, and a root it does have — with nothing connecting the two.

Which makes the practical instruction narrower than most troubleshooting advice. The fix is not a new certificate at all. It is the file your server is configured to send. The intermediate is published by the certificate authority — Let’s Encrypt lists its own on the page quoted here, in downloadable form — and the job is to make sure your server presents it alongside your certificate. A certificate that was never invalid does not become more valid by being reissued.

The published record shows how those extra certificates arise. Let’s Encrypt lists its first root, ISRG Root X1, with a certificate “cross-signed by DST Root CA X3” that is now marked retired; its newer roots appear as cross-signed too, and are described as “not yet included in Root Program Trust Stores”. Put those two facts side by side — a root that trust stores have not yet accepted, and a signature on it from one they have — and the purpose of a cross-signature is fairly clear, though it is a reading of the record rather than a sentence Let’s Encrypt writes on that page.

So a chain can be longer than it strictly needs to be, on purpose, for the benefit of devices you cannot see. That is the real answer to why two servers with certificates from the same authority can present chains of different lengths, and why the shorter one is not automatically the better choice.

And one thing that is not like the rest of the certificate world. Roots do not expire the way your certificate expires. Let’s Encrypt: although a root’s self-signed certificates “do contain a notAfter date, Root Programs and Trust Stores may decide to trust a Root CA beyond that date, or terminate trust in it before that date.” So the lifetime of the thing at the top of your chain is decided by browser and operating-system vendors rather than by the date printed inside it — which is why a chain can stop working on a device that has stopped receiving updates, without anything on your server changing at all.

The guides below take it three ways: the three links and what each one is for, the missing intermediate and how to tell that is what you have, and the trust stores that decide the whole question from the far end.

Not covered here. It will not tell you to buy a certificate to fix a chain. A missing intermediate is a server configuration problem, and the intermediate was supplied with the certificate you already have.

It will not tell you the shortest chain is the best one. Cross-signing makes chains longer on purpose, so that devices which will never be updated can still reach a root they trust.

And it will not rank certificate authorities. That would need paid accounts and real renewals across a year, and this guide is about how the chain works rather than whose to buy. What holds instead is simple: the definition of a certificate chain is DigiCert’s, while the reason intermediates exist and the note on root expiry come from Let’s Encrypt.