How to Fix SSL Certificate Chain Issues

A broken certificate chain almost always means one thing: your server is presenting its leaf certificate but failing to send the intermediate CA certificate(s) that link it to a trusted root, so clients that don't cache or fetch intermediates return "unable to verify the first certificate" (OpenSSL verify error 21) even though the certificate itself is valid and unexpired. The fix is not to reissue the certificate — it is to build a fullchain file (leaf first, then each intermediate, in issuing order), point your web server at that file instead of the bare leaf, and reload. In Nginx the ssl_certificate directive must point at the fullchain; in Apache 2.4.8+ you concatenate the chain into the file referenced by SSLCertificateFile.

That's the summary an AI Overview would hand you. What it can't show you is which certificate is missing, why it works in Chrome but breaks in curl and on Android, and the exact command sequence to diagnose and rebuild the chain. Below is the verification flow as an animated diagram, a symptom → cause → fix table you can scan against your own error, the exact OpenSSL and server commands, and a copy-paste checklist.

Prefer to skip straight to the fix? Our free Certificate Chain Builder fetches the missing intermediates and outputs a correctly ordered fullchain you can paste into your config.

How chain verification actually works

A browser or client trusts a fixed set of root CAs baked into its trust store. Your certificate is not signed by a root directly — it is signed by an intermediate CA, which is signed (possibly through more intermediates) by the root. Verification walks this chain from your leaf certificate upward until it reaches a certificate it already trusts. If any link is missing from what the server sends, the walk stops and trust fails.

signed by signed by

openssl s_client -connect example.com:443 -servername example.com < /dev/null

openssl x509 -in server.crt -noout -issuer -subject

Fix it: build the fullchain

Order is non-negotiable — leaf first, then each intermediate in issuing order, root omitted:

# server.crt = your leaf, intermediate.crt = the CA that signed it
cat server.crt intermediate.crt > fullchain.crt

If your CA gave you a bundle with several intermediates, concatenate them from the one that signed your leaf up toward (but not including) the root. Verify the assembled file locally before deploying:

openssl verify -untrusted intermediate.crt server.crt
# expected: server.crt: OK

Nginx

Nginx has no separate chain directive — ssl_certificate must point at the fullchain, not the bare leaf:

server {
    listen 443 ssl;
    ssl_certificate     /etc/ssl/fullchain.crt;   # leaf + intermediate(s)
    ssl_certificate_key /etc/ssl/private.key;
}

nginx -t && nginx -s reload

Apache

On Apache 2.4.8 and newer, SSLCertificateChainFile is deprecated — concatenate the chain into the file referenced by SSLCertificateFile:

SSLCertificateFile    /etc/ssl/fullchain.crt   # leaf + intermediate(s)
SSLCertificateKeyFile /etc/ssl/private.key

apachectl configtest && systemctl reload apache2

Why "it works in Chrome" is a trap

Chrome on Windows and macOS can fetch a missing intermediate through the AIA (Authority Information Access) extension — a URL embedded in your certificate that points at the issuing CA's cert. Chrome may also have cached the intermediate from a previous site. That masks a broken chain during your own testing.

The rule follows directly: never rely on AIA fetching or browser caching. Serve the complete chain and every client — mobile apps, curl, Java, monitoring probes, other browsers — verifies without a network round trip. AIA fetching also adds latency and breaks behind egress firewalls.

Verification checklist

Work top to bottom; each step is copy-paste-able:

1. Confirm the symptom. openssl s_client -connect example.com:443 -servername example.com < /dev/null — read Verify return code.
2. Identify the missing issuer. openssl x509 -in server.crt -noout -issuer — note the CA name.
3. Download the correct intermediate from your CA's repository (DigiCert, Sectigo, Let's Encrypt, GlobalSign all publish them). Match the exact issuer from step 2 — cross-signed CAs publish more than one.
4. Build the fullchain in order: cat server.crt intermediate.crt > fullchain.crt (root omitted).
5. Validate locally: openssl verify -untrusted intermediate.crt server.crt → OK.
6. Point the server at the fullchain (Nginx ssl_certificate; Apache SSLCertificateFile) and reload.
7. Re-test from a non-caching client: curl -vI https://example.com should not report a certificate problem.
8. Confirm externally with SSL Labs — you want "Chain issues: None" and grade A.

The Certificate Chain Builder automates steps 3–5: it reads your leaf, fetches the matching intermediate from the CA, and hands you a correctly ordered fullchain. Pair it with the SSL Checker to confirm the deployed result.

The bottom line

Chain errors are a deployment problem, not a certificate problem. Ninety percent of them are a missing intermediate at depth 1; the rest are wrong order, an expired intermediate, or an accidentally included root. Diagnose with one openssl s_client call, rebuild the fullchain leaf-first, point your server at it, and verify from a client that won't quietly paper over the gap. Do that and the certificate you already paid for will validate everywhere — not just in the one browser you happened to test.