TLS Handshake Trace
Trace a live TLS handshake to review protocol and cipher, certificate identity and trust, plus DNS-to-negotiation timing from one remote probe.{{ summaryTitle }}
{{ summaryLine }}
| Signal | Status | Evidence | Next check | Copy |
|---|---|---|---|---|
| {{ row.signal }} | {{ row.status }} | {{ row.evidence }} | {{ row.nextCheck }} |
| Field | Value | Meaning | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.value }} | {{ row.detail }} |
{{ transcriptText }}
A browser can reach a server and still fail before any web page or API response exists. Transport Layer Security (TLS) must first establish an encrypted connection, agree on cryptographic parameters, and authenticate the server. A failure during that exchange is different from an HTTP error because the application has not started speaking yet.
The connection begins with three observable jobs. Domain Name System (DNS) resolution finds an address, a Transmission Control Protocol (TCP) connection opens to a port, and the TLS handshake negotiates security over that connection. Separating their timings helps distinguish a slow resolver from a blocked listener or a slow TLS negotiation, but one measurement is only a snapshot of one route.
- Server Name Indication (SNI)
- The hostname sent during the opening TLS message so a shared address can choose the intended certificate and virtual host.
- Application-Layer Protocol Negotiation (ALPN)
- The handshake extension used to select an application protocol such as HTTP/2 or HTTP/1.1.
- Certificate path
- The leaf certificate presented by the service plus any intermediate certificates returned to help a client build trust to a root.
A negotiated connection does not prove that the certificate is right for every client. Hostname coverage comes from subject alternative names, while trust depends on the client trust store, validation policy, time, and certificate path it can build. A remote probe can therefore succeed when the affected client fails, or reject a chain that a managed client accepts through a private trust anchor.
Virtual hosting creates another common trap. Connecting to an IP address without the intended SNI name may retrieve a default certificate that belongs to a different service. The host, port, SNI name, observation time, and network vantage point all belong with the result when the trace is used as incident evidence.
How to Use This Tool:
Start with the endpoint a real client is trying to reach, then add detail only when the first trace leaves a specific question unanswered.
- Enter a hostname, URL, or IP literal in Host or URL and confirm the listener in Port. A port inside the URL overrides the separate port value; otherwise 443 is the usual HTTPS choice.
- Open Advanced when the test needs a different Trace detail, an SNI override, or more time. Use the intended service hostname as SNI when tracing an IP address or a shared listener.
- Select Run trace. If the request fails, use the returned DNS, timeout, connection, or TLS message to correct the target or focus the next network check.
- Read Trace diagnosis first. Use Endpoint ledger for certificate and negotiation evidence, Phase timeline for the observed setup time, and the transcript only when a lower-level handoff needs it.
Interpreting Results:
Handshake evidence looks clear means seven repository-authored review checks all passed for this probe. It is not a security grade or a promise that another client will obtain the same result.
- Check Certificate verification, subject alternative names, validity dates, and chain shape together. A successful negotiation alone does not establish hostname coverage or trust.
- Treat a large DNS, TCP, or TLS segment as a lead for repeated testing, not proof of a lasting bottleneck.
- Compare the observed protocol and cipher with the service policy. The review label treats anything other than TLS 1.3 as a flag even when an older version is intentionally supported.
- Repeat the check from the affected client path before closing a trust, CDN-edge, split-DNS, or intermittent latency incident.
Technical Details:
A TLS trace observes one connection from a remote network. Resolution happens first, TCP establishes the ordered transport, and the TLS client offers SNI plus ALPN choices while negotiating a protocol, cipher suite, key material, and server certificate path.
Mechanism Core
| Stage | Observed evidence | What a failure narrows |
|---|---|---|
| DNS lookup | Resolved IPv4 or IPv6 address and elapsed milliseconds | Name resolution, resolver reachability, or an invalid hostname |
| TCP connect | Connection time to the selected address and port | Routing, firewall, listener, or transport reachability |
| TLS negotiation | Protocol, cipher, ALPN, SNI, certificate, trust result, and elapsed milliseconds | TLS policy, certificate presentation, trust, or negotiation failure |
| Evidence projection | Certificate lifetime, chain and name counts, review flags, and readable transcript | Which returned facts need a targeted client-side or server-side check |
Formula Core
The displayed setup time uses the returned total when it is a finite value from 0 through 120,000 milliseconds. If that total is unavailable, the three measured phases are added.
Certificate lifetime is measured in whole 24-hour periods from the trace observation to the leaf certificate expiry timestamp. The floor operation means a partial remaining day is not rounded up.
Rule Core
The overall review result counts independent operational flags. These rules are intentionally conservative and must be compared with the service's actual compatibility and certificate policy.
| Check | Clear condition | Review condition |
|---|---|---|
| Protocol | Exactly TLS 1.3 | Any other negotiated version |
| Cipher name | No legacy token is found | Name contains RC4, 3DES, DES, MD5, NULL, or EXPORT |
| Certificate lifetime | More than 30 whole days remain | 0 to 30 days remain, or the value is negative |
| Trace-environment trust | Certificate path is authorized | Authorization fails |
| Chain shape | More than one certificate is returned | Leaf certificate only |
| Name evidence | At least one subject alternative name is returned | No subject alternative names are returned |
| Transcript | Output is complete | Output was truncated |
One or more flags changes Overall status from clear to review. The certificate label is Expired for d < 0, Renew soon for 0 ≤ d ≤ 30, and Current for d > 30. Timing values retain millisecond precision returned by the probe.
Privacy Notes:
A live trace cannot stay entirely in the browser because another machine must make the connection. The remote trace service receives the target host, port, optional SNI name, detail choice, and timeout, then connects from its own network.
- Do not submit private service names or sensitive internal addresses unless a remote probe is appropriate for that environment.
- The response is marked not to be cached, but the result still contains endpoint, certificate, address, and timing evidence that may be sensitive in an incident record.
- The probe does not send a client certificate, custom trust store, authentication token, or application request, so it cannot reproduce mutual TLS or authenticated application behavior.
Worked Examples:
Tracing a shared listener by address
A service resolves through several addresses, so an operator enters one IP literal and port 443 but sets SNI override to the public service name. The returned certificate names and fingerprint now describe that virtual host rather than the listener's default certificate. The operator still repeats the check from the affected client because the remote route and trust store differ.
References:
- RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3, IETF, July 2026.
- RFC 6066: Transport Layer Security Extensions, IETF, January 2011.
- RFC 7301: TLS Application-Layer Protocol Negotiation Extension, IETF, July 2014.
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate Profile, IETF, May 2008.
- How to debug TLS handshake with cURL, Simplified Guide.