Certificate & CSR Decoder

How Certificate & CSR Decoder works

An X.509 certificate is a signed statement binding a public key to a set of names. Underneath the familiar `-----BEGIN CERTIFICATE-----` wrapper is base64, and underneath that is DER: a binary encoding where every value is a tag byte saying what it is, a length, and that many bytes of content, nested to whatever depth the structure needs. Nothing in the format is self-describing in a human sense — the tree is just integers, strings and object identifiers, and knowing that the third element of a particular sequence is the serial number comes entirely from the specification, not from the bytes.

That structure is why a certificate can be read offline. Decoding walks the tag-length-value tree and maps it onto the fields RFC 5280 defines: version, serial number, the algorithm the issuer signed with, the issuer and subject as sequences of relative distinguished names, a validity window with two timestamps, and the subject public key with its own algorithm and parameters. Then come the extensions, which is where almost everything that matters in practice lives — the subject alternative names that browsers actually match against, basic constraints saying whether this certificate may sign others, key usage and extended key usage limiting what the key may do, and pointers to revocation and issuer-information endpoints.

The names are the part most often misread. The Common Name in the subject looks authoritative and has not been used for hostname matching by any current browser for years; the Subject Alternative Name extension is what is checked, and a certificate whose CN says one thing while its SAN list says another will be rejected for the hostnames only the CN mentions. Timestamps have their own quirk: certificates use UTCTime with a two-digit year up to 2049 and GeneralizedTime after that, and the two-digit form pivots at 50, so a year of 49 means 2049 and 50 means 1950.

What a browser tool fundamentally cannot do is tell you a certificate is valid. Validity is a property of a chain, not of a document: it requires the issuer’s certificate, then that issuer’s issuer, up to a root that the verifying system already trusts, plus signature verification at every link and a revocation check at each step. A web page has no access to any operating system or browser trust store, so it can describe what a certificate claims, compute its fingerprints, and tell you whether the dates have passed — but it cannot vouch for it, and any tool that implies otherwise is making a claim it has no basis for.

How to use this decoder

1. 1

   Paste the PEM block, or drop the file in

   The BEGIN and END lines can stay. A DER file that is not text at all can be dropped instead, and a certificate request from `openssl req` is read the same way as a certificate.

2. 2

   Paste the whole chain if you have one

   Several concatenated blocks are decoded in order, one panel each, which is the quickest way to see whether the intermediate someone handed you actually issued the leaf sitting above it.

3. 3

   Check the names before anything else

   The subject alternative names are what a client matches a hostname against. A missing entry there is the cause of most certificate errors that look inexplicable given a correct-looking Common Name.

4. 4

   Read the validity window

   Both timestamps are shown along with how long is left. A certificate that is not valid yet fails exactly as loudly as an expired one, which catches people who generate ahead of a deployment on a machine with a skewed clock.

5. 5

   Compare a fingerprint when you need identity, not description

   The SHA-256 digest over the DER is the value to match against what a server presents or what a pinning configuration expects. It is shown in the colon-separated form OpenSSL and browser certificate viewers print.

Worked examples

Frequently asked questions