Root, intermediate and leaf certificates explained

When a browser connects over HTTPS it does not trust your certificate on faith. It builds a chain of trust from the certificate the server sends, through one or more intermediate certificates, up to a root certificate the browser already trusts. Understanding root, intermediate and leaf roles explains most certificate problems.

Know the chain

• Leaf (server) certificate. The certificate presented to the browser that carries the domain name (subject and SAN) visited. It is signed by an intermediate.
• Intermediate certificate. Sits between the leaf and the root. It is not pre-loaded in browsers, so the server usually sends it (or the chain) so the browser can connect leaf to root. This is why misconfiguration of intermediates breaks on some clients.
• Root certificate. The top of the chain, held in the browser or operating system trust store. It signs an intermediate, which signs the leaf. Trust flows from the root downward.

Understand trust anchors

• Why roots rarely sign leaves directly. If a private root key were compromised or misused, everything under it falls. CAs sign an intermediate (or two) with the root and sign leaves with the intermediate key, so they can revoke or rotate the intermediate without touching the root.
• Cross-signing. A root often cross-signs an intermediate issued under another root, which lets a site's chain validate for clients that trust a different root. Keep the full chain sent to clients, not just the leaf.
• Expiry and rotation. Roots run for many years; intermediates and leaves are renewed far more often. When an intermediate rotates, update the bundle the server sends so clients always get a valid chain.

Inspect a chain

On a terminal you can see the chain a server sends with openssl s_client:

openssl s_client -connect example.com:443 -showcerts

• Look for the "Verify return code". A code of 0 means the chain validated. Any other code points at the failing link.
• Count the certificates. You should see the leaf first, followed by intermediate(s). If only the leaf is shown, the server is not sending its intermediates, which will fail for clients without the root cached.
• Confirm the leaf matches the domain. A certificate for the wrong name is usually fixed by issuing for the correct SAN, which is covered in the certificate types and multi-domain SAN guides.

Prevention

• Install the full bundle. Upload the leaf plus intermediates, not just a single PEM, when configuring a web server.
• Use the certificate checker of your CA or host. Many providers validate that you uploaded a complete chain before your domain goes live.
• Re-test after renewal. Every renewal is a chance to silently drop a required intermediate, so re-run the inspection above after each change.