Why Your TLS Certificate Chain Breaks (and How to Fix It)

You renewed your certificate, dropped the new files on the server, reloaded, and now half your clients report a TLS error. The two most common messages — unable to get local issuer certificate and certificate signed by unknown authority — almost always mean one thing: your certificate chain is incomplete or out of order. Here is how to find and fix that in a few minutes.

What a chain actually is

A TLS certificate is rarely trusted on its own. Your leaf certificate (the one for example.com) is signed by an intermediate CA, which is itself signed by a root CA that browsers already trust. To verify your leaf, the client needs to walk that path:

leaf (example.com) → intermediate → root (in the trust store)

The trick is that clients only ship with roots in their trust store — not intermediates. You must serve the intermediate(s). If you serve only the leaf, the client cannot build the path, and the handshake fails.

The two mistakes that break things

1. Serving only the leaf. Your bundle file must contain the leaf plus the intermediate(s). If you concatenated just fullchain.pem partially, the link is missing.

2. Wrong order. Most servers expect the leaf first, then the intermediates in signing order. A shuffled bundle confuses parsers. The root is usually omitted from the server bundle because clients already trust it.

Finding the broken link

Eyeballing a PEM bundle to see which link is missing is painful. Instead, paste the whole bundle into the SSL Chain Analyzer. It parses each certificate, reads its subject, issuer, validity window, and CA flag, and reconstructs the intended order.

For a healthy bundle you get:

• Chain complete — each certificate's issuer matches the next certificate's subject, all the way to a self-signed root.

For a broken one you get a precise diagnosis:

• Broken chain — names the certificate whose issuer is not in the bundle. That is usually a missing intermediate; with a standard rootless server bundle, it may simply be the intentionally omitted trusted root.
• Expired / not yet valid — flags any certificate outside its validity window so you can renew before it bites.
• Duplicate entries — catches the common copy-paste mistake of including the same intermediate twice.

The analysis runs entirely in your browser, so it's safe to paste real production certificates.

The fix, step by step

1. Get your intermediate from your CA (Let's Encrypt calls it the "chain" or "intermediate" file; commercial CAs ship it alongside the leaf).
2. Concatenate in order: leaf first, then intermediate(s). The root is usually omitted from the deployed server bundle because clients already have it.
3. Paste the bundle into the chain analyzer. For this analyzer's complete result, include the self-signed root in the pasted bundle too; with a standard rootless server bundle, its broken-at-root warning is expected and does not by itself mean the deployed bundle is invalid.
4. Point your server at the bundled file and reload.

Before you paste the CSR

If you're starting fresh, inspect your Certificate Signing Request first with the CSR Decoder to confirm the Common Name, key size, signature algorithm, and Subject Alternative Names are what you intend — before you pay for a certificate. SANs in particular are what modern browsers actually check; the CN is mostly cosmetic now.

Chains break for boring, mechanical reasons — a missing file, a shuffled order, an expired intermediate. A ten-second check with the analyzer turns a confusing outage into a one-line fix.