Incomplete Certificate Chain: What It Means and How to Fix It

Few SSL problems are as confusing as this one: the site loads perfectly on your laptop, but an Android phone shows a security warning, a payment gateway's webhook fails, or a script reports unable to get local issuer certificate. The usual culprit is an incomplete certificate chain, meaning the server is not sending the intermediate certificate that links your certificate to a trusted root.

How the chain of trust works

Browsers and operating systems ship with a small set of trusted root certificates. Certificate authorities keep those root keys offline and almost never use them directly. Instead, a root signs one or more intermediate certificates, and an intermediate signs your website's certificate (often called the leaf or end-entity certificate).

To trust your site, a client must build a path like this:

example.com (leaf)
   signed by  →  CA Intermediate
   signed by  →  CA Root (already trusted by the device)

The client already has the root. It needs the server to send the leaf and the intermediate. If the server sends only the leaf, the chain has a gap.

Why it works in some places and not others

Some clients try hard to fill the gap themselves:

Desktop browsers may already have the intermediate cached from another site that used it, or may download it using a URL embedded in the certificate (the Authority Information Access, or AIA, field).
Firefox ships with a preloaded list of known intermediates.

Many other clients do none of this. Command-line tools such as curl and wget, programming language HTTP libraries, payment and webhook services, older mobile devices, and IoT devices generally expect the server to send the full chain and simply fail if it does not. That is why an incomplete chain often goes unnoticed for weeks: the person who installed the certificate tested only in their own browser.

How to detect an incomplete certificate chain

The easiest option is an external test. Our SSL checker reports the chain the server actually presents and warns when intermediates are missing. From the command line, OpenSSL shows the chain the server sends:

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

Look at the Certificate chain section at the top of the output. A healthy chain lists at least two entries, numbered 0 (your site) and 1 (the intermediate). Near the bottom, Verify return code: 0 (ok) means OpenSSL could build a trusted path. A broken chain typically shows only entry 0 and a result such as Verify return code: 21 (unable to verify the first certificate).

A quick curl test also reveals the problem:

curl -I https://example.com

An error like SSL certificate problem: unable to get local issuer certificate on a machine with an up-to-date CA bundle points strongly to a missing intermediate.

Fixing the chain on common servers

First, get the correct intermediate. Your CA normally provides it alongside your certificate, often in a file named something like ca-bundle.crt, chain.pem or intermediate.crt. If you used Certbot, it already created fullchain.pem for you.

Nginx

Nginx expects the leaf and intermediates in a single file, leaf first:

cat example.com.crt intermediate.crt > example.com.fullchain.crt

ssl_certificate     /etc/ssl/example.com.fullchain.crt;
ssl_certificate_key /etc/ssl/example.com.key;

With Certbot, make sure ssl_certificate points to fullchain.pem, not cert.pem. This single-word mistake is one of the most common causes of broken chains.

Apache

Since Apache 2.4.8, SSLCertificateFile can also contain the full chain, leaf first. On older versions, use the separate directive:

SSLCertificateFile      /etc/ssl/example.com.crt
SSLCertificateChainFile /etc/ssl/intermediate.crt
SSLCertificateKeyFile   /etc/ssl/example.com.key

IIS (Windows Server)

IIS builds the chain from the Windows certificate store. Import the intermediate into the Intermediate Certification Authorities store for the local computer (using the Certificates MMC snap-in), then restart the site. Importing a .pfx that already includes the chain usually handles this automatically.

Load balancers and CDNs

Cloud load balancers and CDNs typically have a separate "certificate chain" field when you upload a custom certificate. Paste the intermediate there, not the root.

Common mistakes when fixing it

Wrong order. The leaf must come first, followed by the intermediate that signed it, then any higher intermediate.
Wrong intermediate. CAs operate several intermediates. Use the one supplied with your specific certificate; a mismatched intermediate is as bad as none.
Including the root. Sending the root is unnecessary because clients already have it, and it adds bytes to every handshake. It does not usually break anything, but leave it out.
Forgetting to reload. Run a config test and reload the service (for example sudo nginx -t then sudo systemctl reload nginx).
Fixing one server only. If several servers sit behind a load balancer, each one needs the corrected chain. Keeping certificate deployment scripted, as part of consistent server management, avoids servers drifting apart.

Key takeaways

An incomplete chain means the server sends your certificate without the intermediate that links it to a trusted root.
Desktop browsers often hide the problem; curl, APIs and mobile devices expose it.
Test with an external checker or openssl s_client -showcerts, not just your browser.
Serve the full chain (leaf first, then intermediates) and leave out the root.

Web Security articles