SSL certificate decoder

What a certificate decoder shows you

An SSL certificate is a DER-encoded X.509 structure, usually wrapped in the base64 armour that makes a PEM file. Inside it are the subject and issuer names, a serial number, the two dates the certificate is valid between, a public key, and a list of extensions — of which the important one for a website is the subject alternative name, since browsers stopped accepting a common name as a hostname years ago.

Decoding all of that needs no server. It is a byte-level parse of one narrow profile of one encoding, which is why this page does it in the tab you already have open rather than asking you to upload anything. That matters less for a public server certificate than for a private key, but the habit of pasting cryptographic material into someone else's form is not one worth having, and this site takes the same position on the JWT decoder.

What most decoders will not tell you is whether the certificate actually follows the rules. RFC 5280 is quite specific about several things that are easy to check and easy to get wrong, and real certificates in your own trust store break them.

How to use it

1. Paste the certificate. A full PEM block, just the base64 between the armour lines, or raw hex. All three work, and whitespace is ignored.
2. Read the fields. Names, serial, validity, key and extensions. The two dates also show which ASN.1 time type encodes them, which is the part that turns out to matter.
3. Check the conformance list. Anything the certificate does that RFC 5280 forbids or discourages is spelled out, with the reason. A conforming certificate says so.

The rule almost nobody checks, and the roots that break it

RFC 5280 section 4.1.2.5 is unusual. It does not merely permit two ways of writing a date, it mandates which one by year: dates through 2049 must be UTCTime, and dates in 2050 or later must be GeneralizedTime. The reason is that UTCTime carries a two-digit year, with 00 to 49 read as 20xx and 50 to 99 as 19xx, so the encoding simply cannot express 2050.

That gives the rule a strange shape. One half of it is enforced by the encoding and cannot be broken — no certificate can put 2050 in a UTCTime, because there is nowhere to put it. The other half is not enforced by anything, and it is broken. Of the 150 root certificates in a stock trust store, 149 encode their dates as UTCTime and one uses GeneralizedTime while expiring in 2046, four years before the switch is permitted. Certum Trusted Network CA 2 is in the default trust store of essentially every browser and operating system, and you can load it into the box above and see the finding.

The same store turns up a second violation more often. Section 4.1.2.2 says a certificate's serial number must be a positive integer. Eight of the 150 roots have a serial number of zero, among them two Go Daddy roots and two from the Hellenic Academic and Research Institutions authority. Zero is not positive, and OpenSSL will print serial=00 for all of them if you would rather check with something other than this page.

Neither of these makes a certificate dangerous. They are the sort of thing that was permitted by whatever built the certificate a decade or more ago and has been quietly grandfathered ever since. They are worth showing because a decoder that reports only the fields is telling you what the certificate says, not whether it is well formed.

Honest limits, and how this was checked

This reads a certificate. It does not verify one. There is no signature check, no chain building, no revocation lookup and no trust decision, because all of those need the issuer's certificate and a current revocation source, and a page cannot honestly pretend to have either. If the tool says a certificate is self-signed, that is a statement about two names being equal, not about whether the signature holds.

It also decodes only the extensions worth summarising, and shows the rest as their object identifier and raw bytes. Certificate policies and signed certificate timestamps are structures in their own right, and half-decoding them would be worse than showing them plainly.

The parser is checked against OpenSSL over all 150 root certificates in a real trust store: every serial number, every version, both validity instants and every subject attribute agree, with 326 assertions and 15 negative controls. Three disagreements surfaced during that work and all three were mistakes in the comparison rather than in the parser, including one that only appeared because OpenSSL escapes non-ASCII text in its output while the parser decodes it. The fixtures the trust store cannot supply — a serial over twenty octets, a certificate that is not self-signed, a name in a BMPString — are built from scratch in the test suite, because a rule that nothing in the corpus violates is not actually being tested.

Why is it free?

There is no server involved. Parsing DER is arithmetic on bytes, it runs in your browser, and there is nothing to bill for or sign up to.

Nothing you paste is uploaded, stored or logged. A public certificate is not a secret, but the box above will happily accept things that are, and the only safe design is one where it cannot matter.