SSL Handshake Trace
Full TLS handshake trace to any host and port.
Enter a value above to run SSL Handshake Trace
e.g. example.com
Quick answer
SSL Handshake Trace runs a full TLS handshake to any host and port and shows each step, the negotiated version, cipher, and certificate exchange, so you can see exactly where a connection fails. It is a readable, no-setup alternative to openssl s_client for debugging protocol, cipher, and SNI problems.
SSL Handshake Trace performs a full TLS handshake to any host and port and shows you each step as it happens: the protocol version negotiated, the cipher suite chosen, the certificates exchanged, and where the negotiation succeeds or breaks. It is the equivalent of running openssl s_client and reading the output, but presented clearly, so you can debug a TLS problem without memorizing command-line flags.
Most SSL tools tell you what the certificate is; this one tells you how the connection is established. When a client cannot connect, the failure is often in the handshake itself, a protocol mismatch, no shared cipher, a rejected certificate, or a wrong SNI, rather than in the certificate's contents. Tracing the handshake shows exactly which stage fails, which is the difference between guessing and knowing when you are chasing an intermittent or client-specific TLS error.
Anatomy of a TLS handshake
A TLS handshake begins with the client sending a ClientHello listing its supported versions, cipher suites, and the SNI hostname. The server replies with a ServerHello choosing the version and cipher, then sends its certificate chain. The two sides perform a key exchange to derive shared session keys, verify each other's messages, and switch to encrypted traffic. In TLS 1.3 this is streamlined to a single round trip. The trace shows each of these messages so you can see what was offered and what was agreed.
TLS 1.3 and version negotiation
TLS 1.3 (RFC 8446, 2018) is the current version and should be preferred: it is faster, drops obsolete ciphers, and encrypts more of the handshake. TLS 1.2 remains widely supported. TLS 1.0 and 1.1 are deprecated and should be disabled. The trace reports the version actually negotiated, so if a client fails you can see whether the server refused its highest version or fell back to something it should no longer accept. A handshake that will not go above TLS 1.0 is a configuration to fix.
Debugging handshake failures
Read the trace to the point it stops. A failure right after ClientHello often means no shared protocol version or cipher suite, common when an old client meets a modern server or vice versa. A failure while processing the certificate points to an untrusted or incomplete chain, or a name that does not match SNI. A reset before any TLS bytes usually means the port is not actually speaking TLS. Each stopping point maps to a specific, fixable cause.
Why trace instead of just checking the certificate
Certificate checks assume the handshake completes. When it does not, you need to see the negotiation. Tracing reveals cipher and version mismatches, SNI problems where the server returns the wrong certificate, and cases where a load balancer or middlebox interferes. It is the right tool when a service works from one client but fails from another, because those differences live in the handshake parameters, not in the certificate file itself.
Frequently asked questions
- What is a TLS handshake?
- It is the negotiation that sets up an encrypted connection before any application data flows. The client offers protocol versions and cipher suites and the target hostname (SNI); the server picks a version and cipher and presents its certificate; the two derive shared keys and switch to encryption. If any step fails, no secure connection forms, which is why tracing it pinpoints connection problems.
- Which TLS version should my server use?
- Prefer TLS 1.3, the current version from 2018, which is faster and more secure, while still supporting TLS 1.2 for broad compatibility. Disable TLS 1.0 and 1.1, which are deprecated and no longer considered safe. The trace shows which version was negotiated, so you can confirm your server offers 1.3 and is not silently accepting obsolete versions.
- The handshake fails right after ClientHello, why?
- That usually means the client and server share no common protocol version or cipher suite. It happens when a very old client meets a hardened modern server that has dropped legacy ciphers, or when a client only speaks a deprecated TLS version the server refuses. Compare the offered versions and ciphers in the trace against what the server accepts, and adjust one side.
- How is this different from openssl s_client?
- It does the same job, connecting and walking through the handshake, but presents the result in a readable form without you constructing the command or parsing raw output. It is convenient for a quick check from a browser and for sharing a result. For deep local scripting, s_client is still there; this tool is the fast, no-setup equivalent.
- Can I trace a handshake on a non-standard port?
- Yes. Set the port to whatever the TLS service uses: 443 for HTTPS, 465 or 587 for mail submission, 993 for IMAP, or any custom port. The tool performs the handshake there, which is how you debug TLS on mail, directory, and application services rather than only websites.
- It connects but the certificate is rejected, what now?
- That points to a chain or name problem rather than a negotiation one. Check that the server sends the full intermediate chain and that the certificate's SAN includes the hostname you connected with via SNI. Use the SSL Checker and CA Matcher to confirm the chain is complete and the intermediate is correct, then reload the server.