What the Chain Is, and Who Sends What
A website certificate doesn't stand alone. It relies on a trust chain leading upward: your certificate (leaf) → intermediate → root. The validating party must be able to follow that path to a root it already trusts before it will accept the certificate.
The crucial part is where each piece comes from. Roots are preinstalled in the operating system or browser trust store and don't need sending. Intermediates are not, and your server must send them alongside the leaf. Send only the leaf and the validator is missing the middle, so the chain can't be assembled.
| Client | When the intermediate is missing | What the user sees |
|---|---|---|
| Desktop browsers | Usually fetch it via the AIA field, or reuse a cached intermediate | Everything works, no sign of trouble |
| Mobile apps and WebViews | Generally do not repair it | Connection failure or a certificate warning |
| curl, wget | Do not | Certificate verification fails outright |
| Language HTTP clients (Python, Node.js, Java) | Do not | Certificate validation exception |
| Monitoring and health checks | Do not | Persistent alerts, or a false outage |
Why do some devices connect anyway? Because certain clients repair it themselves. The table shows where they differ.
Three Ways the Chain Ends Up Incomplete
Nearly every case comes from one of these, and none of them errors at the time:
-
Installing the leaf-only certificate file
The most common cause. A CA typically hands you several files: one containing just your certificate, another containing the full chain. With Let's Encrypt,
cert.pemis leaf-only whilefullchain.pemis complete. Point the config at the wrong one and the service starts normally — the fault only surfaces when a particular kind of client connects. - Leaving the intermediate field empty On control panels that ask for certificate and intermediate separately — common with hosting providers and load balancers — leaving the intermediate box blank still saves successfully. Nothing warns you, because from the panel's perspective that field was always optional.
- The CA rotated its intermediate CAs rotate their own intermediates. After a renewal your new leaf may be signed by a new intermediate while the server still holds the old one, and the chain breaks again. This one is hard to diagnose, because it worked last time and broke this time while you changed nothing.
Why the Symptom Comes and Goes
Desktop browsers have two repair mechanisms. The first is the certificate's AIA field (Authority Information Access), which carries a URL for the issuer's certificate; on finding a broken chain, the browser downloads the intermediate from there and completes it. The second is caching — browsers retain intermediates encountered on other sites and reuse them.
Together these make the problem nearly invisible in a browser. Worse, the behaviour is inconsistent: support for AIA fetching varies between browsers and versions, and what's cached depends on which sites that user happened to visit. So the same machine gives different results in different browsers, and the same browser behaves differently for different people.
Non-browser clients generally have neither mechanism. They validate exactly what they receive, and a missing intermediate fails immediately. So the first reports usually come from apps, API integrators, or monitoring — not from ordinary web visitors.
How to See What the Server Sends
The direct method is openssl s_client -connect domain:443 -servername domain -showcerts, which lists every certificate the server actually presents. Each s: (subject) and i: (issuer) pair in the output is one link in the chain — if only one certificate appears, the server is sending the leaf alone.
In a healthy chain the leaf's issuer matches the next certificate's subject, continuing up to a root or a known intermediate. Run the check from outside, against the address users actually reach. With a CDN in front, establish which layer you're testing, since edge nodes and origin can carry different certificates.
Three Levels of Fix
Once you've confirmed the problem, work through these:
1. Switch to the full-chain file
Point the configuration at the file containing intermediates (fullchain.pem for Let's Encrypt), or fill in the intermediate field in the control panel. Including the root is optional — a few hundred extra bytes, and harmless. Reload the service afterwards: a changed file without a reload changes nothing — how Nginx loads certificates covers why.
2. Fix every TLS-terminating endpoint
Origin, each CDN node and load balancers all hold their own certificate. Fixing origin while CDN nodes still serve the old configuration leaves users exactly where they were. This mirrors expiry handling — certificate problems are nearly always "some places updated, others didn't".
3. Make chain checking part of renewal
CAs don't notify you when they rotate intermediates. The reliable defence is verifying chain completeness automatically after each renewal and deployment, rather than waiting for user reports. It's the same mechanism as expiry monitoring, checking one more property.
Three Things to Establish While Diagnosing
These save considerable time before you start changing configuration:
- Confirm it really is the chain Expired certificates, hostname mismatches and clock skew all produce similar-looking errors. Use openssl to see how many certificates the server sends before deciding what to fix.
- Confirm which layer you're inspecting Behind a CDN, an external check measures the edge node's certificate. If the fault is between edge and origin, the origin needs testing separately. Getting the layer wrong leads to the opposite conclusion.
- Confirm which kind of client fails If only some mobile devices fail while desktops are fine, a missing intermediate is very likely. If desktop browsers fail too, it's usually something else — because browsers can repair an incomplete chain on their own.
In Summary
"It opens in my browser" isn't a valid test for certificate problems, because the browser repairs the missing intermediate for you while your apps, API clients and monitoring do not. There is one reliable method: inspect what the server sends, not whether a given client connected.
These faults almost always originate in manual deployment — the wrong file, an empty field, or a CA rotating its intermediate unnoticed. If you'd rather not verify this by hand every time, our SSL automation platform deploys the complete chain to each node on issuance, removing the step where intermediates get dropped.