TLS Certificate Chain Explained

The three kinds of certificate in a chain

Your server presents a leaf certificate — the one issued for your domain name. That leaf is signed by an intermediate certificate belonging to a certificate authority, and the intermediate is signed by a root certificate. The root is the anchor everything else depends on.

The chain exists so that root keys can be kept offline and rarely used, while day-to-day issuance happens through intermediates that can be rotated or revoked without disturbing every browser on earth.

How browser trust stores decide what is valid

Every browser and operating system ships a trust store: a curated list of root certificates it accepts. A connection is trusted when the browser can build a path from your leaf certificate up to a root already in its trust store, and every signature and validity date along that path checks out.

Trust stores differ between vendors and versions. That is why a chain can appear valid on a current desktop browser and fail on an older phone, an embedded device or a payment terminal.

Incomplete chains: the classic misconfiguration

Your server must send the leaf certificate and the intermediates. Roots do not need to be sent, because the client already has them. If the intermediates are missing, some clients will silently fetch them and succeed while others fail outright — which is exactly why this problem gets reported as intermittent.

If a site works in one browser and errors in another, an incomplete chain is the first thing to check. Fix it by configuring the server to serve the full chain file your certificate authority provides, not the leaf certificate alone.

Expiry, renewal and automation

Every certificate in the path has a validity window, and the shortest one governs. Leaf certificates now expire frequently by design, so manual renewal is a recurring outage risk rather than an annual chore.

Automate issuance and renewal, and make sure the renewal process also updates the intermediate chain and reloads the service afterwards. A renewed certificate that was never loaded is a surprisingly common cause of expiry alerts.

• Automate renewal and confirm the service reloads after each renewal.
• Serve the full chain, including intermediates.
• Cover every name visitors use, including the bare domain and www.
• Check that redirects and CDN endpoints present the same valid chain.

Reading the common HTTPS errors

A name mismatch means the certificate does not cover the hostname requested — often because www or a subdomain was omitted. An untrusted issuer usually means an incomplete chain or a private certificate authority. An expired certificate means the validity window closed. A revoked certificate means the authority withdrew it.

Each message points at a different part of the chain, so read it before changing configuration. Replacing the certificate does not help when the actual problem is a missing intermediate or a hostname that was never included.

What a valid chain does and does not prove

A correct chain proves the connection is encrypted and that the certificate was issued for that name by a trusted authority. It says nothing about the security of the application behind it, the strength of administrator passwords, or whether the site is honest.

ScoutLab's Free Scan, Deep Scan and Monitoring review certificate and transport signals from outside, alongside headers, DNS and exposure. They do not perform malware or blacklist detection, are not a manual penetration test, do not provide compliance certification, and do not guarantee security.