How the SSL/TLS Certificate Chain Works
When your browser shows a padlock, it has just verified a chain of trust that runs from the website's certificate up to a root that the operating system already trusts. Understanding that chain is the key to fixing most TLS errors.
The three links
| Link | Issued to | Issued by | Where it lives |
|---|---|---|---|
| Leaf (end-entity) | your domain | an intermediate CA | sent by your server |
| Intermediate | the CA | the root CA | should be sent by your server |
| Root | the root CA | itself (self-signed) | in the OS/browser trust store |
A client trusts the root out of the box. The root signs an intermediate, the intermediate signs your leaf. By following the issuer of each certificate up the chain until it reaches a trusted root, the client establishes trust without the root key ever being exposed online.
Why "incomplete chain" happens
Your server must present the leaf and every intermediate. Roots are not sent — the client already has them. The classic outage is a server configured with only the leaf: desktop Chrome may still work (it caches or fetches intermediates via AIA), but mobile clients and curl fail with unable to get local issuer certificate. Always deploy the fullchain file your CA provides.
Check it yourself
# Show every certificate the server sends, with subject/issuer
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
Our SSL/TLS checker renders the same chain in your browser, including a warning if an intermediate is missing or the certificate does not match the hostname. For expiry monitoring see checking certificate expiry, and for protocol versions see TLS versions.
Note: Order matters in the PEM file — leaf first, then intermediates from nearest to root. A wrong order causes the same client errors as a missing intermediate.