How to Check an SSL Certificate Fingerprint
An SSL certificate fingerprint is a digest of the certificate bytes. To check it with SSL Certificate Decoder, paste a public PEM certificate or upload a PEM-formatted .pem, .crt, or .cer file, click Decode, and read the SHA-256 and SHA-1 values in the result. Copy the SHA-256 value when you need to confirm that a server or deployment is using the exact certificate you expect.
What an SSL certificate fingerprint checks
A fingerprint identifies a particular set of certificate bytes. It is different from the certificate's Common Name, issuer, or visible domain names. Two certificates can show the same domain and certificate authority while still having different fingerprints because the underlying certificate data is different.
This is useful after a renewal or deployment change. Instead of deciding from the certificate name alone, compare the fingerprint of a trusted certificate copy with the fingerprint of the certificate obtained from the path that clients actually use. A match shows that the certificate bytes are the same. A different fingerprint shows that the files are different and gives you a reason to inspect the serial number, validity dates, issuer, and SAN entries next.
SHA-256 and SHA-1 fingerprints
| Value | What it is useful for | How to use it on this page |
|---|---|---|
| SHA-256 Fingerprint | The preferred value for most operational comparisons of the exact certificate bytes. | Decode the public certificate, copy the displayed SHA-256 value, and compare it with a trusted record or another decoded certificate. |
| SHA-1 Fingerprint | A reference value that may still appear in existing inventory records or older tooling. | Read it from the same decoded result when a documented comparison specifically asks for SHA-1. |
The page displays both SHA-256 and SHA-1 fingerprints. For a new comparison, use SHA-256 unless your own certificate inventory, monitoring system, or deployment record explicitly asks for SHA-1.
How to check a certificate fingerprint
- Open the SSL Certificate Decoder.
- Get the public certificate that you want to inspect. It can come from a server export, a certificate authority download, or a local certificate file.
- Paste the complete PEM block, including
-----BEGIN CERTIFICATE-----and-----END CERTIFICATE-----, or upload a.pem,.crt, or.cerfile that contains PEM certificate data. - Click Decode. The page parses the certificate in the browser and presents its certificate details.
- Find the SHA-256 Fingerprint and SHA-1 Fingerprint in the decoded fields. Use the Copy control in the result area when you need to place a value in a ticket, deployment record, or comparison document.
- Compare the copied SHA-256 value character for character with the trusted value. Do not compare only the first or last few characters.
Use Load Safe Sample if you want to see the decode and copy workflow without using your own certificate. Use Clear when you are done with the current input.
Confirming which certificate a server returned
A fingerprint checker does not connect to a hostname and replace your input with a remote certificate. It shows the certificate that you pasted or uploaded. That distinction matters when you are checking a live deployment.
First, obtain the public certificate from the same route clients use. For example, collect it from the actual edge proxy, load balancer, web server, or staging hostname that serves the traffic you are investigating. Then decode that certificate in the tool and compare its SHA-256 fingerprint against the trusted certificate file or the documented value from the planned deployment.
A useful result pattern
If the SHA-256 values match, the two certificate files have the same certificate bytes. If they differ, clients are seeing a different certificate. Inspect the Serial Number, Not Before and Not After dates, Issuer, signature algorithm, and SAN entries to understand whether you are looking at a normal renewal, a different endpoint, or an unexpected deployment.
Copy and compare scenarios
Checking a certificate replacement
Save the old public certificate and the new public certificate. Decode each one separately and copy the SHA-256 fingerprints into a deployment note. A changed fingerprint confirms that the certificate bytes changed. Then compare dates and SAN entries to make sure the replacement also covers the intended names.
Comparing a local file with a live endpoint
Decode the certificate file that was prepared for deployment and record its SHA-256 fingerprint. Next, retrieve the public certificate from the live endpoint, decode that copy, and compare the values. Matching values show that the live path is serving the planned certificate. A mismatch can point to an older file, a separate proxy, or a different deployment path.
Documenting a certificate for a handoff
When handing a certificate record to another administrator, include the SHA-256 fingerprint with the hostname, issuer, serial number, and validity period. The fingerprint gives the other person a direct value to compare after they retrieve or decode their own copy.
What a fingerprint does not prove
A matching fingerprint proves that two compared certificate files are the same. It does not by itself prove that the certificate is currently valid for a particular hostname, trusted by a client, or installed at every endpoint. Check SAN for hostname coverage, Not Before and Not After for dates, and the issuer and chain information for the rest of the review.
Likewise, a fingerprint comparison does not make a private key safe to share. This tool is for public certificate data only. Do not paste a private key, a password, a PFX or P12 bundle, or another secret into the page. Private keys are outside the supported input boundary and are rejected before decoding.
Common questions
Which fingerprint should I compare?
Use SHA-256 for most operational checks. Use SHA-1 only when your existing record or tool specifically requires it.
Does the decoder fetch a certificate from a domain name?
No. The tool decodes the public certificate that you paste or upload. Obtain the certificate from the server path you want to check before using the decoder.
Can two certificates with the same domain have different fingerprints?
Yes. A domain name and issuer may be the same while the certificate bytes differ. The SHA-256 fingerprint is how you determine whether the exact certificate changed.
What file formats can I use?
The page accepts public PEM certificate data and PEM certificates saved as .pem, .crt, or .cer. A CRT or CER file must contain PEM text. Binary DER, P7B, PFX, P12, CSRs, and private-key files are outside the supported input boundary.
Are my certificate contents uploaded?
The site states that decoding happens in the browser and that the selected certificate is not uploaded or stored for this workflow.
A simple check before closing the ticket
Keep the trusted SHA-256 fingerprint beside the certificate source and the endpoint you checked. Decode the public certificate returned by that endpoint, copy the SHA-256 value, and compare the complete value. If it differs, inspect the serial number, dates, issuer, and SAN before deciding whether the deployment is correct.
Open SSL Certificate Decoder
