An SSL certificate chain (also called a certificate chain of trust) is the ordered list of digital certificates that links your server's SSL/TLS certificate back to a trusted root Certificate Authority (CA). Think of it like a chain of vouchers: your server's certificate says "I was vouched for by this intermediate CA," and that intermediate says "I was vouched for by this root CA." The browser already trusts the root, so by extension, it trusts your server.
When the chain is broken or incomplete, browsers throw warnings like "Your connection is not private" or NET::ERR_CERT_AUTHORITY_INVALID — and your users see a scary full-page error instead of your site.
How the SSL Certificate Chain Works
The Three Levels of Trust
A typical certificate chain has three layers:
Root Certificate — Owned by a Certificate Authority like DigiCert, Let's Encrypt, or GlobalSign. Root certificates are self-signed and come pre-installed in browsers and operating systems. They're the ultimate trust anchors, stored in what's called the trust store.
Intermediate Certificate — Issued by the root CA (or by another intermediate). This is the workhorse that actually signs your certificate. CAs use intermediates so they never have to expose the root certificate's private key during day-to-day operations. If something goes wrong with an intermediate, the root stays safe.
Server (End-Entity) Certificate — This is the certificate on your web server, tied to your domain (e.g., example.com). It's signed by an intermediate CA.
What Happens During the TLS Handshake
When a browser connects to your site over HTTPS, here's the verification flow:
- Your server sends its certificate along with any intermediate certificates
- The browser checks your certificate's signature against the intermediate's public key
- It then checks the intermediate's signature against the next cert up the chain
- This continues until the browser hits a root certificate it already has in its trust store
- If every signature checks out and the root is trusted, the connection proceeds
Example Chain
Root CA Certificate (DigiCert Global Root G2)
└── Intermediate CA Certificate (DigiCert TLS RSA SHA256 2020 CA1)
└── Server Certificate (www.example.com)
Here, www.example.com's certificate was signed by DigiCert's intermediate, which was signed by DigiCert's root. The browser trusts DigiCert's root because it ships with the browser, so the whole chain holds up.
Why Intermediate Certificates Exist
You might wonder: why not just have the root CA sign every certificate directly? There are a few good reasons:
Security — Root CA private keys are extraordinarily valuable. If one were compromised, every certificate it ever signed would be suspect. Keeping the root offline and delegating signing to intermediates limits the blast radius.
Damage control — If an intermediate gets compromised, you revoke just that intermediate. The root and the other intermediates keep working fine.
Scale — A single root CA can have multiple intermediates handling issuance for different regions, products, or validation levels. The root doesn't need to be involved in every signing operation.
Common Certificate Chain Errors
Incomplete Certificate Chain
This is by far the most common problem. The server sends only the end-entity certificate but not the intermediates. The browser can't build a path to a trusted root and gives up.
What you'll see:
SSL_ERROR_UNKNOWN_ISSUERin FirefoxNET::ERR_CERT_AUTHORITY_INVALIDin Chromeunable to get local issuer certificatein curl or OpenSSL
The fix: Configure your web server to serve the full chain — your certificate plus all the intermediates.
The tricky part is that this sometimes works in browsers but fails in curl or API clients. That's because some browsers can fetch missing intermediates on their own (called AIA fetching), but most command-line tools and libraries don't. So you might not notice the problem until a customer's integration starts failing.
Wrong Certificate Order
The correct order is: server certificate first, then intermediates from lowest to highest. The root certificate should be left out (browsers already have it). Getting this backwards will break things for some clients.
Expired Intermediate or Root Certificate
If any certificate in the chain has expired, the entire chain fails validation. This catches people off guard because they track their server cert's expiration date but forget that intermediates expire too — just on a much longer timeline.
Self-Signed Certificate Errors
A self-signed certificate has no chain of trust at all. There's no CA backing it up, so browsers have no way to verify it's legitimate. This is fine for local development, but not for production.
How to View the Certificate Chain
In a Browser
- Click the padlock icon in the address bar
- Go to Certificate or Connection is secure > Certificate is valid
- Look at the Certification Path tab to see the full hierarchy
Using OpenSSL
openssl s_client -connect example.com:443 -showcerts
This prints each certificate in the chain with its subject, issuer, and validity dates. It's the quickest way to debug chain issues from the command line.
Using curl
curl -vI https://example.com 2>&1 | grep -A 6 "Server certificate"
Configuring the Certificate Chain on Your Server
Nginx
ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/server.key;
The fullchain.pem file should contain your server certificate followed by the intermediate(s), concatenated together.
Apache
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt
Creating the Full Chain File
cat server.crt intermediate.crt > fullchain.pem
If you have multiple intermediates, concatenate them in order — the one that signed your server cert first, then the one above it:
cat server.crt intermediate1.crt intermediate2.crt > fullchain.pem
SSL Certificate Chain vs. Certificate Pinning
Certificate chain validation is the standard approach — the browser walks the chain up to a trusted root. It's flexible and works automatically when CAs rotate certificates.
Certificate pinning takes a different approach: you hardcode specific certificates or public keys into your application, so it only accepts those exact ones. This protects against a compromised CA issuing a fraudulent certificate for your domain, but it's fragile. If you forget to update the pinned certificate before it expires, your app breaks. Chrome removed support for HTTP Public Key Pinning (HPKP) back in 2020 for exactly this reason. Some mobile apps still use pinning, but it requires careful lifecycle management.
SSL vs. TLS: A Note on Terminology
Technically, SSL has been dead since 2015 — modern connections all use TLS (Transport Layer Security). But "SSL certificate" stuck as the common name, and everyone knows what you mean. The certificate chains described here work the same way regardless of whether you call them SSL or TLS.
Best Practices
Always serve the full chain — Don't assume clients will fetch missing intermediates. Many won't.
Leave out the root certificate — Browsers already have it. Sending it just wastes bytes during the handshake.
Monitor all expiration dates — Not just your server cert. Set alerts for intermediate expirations too.
Automate certificate management — Let's Encrypt with Certbot or any ACME client handles issuance, chain assembly, and renewal for you. There's very little reason to manage this manually in 2026.
Test before you deploy — Run openssl s_client against your server after any certificate change. Catching a broken chain in staging is much better than catching it from a customer ticket.
Keep trust stores current — Make sure your servers and clients have up-to-date CA root bundles, especially in Docker containers or embedded systems where they might not update automatically.
Frequently Asked Questions (FAQ)
What happens if the certificate chain is broken?
The browser can't verify who your server is, so it shows a security warning. Programmatic clients like curl or API libraries will usually refuse to connect at all. Either way, your users or integrations are blocked.
Do I need to include the root certificate in my chain?
No. Browsers and operating systems already have root certificates in their trust stores. Sending the root in your chain is harmless but unnecessary — just extra bytes on the wire.
How many certificates are in a typical chain?
Usually two or three: your server certificate plus one or two intermediates. The root is implied but not sent.
Can a certificate chain have multiple intermediate certificates?
Yes. Some CAs use multi-level hierarchies or cross-signed intermediates, resulting in chains with two or more intermediates between your server cert and the root. This is more common than you might expect.
How do I fix "unable to verify the first certificate" errors?
Nine times out of ten, this means your server isn't sending the intermediate certificates. Update your server config to include the full chain file and restart.
What is cross-signing in certificate chains?
Cross-signing is when an intermediate certificate is signed by more than one root CA. Let's Encrypt did this early on — their intermediate was signed by both their own root (ISRG Root X1) and IdenTrust's root. This meant older devices that didn't have Let's Encrypt's root yet could still trust the chain through IdenTrust.
How often should I renew my SSL certificate chain?
Server certificates typically renew every 90 days (Let's Encrypt) to one year. Intermediates and roots last much longer — 5 to 20 years — but you should still track their expiration dates. Automated tools like Certbot handle the server cert renewal for you.
Does the certificate chain affect website performance?
Barely. The chain adds a small amount of data to the TLS handshake, but we're talking about a few kilobytes at most. TLS 1.3 and session resumption minimize the impact further. This isn't something worth optimizing unless you're shaving milliseconds off every request.
