The chain of trust: from leaf to root
SSL certificate security is based on a hierarchical chain of trust. Your certificate (leaf certificate) is not directly trusted by the browser: it is signed by an intermediate CA, which in turn is signed by a root CA. The browser has a trust store with trusted root CAs (approximately 150 root CAs in modern browsers). To trust your certificate, the browser must be able to build the complete chain from the leaf to a root CA in its trust store. If a link is missing, the chain breaks and the browser shows an error.
The Certificate Chain tool visualizes the entire chain returned by the server, verifying the signature of each certificate, the validity dates of each one, and the completeness of the chain. It is more detailed than the SSL Check: while that provides an overall grade, the Certificate Chain focuses specifically on chain structure, identifying missing certificates, certificates in the wrong order, and expired certificates in the chain.
Common chain problems
The most frequent problem is the missing intermediate certificate. The server must send the leaf and all intermediates (but not the root). If an intermediate is missing, some browsers and clients (especially mobile, cURL, Java applications) cannot validate the chain and show an error. Chrome on desktop often works anyway because it automatically downloads missing intermediates (AIA fetching), masking the problem. This is why testing with a dedicated tool like our Certificate Chain is essential.
Configuring the chain correctly
To correctly configure the chain, concatenate the server certificate with intermediate certificates in a single file (bundle or fullchain). The order is: leaf first, then intermediates from closest to the leaf to closest to the root. Do not include the root certificate. On Nginx: ssl_certificate points to the fullchain. On Apache: SSLCertificateFile for the leaf, SSLCertificateChainFile for intermediates. Let's Encrypt directly provides the fullchain.pem file containing leaf + intermediates.
After configuration, verify with Certificate Chain and with SSL Check for the grade. If you issue certificates for multiple subdomains, verify the chain on each one — the configuration might differ. Also verify that your domain has CAA Record Lookup records configured to limit which CAs can issue certificates, adding an additional layer of protection to your PKI.
A special case is cross-signing: Let's Encrypt initially used an intermediate certificate cross-signed by the root DST Root CA X3 (older and more widespread) to ensure compatibility with pre-7.1 Android devices. With the transition to their own root ISRG Root X1, some older devices may have issues. If your audience includes very old devices, verify chain compatibility with those specific clients.