TLS Certificate Chain Explained

What is a certificate chain?

When a client connects to a server over TLS (HTTPS), the server presents a certificate to prove its identity. But a single certificate is not enough. The client needs a chain of trust that links the server's certificate back to a Certificate Authority (CA) it already trusts.

A typical chain has three parts:

1. Leaf certificate (end-entity): issued to your domain, contains your public key and Subject Alternative Names (SANs).
2. Intermediate certificate(s): issued by the root CA to a subordinate CA. Most CAs use at least one intermediate to keep the root key offline and protected.
3. Root certificate: a self-signed certificate pre-installed in the client's trust store (browsers, operating systems, language runtimes).

During the TLS handshake, the server sends its leaf certificate plus any intermediates. The client walks the chain upward, verifying each signature, until it reaches a root it trusts. If any link is missing or invalid, the connection fails.

Why certificate chains matter

A broken chain is one of the most common causes of TLS errors. If the server omits an intermediate certificate, some clients may be able to fetch it themselves (via the Authority Information Access extension), but many will not. The result is intermittent failures: a browser on desktop works fine because its trust store cached the intermediate from a previous connection, while a mobile app or API client fails with a "certificate verify failed" error.

Chain issues are particularly insidious because they may not affect your own testing environment but break for a subset of users in production.

How chain validation works

For each certificate in the chain, the client verifies:

• Signature: the certificate's signature is valid under the issuer's public key.
• Validity period: the current time is between the notBefore and notAfter dates.
• Revocation status: the certificate has not been revoked, checked via CRL or OCSP.
• Name constraints: the subject or SAN matches the requested hostname.
• Key usage: the certificate is authorized for its role (e.g., digital signature for a leaf, certificate signing for an intermediate).

Modern clients also check for Certificate Transparency (CT) Signed Certificate Timestamps (SCTs), which prove the certificate was logged in public CT logs before issuance.

How to check a certificate chain

You can inspect a server's certificate chain using command-line tools:

# Using openssl
openssl s_client -connect example.com:443 -showcerts

# Using curl with verbose output
curl -vI https://example.com 2>&1 | grep -A 5 "Server certificate"

These tools show you the certificates the server sends during the handshake, including the order and completeness of the chain. Look for the chain depth and verify that each issuer DN matches the next certificate's subject DN.

For a more comprehensive analysis -- including expiry warnings, signature algorithm checks, SAN validation, OCSP stapling status, and CT SCT verification -- use a dedicated TLS inspection tool.

Chain order and best practices

The server should send certificates in order: leaf first, followed by intermediates, with the root omitted (since clients already have it). Sending the root wastes bandwidth and adds no security benefit. Some servers send certificates out of order, which most modern TLS libraries handle gracefully, but older clients may reject.

When configuring your server, include all intermediate certificates in your certificate file. If your CA provided separate files, concatenate them:

# Correct order for Nginx/Apache
cat leaf.pem intermediate.pem > fullchain.pem

Common mistakes

• Missing intermediate: The most frequent chain error. The server sends only the leaf certificate, and clients without a cached intermediate fail. Always include the full chain.
• Expired intermediate: Intermediates have their own validity periods. A valid leaf with an expired intermediate breaks the chain. Monitor intermediate expiry alongside your leaf certificates.
• Wrong intermediate: CAs sometimes issue certificates from different intermediates. Using an intermediate that did not sign your leaf produces a signature verification failure. Match the issuer DN on your leaf to the subject DN of the intermediate.
• Including the root: Not harmful but wasteful. Some scanners flag it. The root should come from the client's trust store, not the server.
• Self-signed certificates in production: Self-signed certificates have no chain -- the leaf is the root. Clients reject them unless explicitly configured to trust them, which defeats the purpose of public PKI.
• Cross-signed chain confusion: During CA transitions (like the Let's Encrypt DST Root CA X3 to ISRG Root X1 migration), servers may need to choose which chain to serve based on their client population's trust store age.

Certificate Transparency

Certificate Transparency (CT) is a framework that requires CAs to log all issued certificates in publicly auditable append-only logs. Browsers like Chrome require SCTs (Signed Certificate Timestamps) as proof of logging. SCTs can be delivered via the certificate itself (embedded), a TLS extension, or OCSP stapling. Missing SCTs cause Chrome to show a warning or reject the certificate entirely.