What Is an SSL Certificate Chain? Order, Check & Fix

What Is an SSL Certificate Chain?

An SSL certificate chain (also called a chain of trust or certification path) is the ordered list of digital certificates that connects your website's SSL/TLS certificate back to a trusted root Certificate Authority (CA). Each certificate in the chain is digitally signed by the one above it, creating a verifiable path of trust from your server all the way up to a root CA that browsers already trust.

Think of it like a chain of endorsements. Your server certificate says "I am example.com." The intermediate CA says "I vouch for example.com's certificate." The root CA says "I vouch for that intermediate." Your browser already trusts the root CA, so by following the chain of signatures, it trusts your server too.

When you visit an HTTPS site, your browser traces this chain in milliseconds. If every link checks out, the page loads with no warning. If a link is missing, expired or untrusted, you get a security warning such as NET::ERR_CERT_AUTHORITY_INVALID instead.

The Three Kinds of Certificate in a Chain

Every chain has three kinds of certificate, though a server may send more than one intermediate:

Root Certificate

The root certificate is the trust anchor at the top of the chain. It is self-signed, meaning the Certificate Authority signed its own certificate. Root certificates are pre-installed in your browser and operating system — this collection is called the trust store.

Chrome's own root list holds about 100 roots (Chrome Root Store); Mozilla, Apple and Microsoft keep their own lists. Organisations such as DigiCert, Let's Encrypt (ISRG), Sectigo, GlobalSign and Google Trust Services run roots. Because root keys are so valuable, CAs keep them offline in hardware security modules and use them only to sign intermediates.

Intermediate Certificate

Intermediate certificates sit between the root and your server certificate. The root CA signs the intermediate certificate, and the intermediate CA then signs end-entity (server) certificates. Most CAs use one or two intermediates.

Your web server must send intermediate certificates along with your leaf certificate during the TLS handshake. Chrome can download a missing intermediate and Firefox preloads them, but apps, API clients and older Android devices have neither, so for them the chain breaks.

Leaf Certificate (Server Certificate)

The leaf certificate (also called end-entity or server certificate) is the certificate installed on your web server. It contains your domain name, your public key, the validity period, and information about the issuer (the intermediate CA that signed it).

This is the first certificate your browser receives during the TLS handshake. The browser then works its way up the chain, verifying each signature until it reaches a trusted root.

How the Chain of Trust Works

When your browser connects to a website over HTTPS, the TLS handshake triggers a chain verification process that happens in milliseconds:

• The server sends its certificates — the leaf, then the intermediates.
• The browser builds a path — from the leaf up to a root in its own list. If an intermediate is missing, Chrome downloads it from the address written in the certificate (AIA), and Firefox uses its own preloaded set; many other clients just fail.
• Signatures are checked — each certificate must be signed by the key of the one above it.
• The root is checked — the path must end at a root in the browser's list. An unknown root fails.
• Validity is checked — every certificate must be within its dates and not revoked, and the leaf must cover the name in the address bar.

Real Chains: What 12 Big Sites Send

We asked 12 of the biggest sites for their chains on 27 October 2026 (openssl s_client -showcerts, from two locations). None sent just a leaf, and several sent extra cross-signed certificates so that older devices can still reach a root they know. What a server sends can change with your TLS version, whether your client supports ECDSA, and which CDN location answers: facebook.com, for example, sent 3 certificates over TLS 1.2.

What Happens After Verification

