SSL Certificate Chain Explained

How Certificate Chains Work

An SSL/TLS certificate chain (or chain of trust) is the sequence of certificates that links a server's end-entity certificate back to a trusted root Certificate Authority. Browsers and TLS clients verify the entire chain before trusting a connection.

Chain Structure

Root CA Certificate          (self-signed, in trust store)
  └── Intermediate CA Certificate   (signed by Root CA)
        └── End-Entity Certificate  (signed by Intermediate CA, your server's cert)

The chain typically has three levels, but can have more if there are multiple intermediate CAs.

How Chain Validation Works

When a TLS client connects to a server, the following process occurs:

1. The server sends its end-entity certificate and any intermediate certificates
2. The client builds a chain from the end-entity certificate to a trusted root
3. For each certificate in the chain:
   • Verify the signature using the issuer's public key
   • Check that the certificate has not expired
   • Check revocation status (CRL or OCSP)
   • Verify that the issuer is authorized to sign certificates (Basic Constraints: CA:TRUE)
4. The chain ends at a root CA certificate that exists in the client's trust store
5. If all checks pass, the certificate is trusted

Trust Anchors

Root CA certificates are called trust anchors. They are self-signed and pre-installed in operating systems and browsers. Each platform maintains its own trust store:

• Mozilla NSS — used by Firefox (~150 root CAs)
• Apple Root Certificate Program — used by Safari, macOS, iOS
• Microsoft Root Certificate Program — used by Windows, Edge
• Google Chrome Root Store — Chrome's own root store (since 2023)

The "Incomplete Chain" Error

The most common chain-related error is an incomplete chain — the server sends its end-entity certificate but not the intermediate certificate(s). In this case:

• Some browsers may still connect (they cache intermediates from previous visits)
• Other clients (curl, API clients, mobile apps) will fail with a certificate verification error
• The fix is to configure your server to send the full chain

# Test chain completeness
openssl s_client -connect example.com:443 -showcerts

Configuring the Full Chain

Most servers require a "full chain" or "chain file" that concatenates the end-entity certificate and intermediate certificate(s):

cat server.crt intermediate.crt > fullchain.pem

The root certificate should not be included — the client already has it in its trust store, and sending it wastes bandwidth.

Cross-Signed Certificates

When a new CA is not yet trusted by all clients, it can have its intermediate certificate signed by an established root CA. This creates a cross-signed chain that allows older clients to validate certificates through the established root while newer clients use the new CA's own root.