Certificates & Site Ops · Field note
Certificate Chain Basics for Beginners
A beginner-friendly explanation of leaf certificates, intermediates, and why chain issues break trust.
Before you start
Inspect the current certificate, key, token, or endpoint output before changing deployment config; stale artifacts make fixes misleading.
In brief
What it is: A certificate chain is the path from the site certificate you deploy to a root certificate the client already trusts.
Why it matters: Understanding the chain helps you debug why one client connects cleanly while another reports an incomplete or untrusted chain.
Watch for: Deploying only the leaf certificate and assuming every client will fill in the rest.
Certificate chains confuse many site owners because the site appears to have 'a certificate,' yet browsers and servers often need more than one file or one logical certificate element to establish trust correctly.
The important idea is simple: a browser usually trusts a root authority already, and your server presents a leaf certificate plus the necessary intermediate material so that trust can be linked properly.
The chain in plain language
- The leaf certificate identifies the site or service being secured.
- An intermediate certificate helps connect the leaf certificate to a trusted root.
- The root is generally trusted by the client system already and is not always something your server needs to send.
Checks people skip
- Deploying only the leaf certificate and assuming that is enough everywhere.
- Mixing up the chain file and the private key.
- Treating every certificate file as if it contained the same material.
Read the supplied path without guessing
Use the Certificate Chain Checker to inventory the pasted PEM blocks and verify each child certificate signature against the candidate issuer key. A verified self-signature identifies a self-signed CA candidate; it does not prove that a browser or operating system trusts that certificate.
For common server deployments, fullchain.pem means the leaf followed by the needed intermediates, while chain.pem contains the intermediates without the leaf. A self-signed root is normally omitted from both. Treat those as deployment conventions and still check the target server's documentation.
Questions that come up in review
Why does the site work on one device but not another?
Different clients may have different trust stores or chain-building behavior.
Is the root certificate always deployed on the server?
Not always; the important requirement is that clients can build a trusted path.
Do this locally (CLI)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem
- The first command shows what the server actually sends during the TLS handshake.
- The second command tests whether the leaf verifies through the expected intermediate when
root.pemis used as the trust anchor for that check. It does not prove that other clients trust the same root.