Why does my site work in Chrome but fail elsewhere?

Browsers can fetch a missing intermediate via the certificate's AIA extension or reuse one they cached from another site, so they hide an incomplete chain. Stricter clients, OpenSSL, many Java and Android versions, and backend HTTP libraries, do not, so they fail while the browser succeeds.

What does 'unable to verify the first certificate' mean?

It is openssl's way of saying the server did not send the intermediate needed to link your leaf certificate to a trusted root. It almost always means an incomplete chain, fixed by serving the leaf plus its intermediates rather than the leaf alone.

Should I include the root certificate in the chain?

No. Clients already trust the root from their own trust store, so sending it adds bytes to every handshake for no benefit. Serve the leaf followed by the intermediate(s) up to but not including the root.

How to Fix an Incomplete SSL Certificate Chain

VigilDog Team · October 27, 2026 · 7 min read

The maddening thing about an incomplete certificate chain is that it usually works in your browser. You test the site, it loads with a padlock, you ship, and then a mobile app, a payment webhook, or a Java client fails to connect with a vague trust error. The certificate is valid; the problem is that your server isn't sending the whole chain. Here is how to confirm it and fix it for good.

What an incomplete chain actually is

A TLS certificate almost never chains directly to a trusted root. Your server's leaf certificate is signed by an intermediate CA certificate, which is in turn signed by the root that lives in every client's trust store. To verify you, a client needs the leaf and every intermediate up to (but not including) the root.

An incomplete chain means your server hands over the leaf but omits one or more intermediates. Some clients paper over this: modern browsers can fetch the missing intermediate via the AIA extension or reuse one they have cached from another site. Others, OpenSSL, many Java and Android versions, curl in scripts, backend HTTP clients, do not, and they reject the connection. That split is exactly why the bug looks intermittent and why 'it works on my machine' is a trap here.

The TLS certificate chain of trust

Confirm it with openssl

Don't guess from a browser. Ask the server what it actually sends:

openssl s_client -connect example.com:443 -servername example.com -showcerts
In the output, count the certificates in the 'Certificate chain' section. If you see only your leaf certificate and it is not self-signed, the chain is incomplete.
Check the last line: 'Verify return code: 21 (unable to verify the first certificate)' is the classic signature of a missing intermediate.
For a second opinion, SSL Labs' server test reports 'Chain issues: Incomplete' explicitly, and whatsmychaincert.com will even build the correct chain for you.

Build and serve the full chain

The fix is to present the leaf followed by every intermediate, in order, from leaf toward root. Concatenate them into one file, leaf first, then each intermediate:

cat leaf.crt intermediate.crt > fullchain.crt

Nginx, point ssl_certificate at the combined fullchain file (not the bare leaf), keep ssl_certificate_key on the private key, then reload. If you use Let's Encrypt, this is exactly what fullchain.pem is for.
Apache (2.4.8+), put the leaf-plus-intermediates bundle in SSLCertificateFile. The old SSLCertificateChainFile directive is deprecated but still works on older builds.
Load balancers and CDNs, paste the intermediate(s) into the 'certificate chain' or 'intermediate' field when you upload the certificate; many require it as a separate box.
Order matters: leaf, then intermediates toward the root. Do not append the root itself, it is unnecessary and wastes bytes on every handshake.

Common causes and gotchas

Most incomplete chains trace back to a handful of mistakes. The most common with Let's Encrypt is pointing the server at cert.pem (leaf only) instead of fullchain.pem, a one-word config difference. Another is a manual install where the CA emailed you a bundle and it was never concatenated in.

Wrong file: cert.pem / leaf only instead of fullchain.pem.
Wrong order: intermediate placed before the leaf, which some servers reject outright.
Stale intermediate after a CA rotation: certificate authorities periodically change their intermediates, and a hardcoded old bundle can go stale even though renewal succeeds. Re-fetch the chain your CA currently issues.
One node in a cluster fixed but not the others, every terminating server must serve the same full chain.

Stop it from coming back

A chain that is correct today can break silently at the next renewal or CA intermediate change, and because browsers hide the problem you often learn about it from an angry client instead of your own tests. The durable fix is to test the served chain from outside the browser and keep testing it.

Our free SSL checker inspects the chain a server actually presents, and if you want continuous coverage, VigilDog monitoring watches certificate validity and chain completeness across all your domains and alerts you before a renewal ships a broken bundle. If the underlying issue is an expired rather than incomplete certificate, see our guide on what to do when an SSL certificate has expired.