Guides · TLS
TLS Certificate Chain Explained
What a TLS certificate chain is, how leaf, intermediate, and root certificates build a chain of trust, and why a missing intermediate breaks some clients but not others.
By Cody · 7 min read · Published
The short version
When a client connects to your site over HTTPS, it does not just check one certificate — it checks a chain of them. Your server's certificate (the leaf) is signed by an intermediate, which is signed by a root that the client already trusts.
The client follows that chain upward until it lands on a root in its trust store. If every link is present and valid, the certificate is trusted. The single most common TLS chain problem — a site that works in your browser but fails in curl or an API client — comes down to a missing intermediate, and the fix is always on the server, not the client.
How the chain works
Trust flows downward through signatures. You trust the root certificate because it ships in your operating system or browser. The root signs an intermediate, vouching for it. The intermediate signs your leaf, vouching for it. So by trusting the root and verifying each signature in turn, the client can trust your leaf without ever having seen it before.
CAs sign with intermediates instead of the root directly so the root's private key can stay offline in a vault. That makes the intermediate essential: it is the bridge between your certificate and the trusted root, and your server is responsible for sending it.
Anatomy of a chain
A typical chain has three roles, but your server only transmits two of them:
| Role | Signed by | Sent by server? |
|---|---|---|
| Leaf (your domain) | An intermediate CA | Yes |
| Intermediate | The root CA (or another intermediate) | Yes |
| Root | Itself (self-signed) | No — the client already has it |
The leaf carries your hostname in its subject and Subject Alternative Names. The intermediate carries the CA's name. The root is the trust anchor and is supplied by the client's trust store, which is why it is never sent over the wire.
The missing-intermediate problem
This is the chain issue you will actually run into. A server is configured with only the leaf certificate, not the intermediate. What happens next depends entirely on the client:
- Browsers usually still work. They cache intermediates from other sites and can fetch a missing one using the certificate's AIA (Authority Information Access) extension, so the gap is invisible.
- Strict clients fail.
curl, Java, Go, Python, and most API libraries do not chase down a missing intermediate. They report an incomplete chain or an untrusted certificate and refuse to connect.
That asymmetry is the trap: the site looks fine to you and broken to a partner's integration. Because the certificate itself is valid, the fix is to make the server send the full chain — never to disable verification on the client.
Common chain problems
| Symptom | Likely cause |
|---|---|
| Works in browser, fails in curl/Java | Missing intermediate certificate on the server. |
| Untrusted / unknown issuer | Chain does not reach a root in the client's trust store. |
| Expired certificate | The leaf or an intermediate is past its validity date. |
| Wrong order / self-signed in chain | Certificates concatenated out of order, or a private root included. |
| Hostname mismatch | The leaf is valid but its names do not cover the host requested. |
Reading the chain in the TLS tool
The TLS certificate checker connects to a host and lists each certificate the server presents in order — leaf first, then intermediates — with the role, issuer, validity dates, and days until expiry for each. If only one certificate appears where you expected two, that is your missing-intermediate signal.
Pair it with the HTTP security header checker once the chain is healthy: a trusted certificate is the foundation, and the security headers riding on the HTTPS response are the next layer. For dates and renewal specifically, see TLS certificate expiration and troubleshooting.
A complete chain, leaf to root
- Example input
openssl s_client -connect example.com:443 -showcerts- Example result
Certificate chain 0 s:CN=example.com <- leaf (your domain) i:C=US, O=Example CA, CN=Example CA Intermediate 1 s:C=US, O=Example CA, CN=Example CA Intermediate <- intermediate i:C=US, O=Example CA, CN=Example CA Root # the Root (Example CA Root) is NOT sent — the client supplies it
The server sends the leaf and the intermediate. The client matches the intermediate's issuer to a root already in its trust store to complete the chain.
Related tools
FAQ
What is a TLS certificate chain?
A certificate chain is the ordered set of certificates that connects the certificate on your server (the leaf) to a root certificate the client already trusts. Each certificate is signed by the one above it: the leaf is signed by an intermediate, the intermediate by a root. The client walks this chain upward until it reaches a root in its trust store — that is what makes the connection trusted.
What is an intermediate certificate?
An intermediate certificate sits between your leaf certificate and the certificate authority's root. CAs sign with intermediates rather than the root directly, so the valuable root key can stay offline. Your server must send the intermediate(s) along with the leaf; the intermediate is the link that lets a client connect your certificate back to a trusted root.
Why does my certificate work in a browser but fail in curl or Java?
Almost always a missing intermediate. Browsers often cache intermediates from previous sites or fetch them using the certificate's AIA extension, so they paper over a server that forgot to send one. Stricter clients — curl, Java, Go, many API libraries — do not, so they report an incomplete chain or untrusted certificate. The fix is to make the server send the full chain, not to change the client.
What is the root CA and the trust store?
The root CA is the certificate authority at the top of the chain, and its self-signed root certificate is the anchor of trust. Operating systems and browsers ship a trust store — a curated list of root certificates they consider trustworthy. A chain is trusted only if it terminates at a root already in that store; the root itself is never sent over the connection because the client already has it.
How many certificates should the chain have?
Typically two that your server sends: the leaf and one intermediate. Some CAs use two intermediates, so three sent certificates is also common. The root is not sent — the client supplies it from its trust store. If a checker shows only the leaf, the chain is incomplete; if it shows the root being transmitted, that is harmless but unnecessary.
What does 'chain of trust' mean?
Chain of trust is the idea that trust flows downward through signatures: you trust the root, the root vouches for the intermediate by signing it, and the intermediate vouches for your leaf by signing it. If every signature checks out and the top of the chain is a trusted root, the client trusts the leaf. Break any link — a missing or expired certificate — and the trust does not reach the leaf.
How do I fix a missing intermediate certificate?
Concatenate the intermediate certificate(s) after your leaf certificate in the file your server presents (often called the fullchain). Most CAs provide the intermediate as a download or bundle. After deploying, re-check from a strict client to confirm the chain is complete — a browser test alone can hide the problem.
Last reviewed: 2026-06-29.