Certificate chain: root, intermediate and leaf

The three kinds of certificate

root certificate          in the browser's trust store, trusted outright
        │  signs
intermediate certificate  vouched for by the root
        │  signs
leaf certificate          yours, for your names

• The root

  sits in a trust store shipped with the browser or the operating system. It is trusted because it is there, not because anything vouched for it, which makes the trust store the actual foundation of the whole system.

• The intermediate

  is signed by the root and signs certificates for customers. Authorities work through intermediates rather than signing directly with roots, so that a compromised signing key can be replaced without touching what is installed on every device in the world.

• The leaf

  is yours. It covers your names and is signed by an intermediate.

What the client has to do

A browser holds roots and receives your leaf. To connect them it needs every intermediate in between, and it expects the server to supply them.

That expectation is the crux. Your server must present its own certificate plus the intermediates, as one bundle. If it presents only its own, the browser has a leaf it cannot connect to anything it trusts, and it refuses, reporting the error described on ERR_CERT_AUTHORITY_INVALID. The procedure a client follows to join those links, and the rule that every link must be signed by the next one up, are specified in RFC 5280.

Configuring the server to serve the full bundle is an installation topic and is covered in the installation material on this site.

Why a broken chain is the most common installation fault

Because it is invisible to the person who caused it.

Browsers cache intermediates they have seen. Once your browser has encountered a particular intermediate anywhere, it can complete chains that use it even when the server does not supply it. Some clients go further and fetch a missing intermediate from the address the certificate carries for that purpose, the caIssuers entry of the authority information access extension defined in RFC 5280. Either way, anyone who has been working with certificates has collected the common intermediates already, so a server with an incomplete chain works perfectly for them.

Meanwhile a visitor arriving on a fresh device, or with a browser that does not do this, sees a trust error. The failure is selective, unpredictable, and impossible to reproduce on the machine where the work was done.

Non-browser clients make it worse and clearer at once. Libraries used by scripts, mobile applications, and server-to-server calls generally do not collect intermediates and do not go looking for missing ones, so an incomplete chain that visitors barely notice breaks integrations outright. That contrast is a reliable diagnostic: works in a browser, fails from a script, suspect the chain first.

Chain versus root store

The chain is what the server sends: a path from your certificate up towards a root. It is data in transit, and you control it.

The root store is the list of certificates a client trusts outright. It ships with browsers and operating systems, is maintained by their vendors, and you do not control it at all.

The distinction matters in two practical ways. A chain can be complete and still fail, if it terminates at a root that a particular client does not have. And a root store differs between clients on the same machine: Firefox maintains its own, which is why some errors appear there and nowhere else, as described on SEC_ERROR_UNKNOWN_ISSUER.

So the chain is your responsibility and the root store is your constraint.

Should you send the root

No, and it is a common minor mistake.

The client already has the root, or it does not, and receiving a copy changes nothing either way: a root the client does not trust is not made trustworthy by being sent. Including it only adds bytes to every connection.

Send your certificate and the intermediates. That is the complete answer.

When the chain changes without you

An intermediate is not permanent, and this catches people who assumed their bundle was set once.

Authorities replace intermediates periodically, and they issue new certificates under whichever is current. So a renewal can arrive signed by a different intermediate than the previous one, and a bundle assembled by hand years ago no longer matches the certificate it accompanies. The symptom is a trust error appearing immediately after a routine renewal that otherwise went perfectly.

Authorities also occasionally retire intermediates entirely, or a root approaches the end of its own validity and clients migrate to a successor. Those transitions are announced well ahead, and they affect anyone whose bundle is a file that nobody revisits.

Whatever installs the certificate should install the chain that came with it, in the same operation. A bundle maintained separately from the certificate is a pair of things that must be kept in step, and pairs like that drift.

How to check your chain

An external checker reports what the server actually presents, in order, and states whether the chain resolves to a trusted root. That is the verification worth doing after every certificate change, and the only one that reflects what a stranger's browser sees.

The check to avoid relying on is your own browser. It will very likely succeed regardless, because it already holds the common intermediates, which makes it the least informative test available to you.

For a certificate you hold as a file, a decoder shows its issuer, which tells you which intermediate you need if you are assembling the bundle by hand.

One further check is worth running deliberately after any change: fetch the site with something that does not collect intermediates, such as a script rather than a browser. That reproduces what a stranger's fresh device sees, which is the audience the chain exists for in the first place.

FAQ