Certificate Trust Lab

Certificate SHA-256 Fingerprint Checker

Paste a certificate and this tool prints its SHA-256 fingerprint, computed in your browser from the certificate’s DER bytes. That is the same value openssl x509 -fingerprint -sha256 produces and the same value Chrome and Firefox show in their certificate viewer, so you can compare a certificate you were handed against a fingerprint someone published without installing anything or uploading the file.

It handles the messy real-world case too: a .pem file that turns out to contain four objects, a bundle where nobody is sure which block is the leaf, or a blob of base64 with no header at all. Every object in the input is inventoried separately with its own byte count and its own SHA-256, and the leaf certificate is parsed so you can see what you are actually fingerprinting.

Fingerprint, Thumbprint, and Hash — the Same Thing, Different Names

The terminology causes more confusion than the cryptography does. A certificate fingerprint is simply a hash of the certificate’s complete DER encoding. It is not a field inside the certificate, it is not the serial number, and it is not derived from the public key alone. Different tools present the same number differently:

Two practical consequences. First, a Windows “thumbprint” that does not match a SHA-256 fingerprint is not a mismatch — it is a SHA-1 value of the same certificate. Second, an HPKP or Android network-security-config pin is a hash of the SubjectPublicKeyInfo, not of the certificate, so it deliberately survives certificate renewal. Comparing a pin against a certificate fingerprint will never match, and that is correct behaviour rather than a bug.

Comparison is case-insensitive and separator-insensitive in meaning but not in text. Strip colons and lowercase both sides before you diff them, or you will chase a difference that is not there.

Producing the Same Fingerprint on the Command Line

Every one of these produces the identical digest for the same certificate, because every one of them hashes the same DER bytes:

• openssl x509 -in cert.pem -noout -fingerprint -sha256
• openssl x509 -in cert.pem -outform der | openssl dgst -sha256
• openssl x509 -in cert.der -inform der -noout -fingerprint -sha256
• Fetching a live endpoint first: openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -fingerprint -sha256
• PowerShell, for the SHA-1 thumbprint: (New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 'cert.cer').Thumbprint

Note the trap in the second form: piping a PEM file into openssl dgst without the -outform der conversion hashes the base64 text plus its header lines, which is not the fingerprint and will not match anything. The conversion is what makes the numbers agree.

Inventorying a PEM Bundle

PEM is a container format, so one file can hold any number of objects, and files arrive misnamed constantly. The inventory scans the input for complete -----BEGIN label----- / -----END label----- pairs and lists every one it finds, in order, with:

• The PEM label — CERTIFICATE, CERTIFICATE REQUEST, PUBLIC KEY, PRIVATE KEY, EC PRIVATE KEY, and so on. This is how you tell a leaf from a CSR from a key without opening each one.
• Byte length of the decoded DER, which is the quickest way to spot a truncated block.
• SHA-256 of that object’s DER bytes. For a CERTIFICATE block this is the certificate fingerprint. For any other label it is a digest of that object, which is useful for confirming two files carry identical material but is not a certificate fingerprint.
• Export buttons to save that single object as DER or re-wrap it as PEM — the practical way to pull one certificate out of a bundle.

If the input contains no PEM header at all, the whole thing is treated as base64 DER and decoded as a certificate. That covers the common case of a certificate pasted out of a JSON field, a Kubernetes secret, or a configuration file with the armour stripped.

Bounds are enforced so a pasted mistake cannot hang the page: 1 MiB of total input, at most 32 PEM blocks in one pass, and 512 KiB per block. A file you open from disk is also capped at 1 MiB and is read locally — the file picker never uploads.

What the Parsed Certificate Summary Shows

When at least one CERTIFICATE block is present, its X.509 structure is decoded and summarised: subject and issuer distinguished names, serial number, the notBefore and notAfter validity window in ISO form, days remaining, signature algorithm, public key algorithm and key size, all subject alternative names (DNS, IP, email, and URI entries together), and whether subject and issuer match, which indicates a self-signed certificate.

Alongside the summary the tool raises findings without contacting anything:

Structure Is Not Trust

