Why an SSL Checker Says the Certificate Chain Is Incomplete

An SSL checker that reports an incomplete certificate chain is usually telling you something very specific:

the server is not presenting enough certificate material for clients to build trust cleanly.

That does not always mean the hostname certificate is wrong. More often, it means the intermediate certificates are missing, out of order, or not part of the active public TLS path.

The short explanation

If the server sends only the leaf certificate and omits the intermediate chain, an SSL checker can flag the site even when some browsers still seem to work.

Current Certbot documentation explains why this is confusing in practice: some browsers may still work some of the time, while others show untrusted-connection errors.

That is exactly the kind of partial failure that makes operators doubt the checker instead of the chain.

What "incomplete chain" really means

Clients usually need more than the leaf certificate to validate trust.

They need the intermediate certificates that link the site certificate to a trusted root.

If the server does not present those intermediates correctly, trust building can fail.

That is why a chain problem is a presentation problem as much as a certificate problem.

The highest-probability causes

1. The server is using cert.pem instead of fullchain.pem

This is the most common cause in Certbot-managed NGINX environments.

cert.pem is just the leaf certificate. fullchain.pem contains the leaf certificate plus the intermediate chain that NGINX normally needs to serve.

2. The certificate bundle order is wrong

Current NGINX documentation says the server certificate should appear first in the file, followed by the intermediate certificates.

If that order is wrong, the chain can still fail even if all the right certificate blocks are technically present.

3. The public edge is not using the same chain as the origin

A reverse proxy, load balancer, or CDN can still be serving an older or incomplete bundle while the origin host already has the correct one.

This is one reason domain and hosting context matter when investigating chain problems.

4. A copied PEM file drifted stale

If the deployment copied certificate files into a custom location once and never refreshed them correctly, the public service can keep serving an outdated or incomplete bundle after later renewals.

5. The wrong virtual host is being hit

Sometimes the checker reports the "wrong" chain because the hostname is actually landing on a different HTTPS server block or edge certificate than the operator expects.

This is where SNI and wrong-certificate selection become part of the diagnosis.

Why some browsers still appear fine

This is the part that misleads people most.

Some clients can build trust from intermediates they already know or have cached. Others cannot.

So the site can look fine in:

• one browser
• one device
• one corporate network

while still failing a proper external checker or another client stack.

That is not proof the checker is wrong. It is usually proof that the chain is only partially working.

Why this belongs in the domain lookup workflow

A chain issue is not always local to the origin server.

If domain lookup shows the hostname terminates on:

• shared HTTPS hosting
• a reverse proxy
• a CDN
• an ingress or load balancer

then the public chain can be different from the local files on the app host.

That makes certificate-chain troubleshooting part of hosting and routing analysis, not just PEM-file inspection.

What to check first

1. Check what the public hostname actually serves

Start with the public hostname, not the local filesystem.

2. Check whether the active config uses fullchain.pem

For standard Certbot + NGINX setups, this is one of the highest-value checks.

3. Check whether the bundle order is correct

The leaf certificate should come first, followed by the intermediates.

4. Check whether the hostname is terminating on an edge or another server

If the public hostname does not terminate where you think it does, you may be fixing the wrong machine.

5. Check for SNI or wrong-virtual-host selection

If the wrong certificate is being served for the hostname, the checker can report chain problems that are really about host selection.

The practical rule

Do not dismiss an incomplete-chain warning just because one browser looks fine.

Instead:

• verify the public certificate path
• verify the file choice
• verify the chain order
• verify the actual TLS terminator

That sequence catches the majority of real-world chain issues.

Common misunderstandings

"The site is secure in my browser, so the chain must be complete"

No.

One client succeeding is not enough evidence that the public chain is being served correctly to all clients.

"An incomplete-chain warning means the leaf certificate is expired"

Not necessarily.

The leaf certificate may still be valid while the trust chain is incomplete.

"This is only a browser problem"

No.

APIs, mobile apps, monitoring systems, and older client stacks can all fail differently when the chain is incomplete.

FAQ

Why does an SSL checker say the chain is incomplete?

Because the server is not presenting enough intermediate-certificate information, or it is presenting it in the wrong order, for clients to build trust cleanly.

Why do some browsers still work?

Because some clients can rely on intermediates they already know or cached, while others need the server to present the full chain correctly.

What file should I check first in a Certbot + NGINX setup?

Check whether the active server config is using fullchain.pem rather than only cert.pem.

Can a wrong edge server or proxy cause this too?

Yes. If the public hostname terminates on another layer, the incomplete chain may be coming from that edge rather than the origin host you renewed.