Why does my certificate work in Chrome but not elsewhere?

Its own leaf certificate, covering the hostname, plus every intermediate certificate needed to reach a trusted root.

The root itself is not sent: the client must already have it for the chain to mean anything, so including it wastes bytes on every handshake.

Certificate authorities publish the correct chain file alongside each issued certificate. Using it verbatim fixes essentially every chain problem.

Order matters for older clients — each certificate followed by the one that signed it — even though TLS 1.3 permits clients to reorder.

Browsers cache intermediates. A visitor whose browser encountered the same intermediate on another site completes the connection without noticing anything missing.

Some clients fetch a missing intermediate from the URL in the certificate's authority information access extension, which works and adds latency.

Neither behaviour is guaranteed, and neither is present in most non-browser clients.

The result is a fault the developer cannot reproduce while a real share of traffic fails — which is why it survives so long.

`openssl s_client -connect example.com:443 -servername example.com` prints the chain the server sent, numbered from the leaf.

A line reading `verify error: unable to get local issuer certificate` in that output means the chain is incomplete.

Test from a machine that has never visited the site, or from a container, so no cached intermediate rescues the result.

`curl -v https://example.com` is a quick second opinion: curl uses the system trust store and does not cache intermediates between runs.

Re-check after every renewal, since a renewal that replaces the leaf without updating the chain file reintroduces the problem.

A hostname not covered by the certificate. Browsers match only the subject alternative name entries, and `example.com` does not imply `www.example.com`.

An expired certificate, which every client rejects equally — so this is not the explanation when only some clients fail.

An old device with an out-of-date trust store, which genuinely lacks a root added in recent years. This affects old phones and embedded devices specifically.

A cross-signed chain whose older path has expired, which has caused large outages and presents exactly as a client-dependent failure.

Server Name Indication: a server presenting a default certificate to clients that do not send the hostname, which is rare on the public web and common on internal infrastructure.

VeriFixScan reports `transport.certificate_details` with the issuer, the validity window and the chain as presented.

`transport.certificate_coverage` reports which hostnames the certificate actually covers, which is the second cause above.

`availability.tls_failure` classifies a handshake that did not complete, separating a chain problem from an expired certificate or an unreachable host.

The scan does not carry a browser's cached intermediates, so it sees the chain the server really sends — which is the point of checking it this way.