Chain of Trust

When your browser connects to a website and displays that reassuring padlock icon, an invisible but critical process has occurred: the certificate chain validation. In milliseconds, your browser has traced a path from the website's certificate, through one or more intermediate certificates, up to a root CA that it implicitly trusts.

This chain of trust is the linchpin of internet security. Every TLS connection, every HTTPS request, every secure API call depends on successfully verifying this chain. A break in the chain—an expired intermediate, a missing certificate, a signature that doesn't verify—results in those dreaded security warnings that block access.

Understanding chain of trust isn't just academic knowledge. It's essential for:

• Debugging SSL/TLS issues — Why is my certificate showing as untrusted?
• Proper certificate deployment — Which intermediates do I need to include?
• Security assessment — Is this chain actually secure?
• Incident response — What's the impact if this CA is compromised?

This page takes you deep into how trust chains work, how they're verified, and how to troubleshoot them when things go wrong.

A certificate chain (or certificate path) is an ordered sequence of certificates that links an end-entity certificate to a trusted root CA. Each certificate in the chain is signed by the next certificate's subject, creating a cryptographic chain that terminates at a self-signed root.

The Basic Chain Structure:

[End-Entity Certificate]
        ↑ signed by
[Intermediate CA Certificate]
        ↑ signed by
[Root CA Certificate (self-signed, in trust store)]

Why Chains Exist:

Remember from our CA discussion that root CAs rarely sign end-entity certificates directly. The reasons are both security and operational:

1. Security — Root private keys are too valuable to expose for routine signing
2. Flexibility — Intermediates can be revoked without changing root stores
3. Segmentation — Different intermediates can have different policies
4. Recovery — If an intermediate is compromised, issue a new one from the root

Chain Terminology:

Real-World Example:

Let's trace a typical certificate chain for a website secured by Let's Encrypt:

Leaf:      CN=www.example.com
           Issuer: CN=R3, O=Let's Encrypt
           
           ↑ R3 signed this
           
Intermed:  CN=R3, O=Let's Encrypt
           Issuer: CN=ISRG Root X1
           
           ↑ ISRG Root X1 signed this
           
Root:      CN=ISRG Root X1, O=Internet Security Research Group
           Issuer: CN=ISRG Root X1 (self-signed)
           
           ✓ In browser trust store

The browser knows nothing about www.example.com initially. But because it trusts ISRG Root X1 (which is in its trust store), and ISRG Root X1 vouches for R3, and R3 vouches for www.example.com, the browser transitively trusts the website.

Before a chain can be validated, it must first be built. Path building is the process of assembling a complete chain from the end-entity certificate to a trusted root.

The Path Building Challenge:

Path building isn't always straightforward because:

1. Servers may send incomplete chains — Missing intermediates
2. Multiple paths may exist — Same CA re-keyed, cross-certified CAs
3. Some certificates may be expired or revoked — Must find valid path
4. Trust stores vary — What's trusted differs by OS/browser/config

Sources of Certificates for Path Building:

AIA Chasing:

When a server doesn't send the complete chain, clients can use the AIA extension in certificates to fetch missing intermediates. This is called "AIA chasing":

1. Client receives end-entity certificate
2. Certificate has AIA extension with URL: http://r3.i.lencr.org/
3. Client downloads the intermediate from that URL
4. Process repeats until reaching a trusted root

Warning: AIA chasing has drawbacks:

• Adds latency (extra HTTP requests)
• May fail if CA's server is down
• Some clients don't support it (notably OpenSSL)
• Can be blocked by firewalls

Once a path is built, it must be validated. RFC 5280 defines the certification path validation algorithm—a complex procedure that every TLS implementation must correctly implement.

The Validation Process (Simplified):

For each certificate in the chain, from root to leaf:

1. Signature Verification — Verify the issuer's signature on the certificate
2. Validity Period — Check notBefore ≤ current time ≤ notAfter
3. Revocation Status — Check if certificate has been revoked (CRL or OCSP)
4. Name Chaining — Verify issuer DN matches subject DN of signing certificate
5. Key Identifier Matching — Authority Key Identifier matches Subject Key Identifier
6. Basic Constraints — If cA is TRUE, certificate can sign other certificates
7. Path Length — Check pathLenConstraint isn't exceeded
8. Key Usage — Verify keyCertSign bit for CA certificates
9. Policy Validation — Process certificate policies if required
10. Name Constraints — Verify any name restrictions

Detailed Validation Checks:

The pathLenConstraint:

This is often misunderstood. It limits how many non-self-issued CA certificates can appear below this CA in the chain.

• pathLenConstraint: 0 — This CA can only issue end-entity certs, not other CAs
• pathLenConstraint: 1 — This CA can issue to CAs that themselves can only issue end-entity certs
• pathLenConstraint: absent — No limit on path length

Example with pathLenConstraint: 1 on the Root:

