Certificate Decoder

What is inside a certificate

An X.509 certificate is a signed statement with three parts: what the certificate says (tbsCertificate — subject, issuer, validity, public key, extensions), which algorithm signed it, and the signature itself. The whole thing is DER — a strict binary encoding of ASN.1 — and PEM is just that binary wrapped in base64 with BEGIN and END lines so it survives being pasted into text.

The signature is made by the issuer's private key over the exact bytes of the tbsCertificate. Verification is therefore a two-step process: check that the signature is valid under the issuer's public key, and check that you actually trust that issuer. This tool deliberately does neither — it decodes and displays. Looking at a certificate and trusting it are different things.

The fields worth reading first when something breaks

• Subject Alternative Names. This is the list browsers actually match against. The CN has been ignored for hostname validation for years, so a certificate with a perfect CN but no matching SAN will fail — and the error often says the name is not in the certificate.
• Validity. An expired certificate is the single most common cause of a sudden TLS failure. Check both ends: a not-yet-valid certificate fails just as hard as an expired one.
• Key usage. keyCertSign means the certificate may sign other certificates. If an end-entity certificate has it, that is a finding worth reporting, not a curiosity.
• Basic constraints. CA:FALSE marks an end-entity certificate; CA:TRUE with a path length limits how deep a chain may go under it.
• Authority and subject key identifiers. The AKI of one certificate should equal the SKI of its issuer. When a chain does not build, these are how you find which certificate is actually missing.

Reading the chain, not the certificate

A certificate on its own proves nothing. Trust comes from a path: the leaf is signed by an intermediate, the intermediate by a root, and the root is in your trust store. Debugging “why is this not trusted?” means walking that path and finding where it breaks — a missing intermediate on the server, a root that is not in the store, or a name mismatch on the leaf. The issuer and authority key identifier fields here are what let you line the chain up.

CN versus SAN, briefly

In the early web, a certificate's CN held the hostname. That stopped working because one CN could only name one host and wildcards were inconsistent, so RFC 6125 moved verification to the SAN extension, which can list many names and IP addresses at once. Every certificate issued today must carry the names in SAN. If you see a certificate from the CN era, it is either very old or very broken.

FAQ