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

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.

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"

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

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

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
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

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.

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

With DNScale, you can manage CAA records and TLSA records to control and secure your certificate infrastructure.

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

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

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. Combined with DNS records like CAA and TLSA managed through DNScale, you can build a robust certificate security strategy.