Root CA (pathLenConstraint: 1)
  → Intermediate CA 1 (pathLenConstraint: 0)  ✓ Valid
    → End-Entity Certificate                   ✓ Valid
    → Intermediate CA 2 (trying to be CA)      ✗ Rejected (pathLen:0 at parent)
  → Intermediate CA 3 (pathLenConstraint: 2)  ✗ Rejected (pathLen:1 at root, can't have CA with pathLen:2)

Critical Extensions:

If any extension is marked critical and the validator doesn't understand it, the certificate must be rejected. This is a safety mechanism—unknown critical extensions might impose constraints that can't be verified.

Certificate chains aren't always simple linear hierarchies. Cross-certification creates links between separate CA hierarchies, enabling interoperability and trust bootstrapping.

What is Cross-Certification?

Cross-certification occurs when one CA issues a certificate to another CA (not its subordinate). This creates a trust bridge between two previously independent PKI hierarchies.

Use Cases:

Let's Encrypt Cross-Signing Example:

Let's Encrypt's ISRG Root X1 was new in 2016 and not in most trust stores. To provide immediate trust, IdenTrust (whose DST Root CA X3 was widely trusted) cross-signed ISRG Root X1:

Path 1 (Modern devices with ISRG Root X1):
www.example.com → R3 → ISRG Root X1 (in trust store)

Path 2 (Older devices without ISRG Root X1):
www.example.com → R3 → ISRG Root X1 → DST Root CA X3 (cross-signed, in trust store)

The same certificate chain could validate through either path depending on what roots the client trusted. This was critical for Let's Encrypt's success—they achieved immediate universal trust without waiting years for root store updates.

Bridge CAs:

A Bridge CA is a special-purpose CA that cross-certifies multiple other CAs, creating a hub for trust. The Bridge doesn't issue end-entity certificates—it only connects other CAs.

Example: The US Federal PKI Bridge CA connects:

• Department of Defense PKI
• Department of State PKI
• Various agency-specific PKIs
• Commercial CAs for contractor authentication

The Bridge enables a DoD certificate to be validated by a State Department system, even though they have different root CAs.

Name Constraints are a powerful but underused extension that limits what names a CA (and its subordinates) can include in issued certificates.

Why Name Constraints Matter:

Consider an enterprise that wants to run its own CA for internal services. Without constraints, that CA could technically issue a certificate for google.com or any other domain. If that CA's root is installed on corporate devices, a rogue administrator could perform MITM attacks.

Name Constraints solve this by specifying:

• Permitted Subtrees — The only names the CA can issue for
• Excluded Subtrees — Names the CA explicitly cannot issue for

Constraint Types:

Minimum Subtree Matching:

The leading dot is significant:

• .example.com matches sub.example.com and deep.sub.example.com but NOT example.com itself
• example.com (no dot) matches exactly example.com and all subdomains

Enterprise PKI Best Practice:

Any enterprise CA that's added to device trust stores should have Name Constraints limiting it to company-owned domains and internal IP ranges. This provides defense-in-depth against CA compromise or administrator abuse.

Why Aren't They Used More?

Despite their value, Name Constraints are underused because:

• Some legacy software doesn't properly validate them
• Adding constraints to existing CAs requires re-issuing the CA certificate
• Public CAs can't have Name Constraints (they need to issue for any domain)
• Constraint complexity can lead to unexpected validation failures

Certificate chain problems are among the most common TLS issues. Knowing how to diagnose and fix them is essential for any systems engineer.

Common Chain Problems:

Diagnostic Commands:

Online Testing Tools:

• SSL Labs SSL Test (ssllabs.com) — Comprehensive analysis including chain validation
• What's My Chain Cert (whatsmychaincert.com) — Downloads correct chain for your certificate
• Certificate Chain Checker — Various online tools to visualize chains

Fixing Common Problems:

Problem: Incomplete Chain

# Nginx: Concatenate certificates in order (leaf + intermediates)
cat server.crt intermediate.crt > fullchain.crt
ssl_certificate /path/to/fullchain.crt;
ssl_certificate_key /path/to/server.key;

Problem: Wrong Order

# Correct order: leaf first, then intermediates toward root
# Never include the root certificate
cat leaf.crt intermediate1.crt intermediate2.crt > correct_chain.crt

Problem: Expired Intermediate

# Download fresh intermediate from CA
curl http://r3.i.lencr.org/ -o new_intermediate.der
openssl x509 -in new_intermediate.der -inform DER -out new_intermediate.pem
# Replace old intermediate in your chain file

In complex PKI environments, multiple valid paths may exist from an end-entity certificate to different trusted roots. Understanding how clients handle this is crucial for interoperability.

Why Multiple Paths Exist:

1. CA Re-keying — CA generates new key pair but old certificates remain valid
2. Cross-Certification — Multiple roots have issued certificates to the same CA
3. Trust Store Differences — Different clients trust different roots
4. Bridge CA Topology — Multiple bridge paths between PKI domains

Example: Let's Encrypt Multiple Paths

Path Selection Strategies:

Different implementations use different strategies:

Build all paths, validate shortest:

• Build all possible paths
• Attempt validation on shortest paths first
• Accept first valid path
• Advantage: Finds valid path even with expired alternates

Build path, validate, retry on failure:

• Build most likely path
• If validation fails, try alternate branches
• May miss valid path if heuristics are wrong

Validate during building:

• Check constraints and validity as path is built
• Prune invalid branches early
• Efficient but may miss some edge cases

Path Preference Policies:

Some validators have policies for path preference:

• Prefer shorter paths
• Prefer paths with longer-validity certificates
• Prefer paths through specific CAs
• Prefer RSA over ECDSA (or vice versa)