Certificate Decoder

X.509 packs a lot of structured data into a Base64 blob, and most of the interesting parts are nested inside extensions. This decoder reads the DER itself rather than leaning on a library's summary, and every field it prints is compared against `openssl x509 -text` in the project's test suite: 472 assertions across thirteen certificates covering RSA, ECDSA P-256 and P-384, Ed25519 and RSASSA-PSS, a v1 certificate with no extensions at all, a certificate with two organizational units, one with a non-ASCII subject, one whose serial carries a DER pad byte, and one with a critical extension nothing here recognises.

The distinguished names keep every attribute in the order the certificate stores them, including repeated ones: a subject with two OU values shows both, and a multi-valued RDN is marked as such. Values are decoded according to the string type their tag names, so a UTF8String holding a German organisation name reads as "Münchener Straßenbahn GmbH" rather than as mojibake. The RFC 4514 one-line form is shown underneath and can be copied.

The serial is shown the way OpenSSL shows it, as the integer. DER stores a positive integer whose top bit is set with a leading zero byte, and that byte is not part of the serial; where the two differ, the DER bytes are shown underneath with a note, because comparing a serial against what a CA displays is a common reason to open this tool.

Extensions are decoded, not dumped. Basic constraints give CA and path length. Key usage is the nine named bits of RFC 5280 section 4.2.1.3, not a bit string in hex. Extended key usage names each purpose and gives its OID. Subject Alternative Name handles all nine GeneralName kinds: DNS, IP (v4 and v6, printed uncompressed the way OpenSSL prints it with the readable compressed form beside it), email, URI, directory name, registered ID and otherName. Authority and subject key identifiers, CRL distribution points, authority information access with its OCSP and CA Issuers URLs, certificate policies with their CPS links, name constraints, the TLS feature extension used for OCSP must-staple, and a count of embedded certificate transparency timestamps are all read. Anything else is shown with its OID and its raw value, and if it is marked critical the page says so out loud, because RFC 5280 section 4.2 requires software that does not understand a critical extension to reject the certificate.

Three things are checked rather than just displayed. Host name matching follows RFC 6125 as browsers apply it and as `openssl x509 -checkhost` implements it: a wildcard is the whole leftmost label, covers exactly one label, and never matches the bare domain, and a certificate carrying any dNSName in its SAN is never checked against its Common Name. Signature verification uses the Web Crypto API to confirm that a certificate was really signed by the key in the certificate above it, covering RSA PKCS#1 v1.5, RSASSA-PSS, ECDSA on P-256, P-384 and P-521, and Ed25519; a fullchain.pem is linked up by name and key identifier and each link is confirmed by the signature, so a chain pasted out of order still resolves. Fingerprints are SHA-256 and SHA-1 over the certificate plus the base64 SHA-256 of the public key, which is the pin-sha256 value.

What this tool does not do: it has no network access, so it cannot fetch a certificate from a host, check revocation, or tell you whether a root is in any trust store. "Within its validity period" is a statement about dates and nothing more.