SSL/TLS Handshake Debugger

Debug and analyze the SSL/TLS handshake process for a domain

Domain

Port

Handshake Analysis

About TLS Handshake Debugger

Step-by-step debugger for TLS handshake process. Shows each message exchange between client and server with timing, cipher selection, and error details.

How to Use

1Enter the domain name and optional port number (default 443).
2Click "Debug Handshake" to start the step-by-step analysis.
3Review each handshake step showing success/failure status and details.

Use Cases

•Debug connection failures and identify where the handshake breaks
•Understand TLS negotiation details and cipher selection
•Troubleshoot timeout issues during TLS connection establishment

Frequently Asked Questions

A TLS handshake involves the client and server exchanging messages to agree on protocol versions, cipher suites, and authentication certificates. This includes ClientHello, ServerHello, certificate exchange, key exchange, and finished messages.

Each step shows OK or Failed status. OK means that handshake phase succeeded. Failed indicates where the connection broke. Look for the first failed step to identify the root cause of connection issues.

The failures that account for most handshake problems: certificate validation failures including expired certificates, self-signed certificates and incomplete chains; protocol version mismatches where the client and server share no version; cipher suite mismatches where they share no suite; and timeouts, which almost always mean a firewall, load balancer or network path is dropping the traffic rather than the server rejecting it. The distinction between a rejection and a timeout is the most useful thing the output gives you, because it separates a TLS problem from a network one.

Read the stage it stopped at. DNS means the name does not resolve; TCP means nothing is listening or a firewall is dropping the port; TLS means the handshake itself was rejected. Each points at a different owner, and the stage label tells you which conversation to have. Fix it, re-run, and the next failure further along is the next problem in the chain.

Compare what each client offers. A failure that reproduces for one browser and not another usually means an algorithm disagreement rather than a broken server: a client offering no overlapping cipher suite, an old client with no shared groups, or a client missing the server name. Reproduce it by connecting with a Client Hello shaped like the failing client, which the client-hello page helps with.

Because a handshake can complete and still be wrong. Connecting without validating the certificate proves the protocol works, not that the right certificate was served — a server with a perfectly valid certificate for the wrong name completes the handshake happily and then shows visitors a warning. The name check is a separate concern from the transport, and this page covers both.

Not necessarily. One handshake includes DNS, one TCP round trip and the TLS exchange, so the distance to the server sets a floor that no configuration can beat. A high figure next to a healthy certificate usually means geography. Compare with the performance monitor, which separates the stages and shows whether the time is in DNS, TCP or TLS before concluding anything.

Expired or not-yet-valid certificates, and hostname mismatches. Both produce immediate user-visible warnings, and both are fixed by deploying the right file rather than by tuning anything. Protocol and cipher negotiation failures affect only the clients that hit them, which makes them less urgent but still worth resolving before a client upgrade exposes them to more traffic.

What the Debug Run Shows

This page walks one connection through its stages and stops at the first one that fails, so a broken connection reports which stage broke it rather than a single opaque error.

1Resolve the hostname. Failure here means the name does not resolve from this location, and no amount of server configuration will matter until it does.
2Open the TCP connection to the port. A refused connection means nothing is listening or a firewall is dropping it — distinct problems with distinct fixes.
3Complete the TLS handshake and read the certificate, recording the negotiated version. This is where most reported failures actually occur: protocol mismatch, cipher disagreement, or a certificate the client refuses.

A successful run reports the total handshake time; a failed one names the stage and quotes the error. Because it stops at the first failure, a single run tells you the earliest problem rather than a list of every possible one — fix that and re-run to find the next.

Tips & Best Practices

•Use handshake debugging to diagnose TLS connection failures
•Analyze handshake messages to identify specific failure points
•Test with different client configurations to reproduce issues
•Check server logs for additional handshake diagnostic information

Technical Details

Debug: TLS handshake message sequence and content analysis
Messages: ClientHello, ServerHello, Certificate, Finished analysis
Errors: Handshake failure identification and cause analysis
Output: Handshake debug log with error details