Fingerprints, Thumbprints, and Why the Same Certificate Shows Different Ones

You install a certificate, open it in Chrome, and copy the fingerprint into the change ticket. A colleague checks the same server in the Windows certificate store and reports a different value. OpenSSL gives a third, in uppercase with colons. Nobody is wrong. Each tool is hashing something slightly different, or presenting the same hash differently, and none of them say so.

This article explains what a fingerprint is, why it differs from one viewer to the next, what the separate public key fingerprint means, and when a SHA-1 thumbprint is still fine.

What a fingerprint is

A certificate fingerprint is a hash of the certificate's complete DER encoding: the signed body, the signature algorithm, and the issuer's signature. Change one bit anywhere and the fingerprint changes.

Two things follow from that.

It is not stored in the certificate. A long-running Security Stack Exchange thread on the difference between a certificate, a signature, and a thumbprint exists because people assume the thumbprint is a field the CA fills in. It cannot be, because it covers the signature and the signature is produced last. Every viewer computes it from the bytes it has. That is why the Windows dialog lists it under Details with a different icon from the real fields: it is a property Windows calculates, not an X.509 attribute.

Thumbprint and fingerprint are the same thing. Microsoft says thumbprint. Browsers, OpenSSL, keytool, and the RFCs say fingerprint. The only real difference between tools is which hash algorithm sits behind the label.

Why tools disagree

When two values are supposed to match and do not, it is almost always one of these:

A SHA-1 and a SHA-256 fingerprint of the same certificate have nothing in common. They are two different hashes of the same bytes, not a short and long form of one value.

The same certificate in common viewers

The screenshots below are all the same certificate, for example.756315.xyz, issued by a Let's Encrypt staging CA.

Chrome and Edge

Chromium shows a SHA-256 Fingerprints section with two entries, Certificate and Public Key, lowercase without separators. There is no SHA-1 value.

This viewer has changed more than once. A 2023 write-up from a consultancy's IT team noticed that Chrome and Edge had dropped the word "thumbprint" and instead showed a SHA-256 fingerprint and a SHA-1 fingerprint side by side, the SHA-1 being the value older tools called the thumbprint. Current builds have since dropped the SHA-1 line too. A runbook that says "compare the thumbprint with what Chrome shows" was written for a viewer that no longer exists.

The Windows certificate dialog

The Windows dialog, reached from certmgr.msc, certlm.msc, or by double-clicking a .cer file, shows a single Thumbprint on the Details tab. It is SHA-1, 40 lowercase hex characters, no separators.

Older Windows versions also had a Thumbprint algorithm row reading sha1. The row is gone; the algorithm is not. The certificate store, IIS bindings, Group Policy, and the Thumbprint property in PowerShell all still use SHA-1. The last section explains why that is an identifier choice rather than a weakness.

One trap: copying the thumbprint out of this dialog has historically picked up an invisible left-to-right mark at the start of the string. The pasted value looks right and fails to match. Retype the first character if a lookup inexplicably fails.

Firefox

Firefox shows a SHA-256 Fingerprint and a SHA-1 Fingerprint, both of the whole certificate, in uppercase hex with colons. It does not show a public key fingerprint.

OpenSSL

The default digest for -fingerprint is still SHA-1:

$ openssl x509 -in example.pem -noout -fingerprint
SHA1 Fingerprint=1F:C7:74:0E:02:E4:41:C7:13:40:C9:2A:21:C2:E9:87:2B:95:9F:2A

$ openssl x509 -in example.pem -noout -fingerprint -sha256
sha256 Fingerprint=76:9F:70:30:6B:15:A8:CE:47:C1:FC:8A:3F:59:5A:8A:C8:74:62:95:9D:8C:09:66:27:C5:0F:9B:8C:E4:BB:B4

Strip the colons and lowercase both lines and they match the Windows thumbprint and the Chrome certificate fingerprint exactly. OpenSSL always hashes the DER bytes, so PEM and DER copies of the same certificate give the same fingerprint.

Appliance vendors often point to this command because their own interfaces show no fingerprint. F5's knowledge base, for instance, has you locate the certificate file on the BIG-IP filestore and run OpenSSL from the shell, once for SHA-256 and once for SHA-1, rather than reading anything from the configuration utility.

PowerShell and .NET

The Thumbprint property is SHA-1, uppercase, no separators:

PS> Get-ChildItem Cert:\LocalMachine\My | Format-Table Thumbprint, Subject

Thumbprint                               Subject
----------                               -------
1FC7740E02E441C71340C92A21C2E9872B959F2A CN=example.756315.xyz

For SHA-256, ask explicitly:

PS> $cert = Get-Item Cert:\LocalMachine\My\1FC7740E02E441C71340C92A21C2E9872B959F2A
PS> $cert.GetCertHashString([System.Security.Cryptography.HashAlgorithmName]::SHA256)
769F70306B15A8CE47C1FC8A3F595A8AC87462959D8C096627C50F9B8CE4BBB4

