Certificate Decoder & Chain Checker

It means the chain your server sent stops before it reaches anything the client trusts — almost always because an intermediate certificate is missing. A client walks upward from the leaf: leaf → intermediate → root. It only has roots in its trust store, so if the intermediate that links the two is absent, the walk dead-ends and OpenSSL reports error 20 with that message. Paste your chain here and the missing intermediate is named by its exact distinguished name, which is the string you need to find the right file to append.

Because browsers repair incomplete chains and command-line clients do not. When an intermediate is missing, Chrome, Edge and Safari can fetch it from the URL in the certificate's authorityInfoAccess extension, or reuse one they cached from a different site — so the padlock appears and the problem stays invisible. curl, openssl s_client, Go's crypto/tls, Python's requests and most language runtimes do none of that: they use exactly the certificates you sent them and fail. That asymmetry is why "it works in my browser" is not evidence, and it is the single most common cause of a deploy that passes a manual check and breaks a webhook.

No — and it does no harm either. A client trusts a root because that root is already in its own trust store; a copy sent over the wire proves nothing, because an attacker could send any root they liked. So including it only adds around 1–2 KB to every single handshake. What you must include is the leaf first, then every intermediate above it. This tool labels each certificate by role and tells you which of the two situations you are in: a root that is merely redundant, or an intermediate that is genuinely missing.

The leaf is the certificate for your hostname: it carries the subjectAltName list, it has CA:FALSE in its basicConstraints, and it is what the server presents. An intermediate is a CA certificate that signs leaves on a root's behalf; it has CA:TRUE, usually with pathlen:0 to stop it delegating further. A root is a CA certificate that signed itself — its subject and issuer are identical — and it is trusted only because it ships inside operating systems and browsers. CAs keep roots offline and sign through intermediates precisely so that a compromised signing key can be replaced without reissuing the root.

Deliberately not, and that is the honest answer rather than a limitation to work around. "Trusted" is a property of the client, not of the certificate: Chrome, Firefox, macOS, Windows and your Java runtime all carry different root lists, and roots get distrusted between releases. Shipping a copy of one trust store into this page would let it print a confident "trusted" for a root that was removed from Chrome last month — exactly the class of confidently-wrong answer this tool exists to catch. What it does instead is checkable arithmetic: the chain is internally consistent, each signature verified against the key above it, and the fingerprints are there for you to compare against what a CA publishes.

A wildcard replaces exactly one label, and only the leftmost one (RFC 6125 §6.4.3). So *.example.com matches api.example.com and www.example.com; it does not match a.b.example.com, because that needs two labels, and it does not match bare example.com, because there is no label to replace — which is why certificates normally list the apex as a second SAN. A wildcard is also never honoured in the top two labels (*.com is meaningless) and never inside a label (w*.example.com is not a valid pattern to match against). The hostname field on this page applies each of those rules and tells you which one decided the verdict.

A certificate is public by design: it is sent in cleartext at the start of every TLS handshake, and for any publicly trusted certificate it is already published in Certificate Transparency logs. So there is nothing to protect. A private key is the opposite, and this page still handles it safely: the whole tool is a static page with no server behind it, so if you paste a PRIVATE KEY block it is recognised by its label, never parsed, and never sent anywhere — the page tells you so explicitly. That is not something most certificate decoders can say, because most of them post your input to a backend. If you did paste a key into one of those, rotate it.

Because those are two completely different answers and merging them would be a lie. "Failed" means the issuer's public key was applied to the signature and it did not match — the certificate was altered, or that is not the issuer. "Not checked" means the check could not be performed at all, and the reason is always named: RSASSA-PSS carries its hash, salt length and mask function inside its parameters and this tool declines to guess them; SHA-224, MD5 and DSA are not implemented by Web Crypto; Ed25519 needs Chrome 137 or Safari 17. A boolean would print "not verified" for all of those and let you read it as "forged". Every chain link here is one of three states, never two.

Because browsers stopped reading commonName in 2017. Chrome 58 and Firefox 48 removed the fallback, and every current client requires the hostname to appear in the subjectAltName extension instead — a certificate with a perfect CN and no SAN matches nothing at all and produces NET::ERR_CERT_COMMON_NAME_INVALID. It is still legal to put the name in the CN as well, and most CAs do, but it is decoration. This tool shows the SAN list separately from the subject for exactly that reason, and warns when a certificate has no SAN at all.