TLS Implementation Fingerprinter
Compute a genuine JA3S fingerprint from a server's real ServerHello and test whether it enforces its own cipher order.
Monitor this automatically
NetTests can run this check on a schedule, preserve historical results, compare changes over time, and alert you the moment something breaks.
Start monitoring free → See all monitoring productsFrequently Asked Questions
What is JA3S fingerprinting?
JA3S hashes fields taken directly from a server's ServerHello handshake message — the negotiated TLS version, chosen cipher suite, and the order the server listed its TLS extensions in. This produces an MD5 hash that's a reliable fingerprint of the server's TLS stack, independent of any version banner it may suppress.
How is this computed — is it a real handshake or a simulation?
This tool opens a real TCP connection and sends a genuine TLS ClientHello, then reads and parses the raw bytes of the server's actual ServerHello response — the same approach the original JA3S reference implementation uses. No handshake is completed and no application data is exchanged; the connection is closed immediately after the ServerHello is parsed.
Why JA3S and not JA4S?
JA4S is a newer format from FoxIO that requires an OEM license for many commercial uses. JA3S, from Salesforce, is BSD-3-Clause licensed and safe to use here. Both measure the same underlying idea — cipher/extension ordering — JA3S is simply the one we can ship without a licensing dependency.
Does this tell me what software the server is running?
Not on its own. This tool computes and displays the raw hash and its human-readable components — it does not include a hash-to-software lookup database. Different TLS libraries (OpenSSL, BoringSSL, NSS, SChannel, etc.) do produce distinct, consistent fingerprints, so the hash is useful for comparing servers against each other or against a known-good baseline, but identifying the specific software from the hash alone requires cross-referencing against an external community database.
What does the cipher suite preference check tell me?
It sends two ClientHellos with the same cipher list in opposite order. If the server negotiates the same cipher both times, it's enforcing its own preferred order — a hardening best practice. If the negotiated cipher changes to match whichever list's first entry, the server is simply deferring to the client, which is common but not as defensively configured.
Why does this require authentication?
This tool sends TLS handshake probe traffic to the target. From the target's perspective this looks like reconnaissance activity, so authentication and target-ownership verification ensure users only probe infrastructure they control.