If every check passes, the connection goes ahead. If any one fails, even on an intermediate, the browser shows a warning such as "Your connection is not private" with a code like NET::ERR_CERT_AUTHORITY_INVALID. (Failures before any certificate is looked at, during the TLS handshake itself, show other codes: ERR_SSL_PROTOCOL_ERROR or ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

This is why the entire chain matters, not just the leaf certificate. An expired intermediate breaks HTTPS just like an expired server certificate, unless the client can build another path around it.

Why Intermediate Certificates Exist

Root CAs could theoretically sign every server certificate directly, skipping intermediates entirely. But there are three critical reasons why they don't:

• Security isolation — Root CA private keys are kept offline in HSMs inside physically secured vaults. They are used only to sign intermediates, not millions of individual server certificates. This drastically reduces the risk of the root key being compromised.
• Damage containment — If an intermediate CA is compromised, only that intermediate's certificates are affected. The root CA can revoke the compromised intermediate and issue a new one — without invalidating every certificate it has ever issued.
• Operational flexibility — CAs use different intermediates for different purposes: one for DV certificates, another for EV, separate ones for different regions or key algorithms (RSA vs ECDSA).

How to Check Your SSL Certificate Chain

There are three ways to inspect a website's certificate chain, from command-line tools to browser-based checks.

Method 1: OpenSSL (Command Line)

The openssl command is the most detailed way to inspect a certificate chain. Run this in your terminal:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

Method 2: Browser Certificate Viewer

Every major browser shows the chain it built (which may differ from what the server sent, if it fetched a missing intermediate itself):

• Chrome: click the icon left of the address → Connection is secure → Certificate is valid, then open the Details tab to see the certificate hierarchy
• Edge: click the padlock → Connection is secure → the certificate icon at the top of the panel
• Firefox: click the padlock → Connection secure → More information → View Certificate; each certificate in the chain gets its own tab
• Safari (18.4 and later): choose Safari > Connection Security Details in the menu bar (Apple); on iPhone, tap the left side of the address field → Privacy & Security → Connection Security Details

Method 3: DNS Robot SSL Checker

The quickest check from outside your network is our SSL Checker: it shows the chain the server sends, whether the Mozilla, Chrome, Apple and Microsoft root lists each trust it, a warning when the chain is incomplete, and every certificate's dates. For sites behind Cloudflare it reads the certificate from public CT logs, so there the chain the server sends isn't checked.

Common Certificate Chain Errors and How to Fix Them

Certificate chain problems are one of the most frequent causes of HTTPS errors. Here are the errors you are most likely to encounter and how to resolve each one.

Missing Intermediate Certificate

Error message: "unable to get local issuer certificate" (curl, Python, PHP), "unable to verify the first certificate" (Node.js) or "incomplete certificate chain"

Cause: the server sends only the leaf certificate. Chrome often repairs this by downloading the intermediate itself (so does Apple's verifier), so the site may look fine in a browser while curl on Linux, Python, Java, payment callbacks and many apps fail.

Fix: send the intermediates with the leaf. With Let's Encrypt, point your server at fullchain.pem, not cert.pem; with another CA, download its intermediate and put it after your certificate in one file:

cat your-domain.crt intermediate.crt > fullchain.crt

Self-Signed Certificate in Chain

Error message: "self-signed certificate in certificate chain" (OpenSSL error 19)

Cause: the chain ends in a root the client doesn't trust: a private or company CA, or a proxy or antivirus that re-signs traffic with its own root. Sending a root the client does trust is harmless, just unnecessary.

Fix: use a certificate from a public CA for public sites, or install the private root on the clients that need it. Leaving the root out of the server's chain is tidy but won't fix this error.

Wrong Certificate Order

Error message: chain verification fails in some clients, or they report the certificate as not trusted.

Cause: the certificates in the chain file are in the wrong order. TLS 1.3 requires the server's own certificate first and asks for the rest in order, while telling clients to cope with other orders (RFC 8446 §4.4.2); older or stricter clients may not.

Fix: put the leaf certificate first, then each intermediate, starting with the one that signed your leaf.

Expired Certificate in Chain

Error message: "certificate has expired" — but your leaf certificate's expiry date looks fine.

Cause: a certificate higher up the chain has expired. The best-known case: IdenTrust's DST Root CA X3, which cross-signed Let's Encrypt's root, expired on 30 September 2021, and devices that didn't trust ISRG Root X1 (and clients on OpenSSL 1.0.x) began failing on Let's Encrypt sites.

Fix: Download the current intermediate certificate from your CA and replace the old one. Then use our SSL Checker to verify the updated chain.

Certificate Chain Best Practices

• Always send the intermediates — don't count on browsers repairing the chain; apps and API clients won't.
• The root is optional — clients use their own copy, so sending a root they trust only adds bytes; a cross-signed root for older devices is a deliberate exception.
• Keep the order — leaf first, then the intermediates from the one that signed your leaf upwards.
• Automate renewal — certificates issued since March 2026 last at most 200 days, falling to 100 in March 2027, and Let's Encrypt moves to 64-day certificates in February 2027.
• Check after every renewal or move — a CA can switch intermediates between renewals. Run the site through the SSL Checker afterwards.
• Watch every name — www, the bare domain and each subdomain can be served by different certificates and chains. The Subdomain Finder lists the names your certificates have covered, from public certificate logs.