Checking TLS certificate chain completeness: why a 'valid' certificate can still fail
A TLS certificate chain is the sequence of certificates — the server's own (leaf) certificate, one or more intermediate certificates, and a root — that lets a client verify the leaf back to an authority it already trusts; RFC 5280 defines how that path is validated, and a server that sends its leaf certificate but omits a required intermediate produces a chain that is individually valid at every link yet still fails to validate for any client that won't fetch the missing piece itself.
By AdminKit team, Netbase JSC · Updated October 31, 2026
A chain is a sequence, and the sequence has to be unbroken
A server’s TLS certificate (its leaf certificate) is signed by a certificate authority, but that CA almost never signs leaf certificates directly with its own root key — instead it signs with one or more intermediate certificates, keeping the root key itself offline and rarely used. RFC 5280 defines certification path validation as building and checking this entire sequence: the leaf must be signed by the next certificate up, that one signed by the next, and so on until the path reaches a root the validating client already trusts. Every individual signature in that sequence can be mathematically valid, and the whole path still fails to validate if even one certificate in the middle — an intermediate — is missing from what the server actually sent.
This is what “chain completeness” means in a certificate check result: not whether the leaf certificate itself is well-formed, but whether the server handed over every certificate a client needs to walk that full path, with nothing missing in between.
Why this looks fine in a browser and breaks everywhere else
The most common way an incomplete chain goes unnoticed is that it happens to work in whichever browser someone tested it in. Two browser behaviors mask the gap, and neither one is guaranteed by any specification:
- Caching. If a browser has already seen a given intermediate certificate while visiting a different, correctly configured site, it can reuse that cached copy to complete the path even though the server in front of it never sent that intermediate.
- AIA chasing. RFC 5280 §4.2.2.1 defines the Authority Information Access extension, which a certificate can use to point at a URL where its issuer’s certificate can be fetched. Some clients — notably Windows’ certificate validation and some browsers — will fetch a missing intermediate this way if the extension is present.
Neither mechanism is something RFC 5280 requires a client to implement, and plenty of real clients implement neither: curl and most non-browser HTTP libraries validate strictly against what the handshake actually delivered, many mobile app TLS stacks behave the same way, Java’s default trust manager does not chase AIA URLs, and mail transfer agents validating a STARTTLS certificate typically don’t either. The result is a server that looks completely healthy to whoever tested it in a browser, while quietly failing every API client, mobile app, and mail server that talks to it.
Reading a chain-completeness result
AdminKit’s SSL/TLS check completes a real handshake and reports exactly what the server sent, which is what makes a chain gap visible: a result showing an incomplete chain, “unable to get local issuer certificate,” or an unresolved path to a trusted root means the server’s handshake is missing one or more intermediates — not that the leaf certificate is invalid, expired, or wrong for the hostname, which are separate, independently reported problems. See how to read a TLS/SSL certificate check result for how those other fields are reported alongside chain status.
Fixing it
The fix is almost always the same regardless of which CA issued the certificate: configure the web server to serve the leaf certificate together with every required intermediate, in one ordered bundle, instead of the leaf alone. Certificate authorities generally publish this bundle ready-made — Let’s Encrypt, for example, documents a fullchain.pem file that already concatenates the leaf and the intermediate it needs — and the common root cause of an incomplete chain is a server configuration pointing at the leaf-only certificate file instead of that bundle. RFC 8446 specifies the TLS Certificate message as an ordered list, so the broadly interoperable convention is leaf first, then each intermediate in order; a root certificate at the end is unnecessary (clients already have it) and best left out.
Next step: check your own chain
Run AdminKit’s SSL/TLS check against your hostname to see whether its chain resolves cleanly to a trusted root, alongside the certificate’s expiry and negotiated protocol. If the chain is complete but you’re deciding which CA should be allowed to issue for the domain at all, see what CAA records are and how they limit issuance.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
If my certificate itself is valid and not expired, why would a connection still fail?
Because chain validation is a separate step from checking the leaf certificate's own fields. RFC 5280's certification path validation requires building an unbroken sequence of certificates from the leaf up to a trusted root, each one signed by the next. A server that sends only its leaf certificate, omitting the intermediate certificate that signed it, breaks that sequence even though the leaf certificate itself is perfectly valid — the client simply has no way to link it to a root it trusts.
Why does the site work in Chrome but fail in curl, a mobile app, or a mail server?
Many desktop browsers cache intermediate certificates they've already seen from other sites, and some also perform AIA chasing (fetching a missing intermediate automatically) using the Authority Information Access extension RFC 5280 defines. Neither behavior is mandated by the RFC, so it varies by client: command-line tools like curl, many mobile app TLS stacks, Java's default trust manager, and most mail transfer agents validate only what the server actually sends in the handshake, with no caching and no fetching, so the exact same misconfigured server that 'works' in a browser fails outright for them.
What's the actual fix for an incomplete chain?
Configure the server to send every intermediate certificate between its leaf and a trusted root, in addition to the leaf itself. Most certificate authorities publish a ready-made bundle for this — for example, a file commonly named fullchain.pem — that already concatenates the leaf and the required intermediate(s) in the right order; the fix is almost always pointing the web server's TLS configuration at that bundle instead of the leaf certificate alone.
Does the order of certificates in the chain matter?
Yes, for interoperability, even though RFC 5280's path-validation logic can in principle work out the links regardless of order. The TLS specification RFC 8446 defines the certificate message as an ordered list, and the broadly compatible convention is leaf certificate first, followed by each intermediate in order up toward (but usually not including) the root — sending them out of order or appending an unnecessary root certificate is a common secondary mistake alongside leaving an intermediate out entirely.
If AIA chasing exists, why not just rely on it instead of fixing the server?
Because RFC 5280's Authority Information Access extension is optional for a client to act on, not a guaranteed fallback. It's a courtesy some clients implement and many don't, and even where it's supported it adds an extra network fetch and a dependency on that fetch succeeding at the exact moment a client needs it — relying on it means a meaningful slice of real-world clients fail outright rather than slowing down. Serving the complete chain yourself costs nothing and removes the dependency entirely.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.
Talk to an expert
Huy Nguyen (David), Founder & CEO, Netbase JSC
Ask whether this fix applies to your setup, or get a second pair of eyes on your DNS and mail records.