When a browser trusts your HTTPS site, it is not trusting your certificate directly. It is trusting an unbroken chain of signatures that leads from your certificate up to a root the browser already trusts. Understanding that chain is the key to fixing the most common — and most confusing — TLS error: "certificate not trusted", even though the certificate is perfectly valid.
The three kinds of certificate
The leaf (your certificate)
The leaf, or end-entity certificate, is the one issued for your domain. It contains your hostname, your public key and a signature from the Certificate Authority that issued it. This is the certificate you install for your site.
Intermediate certificates
CAs almost never sign leaf certificates with their root key directly. Instead the root signs one or more intermediate certificates, and those intermediates sign your leaf. This keeps the extremely valuable root key offline and lets CAs revoke an intermediate without invalidating the root.
The root
At the top sits the root certificate, which signs itself. Roots are distributed with operating systems and browsers in a trust store. Your server never sends the root — the client already has it, and that is the whole point: the chain has to terminate at something the client independently trusts.
Root CA (in the browser trust store)
└─ signs Intermediate CA
└─ signs Leaf (your-domain.com) ← the one you install
How the client validates the chain
During the TLS handshake your server sends the leaf plus any intermediates. The client then walks up the chain: it verifies each certificate's signature against the public key of the certificate above it, checks that none are expired or revoked, and confirms the top of the chain links to a trusted root. If every link checks out, the connection is trusted.
The most common failure: a missing intermediate
By far the most frequent chain problem is a server that sends the leaf but forgets to send the intermediate certificate. The maddening part is that it often looks fine in a desktop browser, because many browsers cache intermediates they have seen before or fetch them automatically. Other clients do not.
- Mobile apps and older devices frequently reject the connection outright.
- Command-line tools like curl and most programming-language HTTP clients fail with "unable to get local issuer certificate".
- API integrations and webhooks break even though the site loads in Chrome.
If a certificate works in your browser but fails from curl or a mobile app, a missing intermediate is the first thing to check. The fix is to install the full chain — leaf plus intermediates — usually as a bundle or "fullchain" file provided by your CA.
Other chain issues worth knowing
- Wrong order: some servers are strict about chain order (leaf first, then intermediates up the tree). Most modern clients tolerate any order, but not all.
- Expired intermediate: an intermediate can expire even while your leaf is valid, breaking the whole chain until the CA rotates it.
- Hostname mismatch: a valid, well-chained certificate still fails if the hostname is not covered by its subject or SAN entries — a different error, but often confused with a chain problem.
- Self-signed or unknown root: if the chain ends at a root not in the client's trust store (common with internal/corporate CAs), the client rejects it unless that root is manually trusted.
Inspecting a chain quickly
An SSL checker connects to your host, retrieves exactly what the server presents, and shows each certificate in the chain with its issuer, validity dates and whether the chain resolves to a trusted root. That is the fastest way to confirm the intermediate is present and everything links up before your users hit the error for you.