Reading a Certificate Chain: Leaf, Intermediates and Root in Order

When a browser shows a padlock, it has not simply trusted the certificate a site presented. It has verified a chain: the site's own certificate, called the leaf, was issued by an intermediate certificate, which was in turn issued by a root certificate that the browser already trusts, or by a further intermediate that leads to such a root. If any link in that chain is missing, expired, or inconsistent, the browser cannot complete the verification, and visitors see a warning instead of the site. The SSL Certificate Chain Checker examines certificate text you paste in, checking the order of the chain and the fields that link each certificate to the next, so you can find the missing or misordered link before your visitors do.

A chain is read from the leaf upward. The leaf names the site, in its subject field, and carries the public key the site uses, the validity dates, and the purposes the certificate is allowed for. Its issuer field names the authority that signed it, and that name must match the subject field of the next certificate in the chain, the intermediate. The intermediate, in turn, names its own issuer, which must match the subject of the next certificate, and so on until a root is reached. A root is self-signed, meaning its subject and issuer are the same, and it is trusted because it is present in the browser or operating system's trust store, not because anything in the chain proves it. A chain checker verifies these linkages: each issuer matches the next subject, each signature is consistent with the issuing key, and the basic constraints of each certificate permit it to issue the one below it.

How it works

Checking a pasted chain is a document exercise performed on certificate text you already hold, such as the PEM text of the certificates your server is configured to send. The checker parses each certificate, extracts its subject, issuer, validity dates, and key information, and then assembles the certificates in order, leaf first and root last. It flags the problems that most often break chains in practice. A missing intermediate is the classic one: the server sends only the leaf, and browsers that do not already have the intermediate cached cannot build the path to the root, so the site fails for some visitors while working for others, which makes the fault confusing to diagnose. A misordered chain, where certificates are sent in the wrong sequence, causes similar intermittent failures, because some clients reorder defensively and others do not.

The checker also examines the fields within each certificate. Validity dates matter: a chain is only valid while every certificate in it is within its validity period, so an expired intermediate breaks the whole chain even though the leaf itself is current. The basic constraints extension matters: a certificate that is not marked as a certificate authority must not appear as an intermediate, and a path length constraint, if present, limits how many intermediates may sit below a given authority. The key usage and extended key usage fields matter too: an intermediate must be permitted to sign certificates, and a leaf must be permitted for server authentication. A chain can look complete while failing on one of these details, which is why a field-by-field check is more useful than a glance at the certificate names.

Worked example

Consider a small sample chain of three certificates, with sample values for illustration. The leaf is issued for www.example.com, valid from 1 March 2026 to 1 March 2027, issued by Example Intermediate CA. The intermediate is issued for Example Intermediate CA, valid from 1 January 2025 to 1 January 2030, issued by Example Root CA, and marked as a certificate authority permitted to sign certificates. The root is Example Root CA, self-signed, valid from 1 January 2020 to 1 January 2040, and present in trust stores. Reading the links: the leaf's issuer matches the intermediate's subject, and the intermediate's issuer matches the root's subject, so the chain links correctly. All three certificates are within their validity periods on a sample check date of 1 July 2026, and the intermediate is permitted to issue, so the chain verifies.

Now suppose the server is configured to send only the leaf and the root, omitting the intermediate. A visitor whose browser has never seen Example Intermediate CA cannot link the leaf to the root, because the issuer of the leaf names a certificate the browser does not have, and the root alone does not bridge that gap, since the root's subject does not match the leaf's issuer. The visitor sees a warning. Another visitor who recently visited a different site using the same intermediate may have it cached and see no warning at all. The same misconfiguration thus produces both success and failure, depending on the visitor's history, which is why chain problems are often reported as working for me but broken for customers. The fix is to configure the server to send the leaf and all intermediates, in order, leaving the root optional, since clients already hold it.

Mistakes to avoid

The most common mistake is sending an incomplete chain, usually by omitting intermediates, as the example shows. Always configure the server to send the full chain except the root, and verify the served order after every certificate renewal, because renewals are when chain configurations are most often broken. A second mistake is renewing the leaf and forgetting that an intermediate has also expired or been replaced by the issuing authority. Check every certificate's dates, not just the leaf's, and diary the intermediate's expiry too. A third mistake is mixing certificates from different issuances, such as pairing a new leaf with an old intermediate after a reissue, which breaks the issuer-to-subject linkage and produces a chain that looks complete but does not verify.

A fourth mistake is assuming that a chain that works in one browser works everywhere. Trust stores differ between browsers, operating systems, and devices, and a chain that relies on a root that is trusted on desktops but not on older phones will fail for a slice of visitors. Test the chain on more than one platform after a change. Finally, the handling rule for certificate work is absolute: a checker needs certificate text, which is public, and never needs a private key. Never paste a private key, a keystore password, or any credential into a chain checker or any other web tool. If a private key has been pasted anywhere outside your own systems, treat it as compromised and replace the corresponding certificate.

Putting it into practice

Make chain checking part of every certificate deployment: before switching a server to a new certificate, paste the chain text into the checker, confirm the order, the linkages, the dates, and the authority flags, and only then deploy. After deployment, re-check the served chain, because the file on disk and the chain the server actually sends are not always the same thing. Neighbouring checks include the Certificate Authority Checker for confirming which authority issued a certificate, and the Certificate and Private Key Matcher for confirming that a certificate and its key belong together, a check that must be done locally and never by pasting the private key into an online tool. For background reading, the related guide explains certificate authorities and trust in more detail.

Key points

• A chain links a leaf to a trusted root through intermediates, issuer matching subject at each step
• The server must send the leaf and all intermediates, in order, for every visitor to verify
• An expired or unauthorised intermediate breaks the whole chain, even with a current leaf
• Check pasted certificate text only, and never paste a private key into any checker