Certificate chain
A certificate chain is the ordered sequence of certificates, per RFC 5280's path-validation rules, linking a server's TLS certificate up through one or more intermediate certificates to a root a client already trusts. AdminKit's SSL/TLS check inspects whether a server actually sends every certificate in that chain, since a missing intermediate breaks validation for clients that won't fetch it themselves.
By AdminKit team, Netbase JSC · Updated
A server’s TLS certificate (its leaf certificate) is almost never signed directly by a root a browser or operating system trusts — certificate authorities keep that root key offline and sign through one or more intermediate certificates instead. RFC 5280 defines certification path validation as building this entire sequence, leaf up to a trusted root, checking that each certificate is correctly signed by the next one up; the chain a server sends during the TLS handshake has to include every intermediate in that path. A chain can be individually valid at every link and still fail validation if even one intermediate is missing from what the server actually sent. Some browsers cache or fetch a missing intermediate automatically; many others, including common command-line tools and mail servers, validate only what the server provides, with no fallback. Let’s Encrypt’s own chain-of-trust documentation shows the same structure from an issuing certificate authority’s side: a complete chain bundles the leaf with its required intermediates so a client never has to fetch one separately.