Glossary
Certificate chain
A certificate chain is the sequence of certificates that connects the one a server presents to a root certificate the client already trusts. The server's own certificate is signed by an intermediate, the intermediate by a root, and the client verifies each signature in turn. The server is responsible for sending the intermediates; the client supplies the root. An incomplete chain is the most common TLS misconfiguration precisely because it works in the browsers that happen to have cached the missing piece.
What the server must send
Its own leaf certificate, covering the hostname.
Every intermediate certificate needed to reach a trusted root, in order.
The root itself is not sent, and sending it wastes bytes on every handshake since the client must already have it to trust anything.
Certificate authorities publish the correct chain file alongside each issued certificate. Using it verbatim is the fix for essentially every chain problem.
Order used to matter strictly — each certificate followed by the one that signed it — and TLS 1.3 relaxed the requirement so that clients may reorder. Sending them in order remains the safe choice, because TLS 1.2 clients still expect it.
Why an incomplete chain fails intermittently
Browsers cache intermediates they have seen before. A visitor whose browser already has the intermediate from another site completes the connection normally.
Some clients fetch a missing intermediate from the URL in the certificate's authority information access extension, which works when it works and adds latency when it does.
Other clients — command-line tools, mobile applications, payment terminals, older devices — do neither and simply fail.
The result is a fault that a developer cannot reproduce in their own browser while a share of real traffic fails. Testing with a tool that does not cache is the only reliable check.
Cross-signing and expired roots
A newer root may not be present in older trust stores, so authorities cross-sign: the same key is certified by both a new root and an older, more widely distributed one.
That produces more than one valid path from the leaf to a trusted root, and different clients may build different paths.
When an old root expires, clients that were relying on that path fail while others continue to work. This has caused large, widely reported outages.
The mitigation is to serve the chain the authority currently recommends and to re-check it after any authority-side root change.
The chain a server sends is a file on disk, not something the authority can update remotely. Nothing prompts you when the recommended chain changes, which is why a working configuration can start failing without anything on your side having been touched.
How to verify a chain
`openssl s_client -connect example.com:443 -servername example.com` prints the chain the server sent, numbered from the leaf.
A `verify error: unable to get local issuer certificate` in that output means the chain is incomplete.
Test against a client with an empty cache rather than your everyday browser, since the browser is the one place the fault is invisible.
Re-check after every certificate renewal. A renewal that replaces the leaf without updating the chain file reintroduces the problem.
Frequently asked questions
- Why does my certificate work in Chrome but fail elsewhere?
- Almost always an incomplete chain. Browsers cache intermediates from other sites; tools and applications that do not simply fail to verify.
- Should the server send the root certificate?
- No. The client must already have the root for it to be trusted, so sending it adds bytes to every handshake for no benefit.
- What is a cross-signed certificate?
- An intermediate certified by more than one root, so that clients with older trust stores can still build a valid path.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website