What Is an SSL Certificate Chain

An SSL certificate chain (also called a certificate chain of trust) is the ordered list of certificates that connects your server's SSL/TLS certificate back to a trusted root Certificate Authority (CA). Browsers and operating systems use this chain to verify that your website's certificate is legitimate.

How the Certificate Chain Works

Every HTTPS connection relies on a chain of trust with three layers:

Root CA Certificate (self-signed, trusted by browsers/OS)
  └── Intermediate CA Certificate (signed by Root CA)
        └── Leaf Certificate (your server's certificate, signed by Intermediate CA)

When a browser connects to your site:

1. Your server presents the leaf certificate (your domain's cert) and any intermediate certificates
2. The browser walks up the chain, verifying each certificate's signature against its issuer
3. Once it reaches a root certificate that's already in the browser's trust store, the chain is verified
4. The connection is established as secure

Each certificate in the chain contains the issuer's distinguished name and the subject's public key. The browser verifies each signature using the issuer's public key, creating a cryptographic chain from your leaf certificate all the way to a trusted root.

Why Intermediate Certificates Exist

Root CA certificates are extremely valuable — if a root key is compromised, every certificate it issued becomes untrusted. To minimize risk:

• Root CAs are kept offline in air-gapped, high-security environments
• Root CAs sign a small number of intermediate CA certificates
• Intermediate CAs handle the day-to-day work of issuing certificates to websites
• If an intermediate is compromised, only that intermediate is revoked — the root remains trusted

This layered approach is why most certificate chains have 3 levels, though some chains are longer. Some CAs use two levels of intermediates, resulting in a 4-certificate chain. The key principle is that the root must never be exposed to online operations.

Root Trust Stores

Every browser and operating system maintains its own root trust store — a curated list of root CA certificates that it trusts. These stores are carefully managed:

• Mozilla NSS — used by Firefox, contains around 150 root CAs
• Apple Trust Store — used by Safari and macOS/iOS applications
• Microsoft Root Certificate Program — used by Windows and Edge
• Google Chrome Root Store — Chrome is transitioning to its own root store

When your certificate chain terminates at a root that's not in the client's trust store, the connection fails. This is why self-signed certificates and certificates from unknown CAs produce browser warnings.

Root trust stores are updated regularly. If a CA is found to have issued certificates improperly, its root can be removed from trust stores, effectively revoking all certificates in its chain. This has happened to several major CAs over the years.

Certificate Chain Example

Here's what a real certificate chain looks like for www.example.com:

[Root]         ISRG Root X1
                 ↓ signs
[Intermediate] Let's Encrypt R3
                 ↓ signs
[Leaf]         www.example.com

You can inspect any site's chain using OpenSSL:

openssl s_client -connect www.example.com:443 -showcerts

Or using curl with verbose output:

curl -vI https://www.example.com 2>&1 | grep -A6 "Server certificate"

Chain Validation in Detail

When a browser validates a certificate chain, it performs several checks on each certificate:

1. Signature verification — the certificate's signature is valid using the issuer's public key
2. Validity period — the certificate's notBefore and notAfter dates are within range
3. Revocation status — checked via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol)
4. Name constraints — the certificate's subject matches the requested domain
5. Key usage — the certificate is authorized for TLS server authentication
6. Path length — intermediate CA certificates respect pathLenConstraint if set

# Verify a full chain locally with OpenSSL
openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem
 
# Check certificate details including validity dates and extensions
openssl x509 -in leaf.pem -noout -text
 
# Check OCSP revocation status
openssl ocsp -issuer intermediate.pem -cert leaf.pem \
  -url http://ocsp.example.com -resp_text

Common Certificate Chain Errors

Incomplete Chain (Missing Intermediate)

The most common SSL error. Your server sends the leaf certificate but not the intermediate:

Browser error: "Unable to verify the first certificate"
              "ERR_CERT_AUTHORITY_INVALID"

Fix: Configure your web server to send the full chain. Most CAs provide a "full chain" or "CA bundle" file:

# Nginx — use the full chain file
ssl_certificate     /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/privkey.pem;

# Apache — specify the chain separately
SSLCertificateFile    /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCertificateChainFile /etc/ssl/certs/chain.pem

Desktop browsers often cache intermediate certificates from previous visits, which can mask a misconfigured server. Mobile browsers and API clients typically don't cache intermediates, so they fail more reliably on broken chains. Always test with a fresh client.

Wrong Order

Certificates in the chain file must be ordered from leaf to root:

-----BEGIN CERTIFICATE-----
(Your server/leaf certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root certificate — optional, browsers already have it)
-----END CERTIFICATE-----

Expired Intermediate Certificate

Even if your leaf certificate is valid, an expired intermediate breaks the chain. Check expiration dates:

openssl x509 -in intermediate.pem -noout -dates

This was a widespread issue in September 2021 when the IdenTrust DST Root CA X3 expired, breaking Let's Encrypt chains on older devices. The fix was to switch to the ISRG Root X1 chain.

Cross-Signed Certificates

Some CAs use cross-signing to maintain compatibility with older trust stores. A cross-signed intermediate is signed by two different root CAs, creating two possible trust paths. This provides broader device compatibility but can complicate chain configuration.

Self-Signed Certificate

A self-signed certificate has no chain — the leaf signs itself. Browsers don't trust these by default because there's no third-party verification.

How to Verify Your Certificate Chain

Using OpenSSL

# Check the full chain from a live server
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com
 
# Verify a certificate file against a CA bundle
openssl verify -CAfile ca-bundle.crt server.crt
 
# Show the complete chain with certificate details
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

Look for Verify return code: 0 (ok) in the output.

Using Online Tools

Most SSL testing tools will show you the complete chain and flag any issues, including missing intermediates or expiring certificates.

Using dig for DNS-Based Certificate Verification

DANE (DNS-Based Authentication of Named Entities) uses TLSA records to publish certificate information in DNS:

dig TLSA _443._tcp.yourdomain.com

This allows domain owners to specify exactly which certificates are valid for their domain, adding a DNS layer of verification on top of the traditional CA chain. You can manage TLSA records in DNScale to enable DANE for your domains.

DANE verification works best when combined with DNSSEC, which ensures that the TLSA records themselves haven't been tampered with. Without DNSSEC, an attacker could spoof TLSA records to redirect trust.

Certificate Chain and DNS

DNS plays an important role in certificate issuance and verification:

• Domain Validation (DV): CAs verify domain ownership via DNS records (TXT or CNAME)
• CAA Records: Specify which CAs are allowed to issue certificates for your domain
• DANE/TLSA: Publish certificate fingerprints directly in DNS for additional validation
• ACME DNS-01 Challenge: Let's Encrypt and other ACME CAs can validate domain ownership by creating a TXT record under _acme-challenge.yourdomain.com

With DNScale, you can manage CAA records and TLSA records to control and secure your certificate infrastructure. You can also automate ACME DNS-01 challenges via the DNScale API for fully automated certificate issuance.

Certificate Transparency

Certificate Transparency (CT) is a public logging system that records all issued certificates. CAs are required to submit certificates to CT logs before issuance. You can monitor CT logs to:

• Detect unauthorized certificates issued for your domain
• Verify that your CA is properly logging certificates
• Audit certificate issuance across your organization

CAA records work alongside CT by restricting which CAs can issue in the first place, while CT provides after-the-fact visibility into what was actually issued.

Best Practices

1. Always include intermediate certificates — never send just the leaf certificate from your server
2. Use CAA records to restrict which CAs can issue certificates for your domains
3. Automate certificate renewal — expired certificates (or intermediates) break the chain
4. Monitor certificate expiration across your entire chain, not just the leaf
5. Test after every change — verify the full chain works after renewing or replacing certificates
6. Consider DANE — publish TLSA records with DNSSEC for an additional layer of trust
7. Use Certificate Transparency monitoring — detect unauthorized issuance early
8. Test on multiple platforms — verify your chain works on mobile, desktop, and API clients

Related Topics

• SSL and TLS Certificates Explained — overview of SSL/TLS
• What Is a CAA Record — restrict certificate issuance via DNS
• What Is a TLSA Record — DANE certificate pinning in DNS
• DNSSEC Key Management — securing DNS for DANE
• What Is a TXT Record — DNS-based domain validation
• DNS Security: Attacks and Threats — threats that affect certificate validation
• What Is DNS — how DNS resolution underpins certificate validation

Conclusion

The SSL certificate chain is the backbone of trust on the web. Understanding how root, intermediate, and leaf certificates connect ensures you can properly configure HTTPS on your servers and quickly diagnose certificate errors. Each link in the chain must be valid, properly ordered, and verifiable back to a trusted root. Combined with DNS records like CAA and TLSA managed through DNScale, you can build a robust certificate security strategy that prevents unauthorized issuance and adds DNS-based verification on top of the traditional CA model.