Java keytool

keytool -printcert -file example.cer prints SHA1 and SHA256 certificate fingerprints, uppercase with colons. Older JDKs also printed MD5.

Certificate fingerprints versus public key fingerprints

Chrome's Public Key line is a different kind of value. It is the SHA-256 hash of the certificate's SubjectPublicKeyInfo, the DER structure holding the key algorithm and the key itself. Subject, dates, extensions, issuer, and signature are all outside it.

So it behaves differently over time:

• Renew with the same key pair and the certificate fingerprint changes but the public key fingerprint does not.
• Renew with a fresh key pair and both change.
• Cross-signed or re-issued certificates for the same key share a public key fingerprint but have different certificate fingerprints.

Use a public key fingerprint when you care about the key rather than the certificate around it. The retired HTTP Public Key Pinning standard pinned Base64 SHA-256 hashes of the SubjectPublicKeyInfo for exactly this reason, and SSH host key fingerprints are the same idea, which is why they also look like SHA256: followed by Base64.

The Subject Key Identifier extension is related but not the same. RFC 5280 suggests deriving it from a SHA-1 hash of the key, and many CAs do, but it is a value the CA chooses. Do not treat it as a hash you can recompute.

To compute the SPKI hash yourself:

$ openssl x509 -in example.pem -noout -pubkey \
    | openssl pkey -pubin -outform DER \
    | openssl dgst -sha256

Things that look like fingerprints but are not

A serial number is assigned by the CA and is unique only within that CA. It is a field in the certificate, not a hash of it. It is the right value for revocation lookups, where it is always paired with the issuer, and the wrong value for identifying a certificate on its own.

A signature is derived from a hash too, but of the certificate body only, and only the CA can produce it. It proves who issued the certificate. The fingerprint, computed afterwards over everything including the signature, only identifies the exact bytes you are holding.

Is a SHA-1 thumbprint still safe?

It depends on what you use it for.

A 2019 paper by two Microsoft researchers, Are Certificate Thumbprints Unique?, found that thumbprints fail as unique identifiers in two ways.

Collisions. If the hash admits chosen-prefix collisions, an attacker can build two different certificates with the same thumbprint. The paper called this practical for MD5 and imminent for SHA-1; a chosen-prefix SHA-1 collision was published in early 2020. An attacker who gets a benign certificate onto an allowlist by SHA-1 thumbprint could later present a different one with the same thumbprint.

Malleability. This one needs no broken hash. A valid certificate can often be re-encoded, or its ECDSA signature replaced with its mathematically equivalent twin, so that it still validates and carries the same key but has a different fingerprint under every algorithm, SHA-256 included. A blocklist that refuses a known-bad certificate by fingerprint can be bypassed with a mauled copy.

The authors also scanned a large corpus of internet certificates and found no collisions in practice, and judged real attacks to need a very sophisticated adversary. That is context, not a reason to ignore the findings.

In practice:

• Comparing by eye against a value from a trusted source is fine with SHA-1 when the attacker had no hand in producing the certificate. Use SHA-256 anyway when both sides can.
• Looking up a certificate you already hold by SHA-1 thumbprint, as Windows and IIS do, is indexing, not a trust decision. Nothing external can influence it.
• Allowing in software should use SHA-256, prefer the public key fingerprint when the key is what matters, and ideally compare the full DER bytes.
• Denying by fingerprint is weak under any algorithm because of malleability. Deny by issuer and serial, or by public key.

A checklist for mismatches

1. Count the hex characters. Different lengths mean different algorithms, and the values are not expected to match.
2. Check the label. A Public Key fingerprint will never match a certificate fingerprint.
3. Remove colons and spaces and compare in one case.
4. Confirm both sides are looking at the same certificate. A per-hostname certificate or a stale load balancer binding is a more common cause than any hashing subtlety.
5. Watch for invisible characters pasted from the Windows dialog.

If you want both algorithms side by side without a shell, paste the certificate into the certificate decoder. It shows the SHA-256 and SHA-1 certificate fingerprints with the subject, issuer, validity, and extensions. When you record a fingerprint in an inventory or ticket, record the SHA-256 certificate fingerprint and label it as such. It will still match whatever viewer the next person reaches for.

Further reading

• Are Certificate Thumbprints Unique? by Greg Zaverucha and Dan Shumow, IACR Cryptology ePrint Archive, for the collision and malleability analysis.
• RFC 5280, for the certificate structure fingerprints are computed over and the Subject Key Identifier derivations.
• RFC 7469, the original HTTP Public Key Pinning specification, for the Base64 SubjectPublicKeyInfo hash format.
• Your vendor's documentation for how its store or appliance exposes fingerprints. F5 and Microsoft both document the algorithm and format their interfaces use.