piapia123
en

Certificate Reader

Encoding

Everything runs locally in your browser — nothing is uploaded

Input
Drop a file here to load its contents
Output

Paste the contents of a `.crt` or `.pem` and get the version, serial number, subject, issuer, validity, public key, SAN, key usage, signature algorithm and SHA-256 / SHA-1 fingerprints. PEM, bare base64 and hex all work. ⚠️ It reads; it does not verify. This is the thing to know before using it: whether a certificate *parses* and whether it can be *trusted* are entirely different questions, and a pane that lists the fields beautifully makes it easy to assume the second one is covered. Chain validation means: obtaining the issuer’s certificate, walking up to a trusted root, checking at each step that basic constraints and key usage permit the signing, checking revocation (CRL or OCSP, both needing the network), and matching the hostname against the SAN. Browsers do that only during the TLS handshake, using their own root store — a web page cannot do it at all. So what follows is the facts: what the certificate says. Whether to trust it is a separate judgement. ⚠️ The one check performed is the self-signed test — comparing subject with issuer. Different is not a problem: nearly every certificate is signed by somebody else, and that is the normal case. ⚠️ Expired and not-yet-valid are always reported, whatever the options say — that is the single most important thing about a certificate. Everything runs in your browser.

Features

  • ⚠️ The “reads, does not verify” note sits at the top of the result, not buried in the FAQ
  • Version, serial number (given as a string — it can exceed 2⁵³), signature algorithm
  • Every attribute of the subject and issuer (CN, O, OU, C, ST, L, emailAddress and more)
  • Validity and days remaining; ⚠️ expired or not-yet-valid is called out plainly
  • A three-level verdict banner at the top of the result — valid (with days remaining), expired, or not yet valid — so the answer is the first thing you see
  • Public key algorithm and size (RSA computed from the modulus, EC from the curve), plus the curve name
  • SAN listed entry by entry, with DNS, IP, email and URI distinguished; ⚠️ an IP is rendered as four octets rather than decoded as text
  • Key usage and extended key usage, explained bit by bit
  • Basic constraints: whether it is a CA certificate, and any pathLenConstraint
  • SHA-256 and SHA-1 fingerprints, hex with colons
  • PEM, bare base64 and hex inputs all accepted
  • ⚠️ Binary certificate files such as `.cer` and `.der` can be dropped straight in — the shell converts them to hex before parsing, which matters because those files are DER-encoded binary and cannot be pasted
  • Runs entirely in your browser; the certificate is never uploaded

How to use

  1. Paste the whole certificate (the `-----BEGIN CERTIFICATE-----` block)
  2. The result is grouped: summary → subject → issuer → validity → key → SAN → usage → signature → fingerprints
  3. Read the “reads, does not verify” note at the top first, then check the fields

FAQ

Does this verify that the certificate is trustworthy?
No, and it cannot. Chain validation means obtaining the issuer’s certificate, walking up to a trusted root, checking at each step that basic constraints and key usage permit the signing, checking revocation (CRL or OCSP, both requiring the network), and matching the hostname against the SAN. Browsers do that only during the TLS handshake, using their own root store — a web page has neither that store nor a revocation list. So this gives you what the certificate says; whether to trust it takes another means. The same goes for the self-signed certificate generator elsewhere on this site: nothing trusts what it produces.
Does “self-signed: No” mean something is wrong?
No. Nearly every certificate is signed by somebody else — a CA — so “No” is the entirely normal answer. The check simply compares subject with issuer: identical means it signed itself (a self-signed certificate, common for local development and internal testing), different means there is a layer above. It has no bearing on trustworthiness: a self-signed certificate may be one you installed in your own root store, and a CA-signed one may be expired or issued for a different hostname.
Why let me read an expired certificate at all?
Because “what this certificate says” and “whether it still works” are separate questions, and the first has uses beyond the second: finding out who issued it, which names it covered, checking a fingerprint, or confirming that an old certificate is the one from back then. Parsing does not stop being meaningful when it expires. The result does state how many days ago it expired, though — that is the most important thing about it, and nobody should have to subtract two dates to find it.
What are the fingerprints for?
A fingerprint is a hash of the whole certificate, used to check whether this is the same certificate — whether the one on a server matches the copy you have locally, or whether a downloaded one has been altered. SHA-256 is the one in use (`openssl x509 -fingerprint -sha256`); SHA-1 is shown because a lot of older documentation and admin panels still print it, but SHA-1 should not be used for any security decision any more.
Why does my certificate have no SAN?
It is probably a very old one. Chrome has ignored CN entirely since version 58 and matches on subjectAltName alone, so every certificate issued now carries a SAN (even for a single hostname, with the CN repeated inside). A CN-only certificate cannot connect in a modern browser, and the error only says “name mismatch”, which points people at the wrong problem. If you issued it yourself, issue a new one with a SAN.

Related tools