How Certificate Chains Work

A certificate chain (or chain of trust) connects a leaf certificate back to a trusted root through one or more intermediate CA certificates. Understanding chains is critical for debugging TLS errors and correctly configuring servers.

The Three Levels

Root CA (self-signed, in trust store)
  │
  └── Intermediate CA (signed by Root)
        │
        └── Leaf Certificate (signed by Intermediate)
              ↑ your server presents this

Root CA

A self-signed certificate that serves as the trust anchor. Root CAs are pre-installed in operating system and browser trust stores. There are roughly 150 root certificates trusted by major platforms. Root CAs rarely sign leaf certificates directly — instead they sign intermediates, keeping the root key offline and heavily protected.

Intermediate CA

A CA certificate signed by the root (or another intermediate). The intermediate's Basic Constraints extension has CA:TRUE. Intermediates perform the actual certificate issuance. If an intermediate is compromised, only it needs to be revoked — the root remains trusted.

Leaf Certificate

The end-entity certificate presented by your server. Its Basic Constraints either has CA:FALSE or omits the extension entirely. It cannot sign other certificates.

How Browsers Verify Chains

When a TLS client connects to a server, the server sends its leaf certificate plus any intermediates. The client then:

1. Builds a chain from the leaf to a root by matching each certificate's Authority Key Identifier (AKI) to the issuer's Subject Key Identifier (SKI).
2. Verifies each signature: the leaf was signed by the intermediate's key, the intermediate was signed by the root's key.
3. Checks that the root exists in the local trust store.
4. Validates constraints: dates, key usage, path length, name constraints.
5. Checks revocation status (OCSP or CRL) for each non-root certificate.

Trust Stores

Each platform maintains its own trust store: Windows uses the Certificate Store (certmgr.msc), macOS uses System Keychain, Linux distributions use ca-certificates packages, and Java uses its own cacerts file. Browsers may use the OS store (Chrome, Edge) or bundle their own (Firefox uses NSS/Mozilla root program).

Cross-Signing

A CA can have its intermediate signed by multiple roots. This is called cross-signing and allows new CAs to be trusted by older clients that have not yet added the new root. Let's Encrypt famously cross-signed with IdenTrust DST Root CA X3 during its early years.

Common Chain Issues