The hostname matches.
The chain is complete — every intermediate is present, each certificate signs the next, and it all leads up to a single certificate at the top.
The dates are fine.
And the browser still slams the door: Every stack says it in its own accent.
Chrome and Edge say .
Firefox says — or when the leaf signed itself. curl says .
Node says or .
Python says .
OpenSSL prints (or for a self-signed leaf).
One root cause, many dialects: the client followed the chain all the way to the top and did not recognize the authority sitting there.
This is a different failure from the two it's most often confused with.
It is not a name mismatch (the hostname is fine) and — the subtle one — it is not simply an incomplete chain.
A missing intermediate breaks a path to a root the client would have trusted; this is the client reaching the root and refusing it.
The chain can be perfect and still end at an anchor the client will never accept.
Trust Is About the Anchor, Not the Path Certificate validation does two separate things, and it's easy to conflate them.
First it builds a path: leaf → intermediate(s) → root, each link signed by the next one up.
Then it checks whether the anchor at the top of that path — the root — is one it already trusts, because it ships in the client's trust store (the OS or browser root program) and its public key is baked in.
An incomplete-chain error is a path failure: the client couldn't assemble the links, usually because the server didn't send an intermediate. is an anchor failure: the path is fine, the client reached the top, and the certificate up there is not in any trust store it consults.
No amount of adding intermediates fixes that — you can hand the client a beautifully complete chain and it will still reject it, because completeness is not the same as being anchored in a trusted root.
That's the whole error in one sentence: the client built a chain to a root it does not trust.
The question is never "is this chain complete?" It can be.
The question is "does this chain terminate in a root the client already trusts?" — and when the answer is no, you get , no matter how tidy everything below the root looks.
What Actually Causes It In rough order of how often they bite: A self-signed certificate.
The leaf signed itself; there is no separate CA at all.
Ubiquitous on , internal dashboards, appliances, IoT devices, staging boxes, and anything stood up with in thirty seconds.
It's a valid certificate in the cryptographic sense — it just vouches for itself, and self-vouching is exactly what the trust store exists to reject.
Firefox names this one specifically: .
A private or internal CA the public doesn't ship.
A company runs its own certificate authority (Active Directory Certificate Services, a HashiCorp Vault PKI, an internal ) and issues certificates from it.
On a managed corporate laptop, that CA's root is pushed into the trust store, so everything works — and it looks like a solved problem.
Then someone hits the same host from an unmanaged device, a personal phone, or a CI runner that doesn't have the root, and the certificate is because that client never received the internal root.
The certificate didn't change; the audience did.
A TLS-inspecting proxy or antivirus re-signing traffic.
Corporate middleboxes (Zscaler, a Palo Alto firewall) and some antivirus products terminate TLS, inspect it, and re-sign it with their own CA on the way to you.
If that CA's root is installed on the machine — normal for a managed device — it's invisible.
If it isn't (a container, a VM, a colleague's BYOD laptop), every HTTPS site suddenly shows , which is the tell: it's not one site's certificate that's broken, it's all of them, because something in the path is re-issuing everything from an untrusted root.
A chain that leads to the wrong root, or a genuinely untrusted one.
The chain is structurally perfect — intermediates present, hostname covered, nothing self-signed at the leaf — and it still terminates at a root th