Certificate Fingerprint Database

Look up and compare certificate fingerprints (SHA-1, SHA-256, MD5)

Domain

Port

Certificate Fingerprints

About TLS Fingerprint Database

Database of known TLS fingerprints (JA3, JA4, JARM) for identifying clients, bots, and potential threats. Maps fingerprints to known applications and threat actors.

How to Use

1Enter a fingerprint hash or the domain name to retrieve its TLS fingerprint.
2Click "Lookup Fingerprints" to search the database.
3Review the fingerprint details, matching applications, and identification results.

Use Cases

•Bot detection by identifying automated TLS client signatures
•Threat hunting using known malicious TLS fingerprints
•Client identification and security research on TLS behavior

Frequently Asked Questions

We support JA3 (MD5 hash of TLS ClientHello), JA4 (improved JA3 with more fields), and JARM (active TLS server fingerprinting) for both client and server identification.

Fingerprint accuracy depends on the database coverage. JA3/JA4 can identify specific client libraries and versions, but may not distinguish between different applications using the same TLS library.

JA3 and JA4 fingerprints are generated from the ClientHello message fields. JARM fingerprints are actively generated by sending specially crafted TLS probes to a server. Use our other tools to generate these fingerprints.

SHA-256, without hesitation. MD5 and SHA-1 are included because older tooling, audit records and support tickets still quote them, and because some hardware tokens were provisioned against them — but both have practical collision attacks and neither should inform a decision today. SHA-384 and SHA-512 are shown for completeness and match nothing in common use. If you are recording a value for comparison against something someone else gave you, match their algorithm, then move to SHA-256 for anything new.

Almost always because the two sides hashed different things. The fingerprint is computed over the DER encoding, so a certificate converted to PEM and back, or re-saved by a tool that changes its formatting, produces a different hash of the same logical certificate. The other common cause is fetching a different certificate: a renewed one, a certificate from a different host on the same address, or one served by a load balancer that has not been reloaded. Check the serial number alongside the hash before concluding anything.

No. This tool computes fingerprints and identifiers; it does not consult a database of known-bad or distrusted certificates. That is a deliberate division: a computed hash is a fact about a document, while a verdict depends on a list that changes daily and on which entry you match. For the reputation side of the question, check whether the certificate appears in Certificate Transparency, and review the issuer itself. Use the fingerprint here to confirm you are looking at the certificate you think you are.

For matching inside data that indexes certificates rather than serving them. Revocation lists, transparency logs and certificate inventories all key on issuer plus serial, because serial numbers are short and fixed-length where fingerprints are long. Serial numbers are unique per authority rather than globally, so they are meaningless without the issuer — which is why the two are reported together here.

Realistically, by monitoring rather than by pinning. Public key pinning in the browser is finished: the mechanism was deprecated, support was removed, and a pinned certificate that expires breaks the site outright. The practice that replaced it is to record the fingerprint of the certificate you expect, then alert when the certificate served changes unexpectedly. That catches interception and misissuance without the fragility, provided you treat a change as a signal to investigate rather than as a failure to auto-heal.

How the Fingerprints Are Computed

A certificate fingerprint is a hash of the certificate itself. The same certificate always produces the same value, and any change to a single byte changes it completely.

1Fetch the leaf certificate exactly as the server presents it, in its DER encoded form.
2Hash those exact bytes five times, with MD5, SHA-1, SHA-256, SHA-384 and SHA-512.
3Format each digest as colon-separated uppercase hex, which is the form used by every tool that displays fingerprints.
4Read the serial number, issuer and subject from the parsed certificate so a value can be tied back to a specific document.

MD5 and SHA-1 are shown for identification against older records only. Neither is strong enough to rely on for security decisions; use SHA-256 or stronger.

Tips & Best Practices

•Query the database to identify certificates by their fingerprints
•Use fingerprint lookups during incident response to identify affected certificates
•Compare fingerprints against known good values for verification
•Maintain local fingerprint databases for critical infrastructure

Technical Details

Database: Certificate fingerprint database with SHA-256 and SHA-1 hashes
Query: Lookup by fingerprint, domain, or issuer
Results: Certificate details and trust status
Export: Database query results in CSV and JSON formats