Generate fingerprints for the public key in an SSL certificate
Key Type
Key Size
Subject
Public Key Fingerprints
About Key Fingerprints
A public key fingerprint is a cryptographic hash that uniquely identifies a public key without revealing the key itself. Fingerprints are used for key validation, SSH host verification, and certificate pinning. Our Key Fingerprint Tool extracts the public key from an SSL/TLS certificate and generates fingerprints using MD5, SHA-1, SHA-256, SHA-384, and SHA-512 algorithms, making it easy to verify and compare keys across different formats and systems.
How to Use
Enter the domain name whose certificate public key fingerprint you want to generate.
Click Generate to fetch the certificate and compute fingerprints.
Review the key type, key size, and subject information.
Copy individual fingerprints using the Copy button next to each hash.
Use Cases
Certificate Pinning: Generate SHA-256 fingerprints for use in HTTP Public Key Pinning (HPKP) configurations.
Key Verification: Compare fingerprints across servers to confirm they share the same public key.
Security Audits: Track key fingerprints over time to detect unauthorized certificate or key changes.
SSH Key Management: Generate and compare fingerprints for SSH host key verification and management.
Frequently Asked Questions
Key fingerprints are used to uniquely identify public keys without sharing the full key data. They are commonly used in certificate pinning to prevent man-in-the-middle attacks, SSH host key verification, and ensuring key consistency across load-balanced servers.
SHA-256 is the most widely recommended fingerprint algorithm due to its strong security properties and broad compatibility. SHA-1 is still commonly used but is being phased out due to collision attacks. MD5 should only be used for legacy compatibility.
A certificate fingerprint hashes the entire certificate including metadata, while a key fingerprint hashes only the public key. Key fingerprints remain the same across certificate renewals if the same key pair is reused, making them more stable for long-term identification.
The key, almost always. Pinning a whole certificate means any renewal breaks every client until you update the pin, which is a recurring operational cost and a recurring outage risk. Pinning the public key survives reissuance, because the same key can sign a new certificate. If you must pin certificates, pin an intermediate and carry a backup pin, so you can rotate without coordinating clients.
For most sites, no. Pinning defends against a compromise of the CA infrastructure itself, which is rare, and the certificate trust model already covers the far more common case of a key exposed on your own server. What it costs is real — you lose the ability to rotate certificates on your own schedule, and a mistake takes your site down completely. Strong keys, HSTS and prompt rotation handle the realistic threats without that fragility.
At least two, and they must come from different sources. A primary pin plus a backup you hold in reserve lets you rotate without downtime, which is the whole point of having a backup. Two pins from the same issuer protect nothing extra, since compromising that issuer defeats both. Generate the backup key and store it safely — an unrecoverable backup is the same as no backup.
Every connection to that host, at once, for clients honouring the pin. There is no graceful degradation, which is why an expiring pin is an incident with a hard deadline rather than a warning. The certificate checker on this site reports expiry dates, and the expiry calendar export can put them into your calendar with advance reminders — that is the operational half of pinning that people underestimate.
It complicates them considerably. Each hostname that terminates TLS and presents a certificate needs to satisfy the same pin, and a CDN fronting many domains changes which certificate is actually served. Pinning the CDN's certificate couples you to their infrastructure and their rotation schedule. This is one of the strongest practical arguments against pinning for most public sites.
How the Fingerprint Is Produced
Public key pinning can use either a whole certificate or just its public key. This page produces the key-level form, which survives reissuance and is the more useful of the two.
1Retrieve the certificate and extract its public key in the standard subject-public-key-info encoding, so the bytes hashed are the canonical form rather than a rendering of it.
2Hash the key bytes and format the result colon-separated for reading aloud. The subject and issuer are reported alongside so you can confirm which certificate the key came from.
3Explain the distinction that matters. A certificate hash changes at every renewal, so pinning one breaks the next time the certificate is replaced. The key hash does not, which is why pinning is normally done at the key level or against an intermediate.
Pinning remains a decision with real costs: it removes your ability to change certificates freely and will break connections if a pin expires without a backup. Most sites are better served by relying on the CA trust model plus HSTS.
Tips & Best Practices
•Calculate key fingerprints for certificate pinning and verification
•Use fingerprints to verify key authenticity during deployment
•Store fingerprints securely for later comparison
•Compare fingerprints across multiple sources for tamper detection
Technical Details
Calculation: Public key fingerprint computation Algorithms: SHA-256 and SHA-1 fingerprint calculation Format: Hex-encoded fingerprint strings Output: Key fingerprint for pinning and verification