This is the limit worth stating plainly, because it is where certificate work goes wrong. Everything above is read out of the bytes you supplied. A fingerprint proves that two people are looking at the same certificate; it proves nothing about whether that certificate should be trusted. Chain construction to a trusted root, revocation status, name matching against the host you actually connected to, and policy constraints are all separate questions that need either an anchor set or a live endpoint.

Those questions have their own tools, and a saved workspace carries across to them: the certificate chain builder for leaf-to-root assembly, the OCSP and CRL checker for an explicit revocation lookup, certificate transparency search for what has been publicly issued for a domain, and the SSL checker for what a live server actually serves.

Private Keys Are Never Saved

Raw input stays in page memory and is deliberately excluded from any saved workspace record. If you paste something whose PEM label contains PRIVATE KEY, the tool inventories and fingerprints it, warns you at high severity, and still writes none of those bytes to storage. The general advice stands regardless: do not paste production private keys into tools you do not need to paste them into.

What a saved workspace does hold is the derived material — object labels, byte counts, fingerprints, the parsed certificate summary, findings, and your own notes and tags. It lives in this browser’s local storage, expires after 30 days, and is capped at 24 workspaces of 128 KiB each. Nothing is transmitted, and clearing site data removes it permanently.

How to Check a Certificate Fingerprint

1. Paste the certificate into the input box, or use Open file to load a .pem, .crt, .cer, .der, .csr, or .key file from disk. DER files are converted to PEM for display automatically.
2. Select Inspect locally. Nothing leaves the browser at any point.
3. Read the material inventory. Each object gets its own row with label, size, and SHA-256. In a bundle, the CERTIFICATE row you care about is usually the first.
4. Compare fingerprints as text. Remove colons and lowercase the published value before diffing it against the value shown here.
5. Check the parsed summary to confirm the subject, SANs, and validity window match the certificate you expected to be looking at.
6. Export a single object as DER or PEM if you need to split one certificate out of a bundle.
7. Save the workspace to keep the fingerprints and findings, then hand off to a chain, revocation, or endpoint check.

Frequently Asked Questions

Why does my fingerprint not match the one the vendor published?

Check three things in order. Are you comparing the same algorithm — a Windows thumbprint is SHA-1, not SHA-256. Are you comparing the same formatting — strip colons and case before diffing. And are you comparing the same certificate — in a bundle it is easy to fingerprint the intermediate instead of the leaf. If all three match and the values still differ, the certificates genuinely differ.

Does converting between PEM and DER change the fingerprint?

No. PEM is base64-encoded DER wrapped in header lines, so both encodings carry identical bytes underneath and the fingerprint is computed from those bytes. Converting formats, re-wrapping a bundle, or changing line endings leaves the fingerprint unchanged. Re-issuing or renewing the certificate changes it completely.

Is my certificate or key uploaded anywhere?

No. Parsing, hashing, and conversion all run in your browser using the Web Crypto API, and no request is made. Raw input is additionally excluded from saved workspaces, so private key bytes are never written to storage even locally.

Can I fingerprint a certificate signing request or a public key?

Yes, and the tool will show a SHA-256 for any PEM object you give it. Be clear about what the number means: it is a digest of that object’s DER encoding, which is fine for proving two copies are identical, but only the digest of a CERTIFICATE block is what anyone means by a certificate fingerprint.

How many certificates can one PEM file contain?

As many as you like — a typical server bundle holds the leaf plus one or two intermediates, and a CA bundle holds hundreds. This tool inspects up to 32 objects in a single pass, which covers a server bundle comfortably. For very large trust stores, split the file first.

What is the difference between a certificate fingerprint and a certificate pin?

A fingerprint hashes the whole certificate, so it changes on every renewal. A pin normally hashes the SubjectPublicKeyInfo, so it survives renewal as long as the key is reused. They are different values by design and will never be equal.

The tool says “No X.509 certificate block found” — what now?

It means nothing in the input carried the CERTIFICATE label, so there are no certificate fields to summarise. That is normal for a file that holds only a key or only a CSR. The inventory, fingerprints, and format conversion all still work; only the parsed summary is unavailable.

Do I need an account?

No. This and the rest of our security tools are free and need no signup. To decode a certificate’s full field and extension set, use the X.509 decoder; to generate a CSR or convert between PEM, DER, PFX, and P7B, use the CSR generator and format converter.