Certificate fingerprints identify the exact encoded X.509 certificate file being reviewed. They are useful when a portal, ticket, certificate authority record, or server capture must be matched against a file before renewal, installation, bundle cleanup, or incident handoff.
OpenSSL prints certificate fingerprints with the x509 command. The -fingerprint option hashes the certificate object, -sha256 selects the digest used for modern handoffs, and -noout keeps the PEM certificate body out of the output.
Treat the fingerprint as an identity check, not a trust decision by itself. A matching fingerprint proves that the checked file is the same certificate as the trusted reference, while chain trust, hostname coverage, expiry, revocation, and live deployment state still need their own checks when those questions matter.
Steps to check a certificate fingerprint using OpenSSL:
- Get the trusted SHA-256 fingerprint from the certificate authority portal, deployment ticket, server owner, or another approved record.
Do not treat a fingerprint copied from the same unverified file, email, or network path as independent proof.
- Print the SHA-256 fingerprint from a PEM certificate file.
$ openssl x509 -in server.crt -noout -fingerprint -sha256 sha256 Fingerprint=07:9E:85:C0:67:DD:1A:FB:7C:B6:1E:A8:81:56:B9:79:7C:2D:F2:07:81:88:02:DD:5E:8A:1D:CA:23:D0:85:3C
Replace server.crt with the certificate file being approved. Use the same digest algorithm as the trusted record; SHA-256 is the normal choice for new certificate handoffs.
- Compare the entire fingerprint string with the trusted value.
Stop if any hex pair differs, if the trusted value uses a different hash algorithm, or if the certificate file came from the same untrusted source as the value being compared.
- Read a binary DER certificate with an explicit input format.
$ openssl x509 -inform DER -in server.der -noout -fingerprint -sha256 sha256 Fingerprint=07:9E:85:C0:67:DD:1A:FB:7C:B6:1E:A8:81:56:B9:79:7C:2D:F2:07:81:88:02:DD:5E:8A:1D:CA:23:D0:85:3C
The DER and PEM versions of the same certificate should print the same fingerprint because the encoded certificate object is unchanged.
- Recheck any suspected alternate certificate before approving the handoff.
$ openssl x509 -in old-server.crt -noout -fingerprint -sha256 sha256 Fingerprint=75:0B:ED:3F:2D:E7:B0:C5:4A:90:66:F0:C6:58:D3:DF:1E:CB:2A:F8:5B:24:EE:7C:9F:C3:01:95:67:0C:5F:70
This fingerprint differs from the trusted server.crt value, even though the filename or subject could look familiar. Do not install, approve, or close the ticket until the mismatch is explained.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.