Developer tools · SHA hash calculator
Certificate and SSH Fingerprints: How SHA-256 Identifies a Public Key
· Background
sha-256 cryptography security
A fingerprint is a hash of a certificate or key, short enough to read aloud. This post explains how TLS and SSH fingerprints are computed, why SHA-1 fingerprints are being replaced, and what a match proves.
The host key prompt you always accept — what the SHA256: line is asking you to compare
When you connect to a server via SSH for the first time, you see a prompt asking whether to accept the host key. The prompt displays a fingerprint: `SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8` or similar. This fingerprint is a hash of the server's public key. You are being asked to verify out-of-band (outside the SSH protocol) that you recognize this key. The prompt also typically shows the key type (RSA, ED25519, ECDSA) and fingerprint format. If you have seen this key's fingerprint before through a trusted channel, you can confidently type "yes". If not, accepting means trusting the network to deliver the correct key.
A fingerprint is simply the output of a cryptographic hash function applied to the encoded key. For SSH, the key is encoded as a binary blob (the OpenSSH wire format), and the hash is computed over that blob. The fingerprint is shorter than the full key, making it readable and typeable. The same fingerprint will always result from the same key, so you can compare a fingerprint published in multiple places or channels.
Fingerprint equals hash of the encoding — the DER certificate or the public key blob as the input
SSH host keys and TLS certificates are encoded differently, but the fingerprinting principle is identical. For SSH, the fingerprint is computed from the public key material. For TLS certificates, the fingerprint is computed from the entire certificate (including issuer, validity dates and other fields). When you connect to a web server, the browser does not display the certificate fingerprint to you, because TLS uses a different trust model: the browser trusts a set of certificate authorities (CAs) that are pre-installed, and those CAs vouch for the certificate. SSH uses no pre-installed CAs; instead, you trust specific keys and store them locally in `~/.ssh/known_hosts`.
Because the fingerprint includes the entire certificate bytes for TLS, changing the validity dates without re-signing results in a different fingerprint. For SSH, the fingerprint is only of the public key, so the fingerprint is stable as long as the key is not changed.
This calculator demonstrates SHA-1 and SHA-256 lengths; fingerprint-policy recommendations require protocol sources
Historically, SSH fingerprints were displayed in MD5 hexadecimal. MD5 is cryptographically broken and collisions are practical. The security community moved to SHA-256 fingerprints as the default. You may still see both formats displayed by your SSH client: `SHA256: base64` and `MD5: hex`. The SHA-256 fingerprint is the one to trust for identity verification. If you see both, compare the SHA-256 version against a fingerprint from a trusted source (the server's website, a signed email from an admin, an internal wiki). The MD5 fingerprint is less reliable because MD5 collisions exist.
The change in fingerprint format is a visible sign of the cryptographic transition. Older OpenSSH versions showed only MD5. Modern versions show SHA-256 by default. The command `ssh-keygen -l -f /path/to/key` displays the key's fingerprint in the default format for your version of ssh-keygen; you can force a specific format with the `-E` flag (e.g., `-E sha256` or `-E md5`).
SSH's base64 SHA256: format — the encoding change that made fingerprints shorter than hex
SSH base64 fingerprints use a variant format: they are prefixed with the algorithm name and a colon, e.g., `SHA256:base64string`. This is different from subresource integrity (SRI) format, which uses a hyphen and includes only standard base64. The SSH format includes a label that makes it unambiguous which algorithm produced the digest. When you see a fingerprint in SSH output, the algorithm is always shown. When you see an SRI integrity attribute, the algorithm is encoded as a prefix with a hyphen.
The base64 output from the ToolAcre SHA hash calculator is the standard form; to match SSH fingerprints, prepend `SHA256: ` (algorithm name, colon and space). The hex form from the calculator is not the form SSH displays, though it represents the same digest and is equally valid for verification purposes.
What a match proves — that you hold the same key bytes the other side published, and nothing about the key's owner without an out-of-band check
A fingerprint match proves two things: first, that you hold the same key bytes the other side published, and second, that neither the key nor the fingerprint has been altered since the digest was computed. It does not prove the identity of the key's owner or authorize any specific action. Verifying a fingerprint out-of-band is a necessary but not sufficient condition for trusting a key. You must also verify that the person who published the fingerprint is who they claim to be.
In practice, if an admin publishes a server's SSH fingerprint on the company intranet or in a signed email, you can verify it matches the prompt you receive when connecting. If the fingerprint does not match, you can confidently reject the connection because someone is intercepting your traffic or the server key has changed. If the fingerprint matches, you know you have the right key. Whether that key belongs to the right server is a separate question—one you can answer by verifying the publication channel (does the intranet page look legitimate? is the email actually from that admin's account?).
Worked example — verifying a fingerprint against one published through a trusted channel, step by step
A certificate fingerprint serves the same purpose: it identifies a specific certificate uniquely. If a TLS server changes its certificate (e.g., during renewal), the new certificate has a different fingerprint. Certificate pinning—hardcoding a fingerprint or a small set of acceptable fingerprints in an application—is a security technique to detect certificate changes. If the server presents a certificate with a different fingerprint, the application rejects it. This protects against a compromised CA issuing a fraudulent certificate that the browser would otherwise trust.
Certificate pinning requires careful management: if the server updates its certificate and you did not anticipate it, your application will reject the valid new certificate. Many applications use public-key pinning instead, which pins the public key rather than the entire certificate. This allows certificate renewal without rejection as long as the same key is used.
Worked example: verify with protocol-aware tools because ToolAcre hashes pasted UTF-8 text, not DER or SSH wire bytes
Computing a fingerprint manually for verification is straightforward. Save the certificate or key to a file, use `openssl dgst -sha256 filename` or `ssh-keygen -l -f filename -E sha256` to display the fingerprint, and compare against the one the server showed you. The ToolAcre SHA hash calculator can also compute the digest if you paste the key bytes, but remember that the calculator hashes UTF-8 text you paste, not binary files. If the key is in PEM format (text with `-----BEGIN CERTIFICATE-----` header and base64-encoded bytes), you can paste it into the calculator. If it is in DER format (binary), you need to use command-line tools or convert to PEM first.
The boundary is important: ToolAcre hashes UTF-8 text that you paste in the calculator interface. It does not read files from your device (all computation is in the browser, in your tab, with no network). If you have a key file on disk, you can open it in a text editor, copy the text and paste into the calculator if it is in PEM format. Or you can use command-line tools like `openssl`, `ssh-keygen` or `sha256sum` to compute the hash locally.
Takeaway: compare fingerprints out of band — the ToolAcre SHA hash calculator shows what SHA-1 and SHA-256 digests look like at the lengths fingerprints use
The ToolAcre SHA hash calculator displays SHA-1 and SHA-256 digests for any text input. If you paste a certificate in PEM format or an SSH public key, the calculator computes both digests. For SSH keys, the calculator will hash the text you paste; if you paste the standard base64-encoded SSH public key format, the digest will not match the SSH fingerprint because SSH applies its own formatting (the wire format) before hashing. For a direct match, you need the key in the exact format SSH uses internally, which is not the public display format.
For certificate fingerprints, the behavior is similar: if you paste the PEM-encoded certificate text, the calculator hashes that text. A certificate's fingerprint is computed over the encoded certificate bytes (DER format), not the PEM text wrapper. The bytes are the same, but the text encoding differs. To match a certificate fingerprint from OpenSSL or the browser's certificate viewer, you would need to provide the DER bytes, which are not human-readable. The calculator's purpose is to hash UTF-8 text you can paste and read, making the boundary clear: it hashes text input, not cryptographic key files in their standard binary or wire-protocol forms.