rea-reverse

X.509 certificate decoder

Paste a PEM certificate or a whole chain, or drop a DER, CRT, CER or P7B file, to see every field and extension, the SHA-1 and SHA-256 fingerprints, whether the chain is in order and whether each certificate is valid today.

Your certificates never leave your browser. Decoding runs locally in a Web Worker that has no network access. AIA, CRL and OCSP URLs are shown as text and never fetched. How to verify this yourself

Or drop a certificate file

or

PEM (one certificate or a chain), DER, CRT, CER and P7B / PKCS#7 bundles, up to 16 MiB.

What this tool does not do

  • Signatures are not verified and revocation is not checked: the chain check compares issuer and subject names and key identifiers only. Nothing is fetched from the AIA, CRL or OCSP URLs.
  • Private keys and CSRs in the pasted text are skipped without being read.

When a TLS handshake fails, a mobile app rejects a pinned certificate, or a CA sends you a bundle, the first question is usually “what is actually in this certificate?”. openssl x509 -noout -text answers it, but you have to have OpenSSL at hand, save the text to a file, and run it once per certificate in a chain. Pasting a certificate into a random website is the other option, and it is a poor habit even for public certificates when the same box later receives a private key.

This decoder runs entirely in your browser. Paste PEM text (one certificate or a whole chain) or drop a file.

What it reads

  • PEM: any number of -----BEGIN CERTIFICATE----- blocks, TRUSTED CERTIFICATE (OpenSSL’s variant with trust settings), and PKCS7 blocks. Text around the blocks is ignored, so you can paste a whole log excerpt or the output of openssl s_client -showcerts. Private keys and CSRs in the same text are skipped without being read. Base64 without the header lines also works.
  • Files: DER (.der, .cer, .crt), PEM files and PKCS#7 / CMS bundles (.p7b, .p7c). Keystores and APKs are accepted too, but the signing certificate fingerprint viewer is built for those.

What you see for each certificate

  • Subject and issuer in RFC 4514 form (CN=example.test,O=REA Fixtures\, Test,C=CN), the serial number, the version, the signature algorithm, and the public key (RSA modulus size, EC curve such as P-256 or P-384, Ed25519).
  • Validity with a status for today: valid with the number of days left, expired, or not yet valid.
  • Fingerprints: SHA-1, SHA-256 and MD5 of the DER encoding, as colon hex, plain hex and Base64, plus the Base64 SHA-256 of the public key (the HPKP / Android network security config pin).
  • Every extension in the order the certificate stores them, critical ones marked, decoded into text lines that use the RFC 5280 names:
    • subject alternative names (DNS, IP v4 and v6, email, URI, directory names, other names);
    • key usage, extended key usage (serverAuth, clientAuth, codeSigning, …), basic constraints with the path length;
    • subject and authority key identifiers;
    • authority information access (OCSP and CA Issuers URLs) and CRL distribution points, shown as text and never fetched;
    • certificate policies with CA/Browser Forum names (DV, OV, EV) and CPS URLs, name constraints, TLS feature (OCSP Must-Staple);
    • the embedded Certificate Transparency SCT list: the number of SCTs, and each SCT’s log ID and timestamp.
    • Anything else is shown with its OID and the value in hex.

Chain order check

When there is more than one certificate, the page checks each link: is certificate n+1 the issuer of certificate n? It compares the issuer name with the next subject byte for byte, and the authority key identifier with the next subject key identifier when both exist. A server should send its leaf first, then each intermediate; a common deployment mistake is a bundle in the wrong order, or with the root first, and the check flags that. It also says whether the chain ends with a self-issued root, which servers normally leave out.

This is a structural check. Signatures are not verified, and revocation (CRL, OCSP) is not looked up, because that would mean contacting the CA from your browser.

How we checked it

The test certificates were made with OpenSSL 4.0.3: an EC P-256 root, an EC P-384 intermediate with pathlen:0, and an RSA 2048 leaf with two DNS names, an IPv4 and an IPv6 address, an email and a URI in the SAN, both TLS EKUs, AIA, a CRL distribution point, a DV policy and two SCTs, plus an expired certificate from 2000. The unit tests compare fingerprints, names, dates, key sizes, critical flags and each of those extensions with openssl x509 -text -fingerprint. OpenSSL prints IPv6 SANs uncompressed (2001:DB8:0:0:0:0:0:1); this page writes them in the RFC 5952 short form (2001:db8::1).

How your data stays private

  • Decoding runs in a Web Worker on your device. Nothing you paste or drop is uploaded.
  • Values from the certificate are shown as plain text. URLs inside it are not turned into links and are never requested.
  • Analytics events contain only coarse values: success or an error code, the detected format, a count bucket, a size bucket and a duration bucket. No names, URLs or fingerprints. The full list is on the privacy page.
  • The tool page shows no ads.

How to verify this yourself

  1. Open the Network tab of your browser’s developer tools, then paste a chain and decode it. The only requests are page assets and the worker script /_astro/cert-worker-*.js.
  2. Or load the page, go offline, and decode. It still works.
  3. The worker runs under the Content Security Policy default-src 'none'; script-src 'self'; connect-src 'none'.
  4. Compare with openssl x509 -in cert.pem -noout -text -fingerprint -sha256.

Limitations

  • No signature verification, no revocation check, no trust-store lookup: “in order” does not mean “trusted”.
  • Encodings: DER, and BER with indefinite lengths (as in PKCS#7 / CMS files written by openssl cms -stream). Fingerprints are computed over the bytes as stored.
  • Rare extensions (policy mappings, policy constraints, subject directory attributes, qualified statements) are shown as hex.
  • Certificate requests (CSR), CRLs and OCSP responses are not decoded.