TLS Negotiation Debug

Debug TLS handshake negotiation details

Domain

Port

Results

About

The TLS Negotiation Debug tool provides detailed insights into the TLS handshake process between a client and server, showing exactly how the connection is established step by step. It captures and analyzes the ClientHello and ServerHello messages, identifies the negotiated protocol version, cipher suite, compression method, and any extensions used during the handshake.

This debugging tool is invaluable when troubleshooting TLS connection failures, cipher suite mismatches, protocol version issues, or SNI (Server Name Indication) problems. It shows the exact bytes exchanged during negotiation, making it possible to diagnose issues that other tools cannot reveal. Use it when clients fail to connect, when you see unexpected cipher suite selections, or when you need to verify TLS configuration from a client perspective.

How to Use

1Enter the target domain and port to analyze the TLS handshake
2Click "Debug Negotiation" to initiate the handshake capture
3Review the detailed ClientHello and ServerHello message breakdown
4Analyze the negotiated parameters including protocol, cipher, extensions, and any errors

Use Cases

•Connection Failure Diagnosis: Debug why clients cannot establish TLS connections by examining the exact handshake messages and identifying where the failure occurs
•Cipher Suite Mismatch: Identify when clients and servers cannot agree on a common cipher suite, causing connection failures or degraded security
•SNI Troubleshooting: Diagnose Server Name Indication issues that cause certificates to be served for the wrong domain on shared hosting
•Protocol Compatibility: Verify which TLS versions are actually negotiated during connection, not just what is configured on the server
•Client Configuration Validation: Test how specific clients (browsers, curl, OpenSSL) negotiate TLS connections to your server

What The Trace Shows

When a connection fails, the error rarely says which part failed. This page walks the handshake and stops at the first stage that breaks.

1Trace the stages in order: name resolution, TCP connection, TLS handshake, certificate exchange. Each is attempted separately so the first failure is identified rather than reported as a single opaque error at the end.
2Time the successful path, so you get both the diagnosis on failure and the measurement on success. A working connection tells you the handshake completed and how long it took.
3Quote the error from the failing stage verbatim, because the wording distinguishes causes that otherwise look alike — a name mismatch and an unknown authority both present as verification failures but need completely different fixes.

Because the trace stops at the first failure, one run identifies the earliest problem rather than listing every possible one. Fix that and re-run to find the next, which is usually how several stacked misconfigurations are worked through.

Tips & Best Practices

•Use this tool when SSL Labs or other scanners show "handshake_failure" errors
•Compare ClientHello from different clients to understand why some connect and others fail
•Check for SNI extension presence in ClientHello when debugging virtual hosting issues
•Capture multiple handshakes to identify intermittent negotiation failures

Technical Details

●Handshake Messages: Captures and decodes ClientHello, ServerHello, Certificate, ServerKeyExchange, ServerHelloDone, ClientKeyExchange, ChangeCipherSpec, and Finished messages

●Extension Analysis: Decodes all TLS extensions including SNI, ALPN, supported_groups, key_share, signature_algorithms

●Cipher Suite Parsing: Breaks down negotiated cipher suite into component algorithms (key exchange, auth, encryption, MAC)

●Error Detection: Identifies alert messages (fatal, warning) and their specific error codes during negotiation

Frequently Asked Questions

TLS negotiation can fail due to: no common cipher suite between client and server, unsupported protocol version, certificate chain issues, SNI mismatch on shared hosting, expired or revoked certificates, firewall blocking handshake messages, or server configuration errors. The debug output shows exactly which step failed.

Server Name Indication (SNI) is a TLS extension that tells the server which hostname the client is requesting. On servers hosting multiple HTTPS sites, SNI determines which certificate to present. If SNI is missing or incorrect, the server may present the wrong certificate, causing browser warnings or connection failures.

SSL Labs performs a comprehensive external scan and provides a grade, while this tool gives you raw access to the actual handshake messages. It is more useful for debugging specific connection failures, testing individual cipher suites, or analyzing handshakes from specific client configurations that SSL Labs cannot simulate.

They answer closely related questions from slightly different angles. The debugger walks DNS, TCP and TLS and names the stage that broke; this traces the negotiation itself and focuses on what was offered and selected. In practice they overlap heavily — run the debugger when a connection fails outright, and this when it connects but negotiates something you did not expect.

Because later stages depend on earlier ones and cannot be meaningfully attempted once one has failed. A TLS handshake cannot be traced when the TCP connection was refused. Stopping gives you the earliest problem, which is the one to fix — and re-running after each fix is how a stack of misconfigurations gets worked through rather than requiring them all to be diagnosed at once.

Almost always an algorithm disagreement rather than a broken server. The failing client offers no cipher suite the server accepts, no shared elliptic curve, or no common signature algorithm — typically because it is older, or because a newer algorithm was deprecated and one side never updated. Reproducing it means connecting with a Client Hello shaped like that client, which the client-hello page on this site helps with.

At the timing, not the diagnosis. A completed trace with a long duration means nothing is broken and the time is being spent somewhere — network distance, a full two-round-trip handshake on an old protocol, or resolver latency. The performance monitor separates DNS, TCP and TLS into their own figures, which is where you can see which stage to attribute it to.

It reports the connection stages, and certificate problems surface at the exchange stage as a verification failure with a quoted reason. The distinction between a name mismatch and an unknown authority is preserved, which is the useful part. For a full verdict on a certificate use the trust verification page; this is about getting the connection to work at all.