{{ summaryHeading }}
{{ summaryFigureText }}
{{ summarySecondaryLine }}
{{ handshakeBadgeText }} {{ hostDisplay }} {{ summaryCipher }} ALPN {{ summaryAlpn }} {{ certificateBadgeText }} Truncated output
TLS handshake trace inputs
Examples: example.com, https://example.com, api.example.com:8443, or [2001:db8::1]:443.
Enter 1-65535; 443 is the normal HTTPS/TLS default.
Use Summary for routine checks; verbose modes include chain detail and a raw summary block.
Leave blank to use the host name; enter a DNS name when testing an IP or CDN edge.
Enter 500-20000 ms in 500 ms steps; raise it for slow remote endpoints.
ms
Signal Status Evidence Next check Copy
{{ row.signal }} {{ row.status }} {{ row.evidence }} {{ row.next }}
No findings returned.
Field Value Copy
{{ row.field }} {{ row.value }}
No endpoint facts returned.
Position Subject CN Issuer CN Valid From Valid To SHA-256 Fingerprint Copy
{{ row.position }} {{ row.subject }} {{ row.issuer }} {{ row.validFrom }} {{ row.validTo }} {{ row.fingerprint }}
No certificate chain returned.
Timing data is unavailable for this trace response.
{{ outputText }}

                
Customize
Advanced
:

Many HTTPS outages begin before an application has a chance to respond. A port can be reachable while the endpoint serves the wrong certificate, negotiates a legacy protocol, omits an intermediate certificate, or spends most of the delay inside encrypted setup. A TLS handshake trace narrows the investigation to the short exchange that decides whether a protected session can exist.

The sequence starts after DNS resolution and a TCP connection. The client sends a ClientHello with supported TLS capabilities and, for most name-based services, Server Name Indication (SNI). SNI is the hostname hint that lets a shared address or CDN edge select the right certificate. The server then chooses a TLS version, cipher suite, certificate evidence, and sometimes an application protocol through Application-Layer Protocol Negotiation (ALPN). Small changes to host, port, SNI, or route can therefore produce a different certificate or protocol result.

TLS trace stages from DNS lookup through TCP connect, TLS negotiation, and certificate evidence.

Certificate identity is usually the first practical check after the session negotiates. Modern clients rely on Subject Alternative Name (SAN) entries to decide whether a certificate covers the requested name. The common name may still appear in reports, but SAN coverage, validity dates, issuer continuity, and the client trust store matter more than the label on one certificate field.

Handshake evidence is especially useful when the failure is uneven. A renewed certificate can reach one edge node but not another. A direct IP test can show a default certificate because no SNI name was sent. Port 8443 can have a different listener, protocol policy, or certificate chain from port 443. Timing also matters: a slow result should point toward DNS lookup, TCP connect, or TLS negotiation instead of becoming a vague "site is slow" report.

  • Renewal checks: confirm that the served leaf certificate has the expected validity window and fingerprint after deployment.
  • Name-routing checks: compare SNI and non-SNI behavior when a shared address or CDN edge appears to serve the wrong certificate.
  • Protocol checks: verify whether the endpoint negotiates TLS 1.3, falls back to TLS 1.2, or fails before a protected session exists.
  • Performance checks: separate name resolution delay from connection setup and encrypted negotiation delay.

A trace is a snapshot from one network vantage point. It can show what the endpoint presented during that run, but it does not replace browser testing, production-client checks, revocation handling, or monitoring from the networks that matter to real users.

How to Use This Tool:

Start with a normal summary run, then increase the trace detail only when the first result points to a certificate, SNI, timing, or connection problem.

  1. Enter Host or URL. Hostnames, full URLs, host-and-port strings, and bracketed IPv6 values with ports are accepted. If the field reports an invalid hostname, remove paths, spaces, credentials, or unsupported characters.
  2. Use Port for nonstandard TLS listeners. A port included in Host or URL, such as api.example.com:8443, becomes the effective port for that run.
  3. Leave Trace detail on the default summary setting for a first pass. Choose Summary (compact) for shorter text, Verbose (handshake + chain) when the certificate chain matters, or Verbose (full details) when a fuller transcript is needed for handoff.
  4. Add SNI override when testing a direct IP address, CDN edge, or virtual host. Use the DNS name the server should see in ClientHello.
  5. Set Timeout between 500 ms and 20 s. Raise it for distant or intermittently slow endpoints before treating a timeout as a hard service failure.
  6. Press Run trace. If the request fails with DNS, timeout, connect, certificate, or TLS errors, fix that reachability or listener problem before judging certificate identity.
  7. Read Trace Findings first, then use Endpoint Facts, Certificate Chain, Handshake Phase Timeline, Handshake Transcript, and JSON for the evidence you need to share or compare.

For repeat checks, keep host, port, SNI, trace detail, and timeout the same. Changing any of those settings can change which listener, certificate, or failure mode appears.

Interpreting Results:

Begin with Handshake status. A negotiated session means the trace reached TLS and collected evidence. A DNS failure, timeout, connect error, missing certificate, or TLS error means the investigation is still at reachability or listener setup, not certificate interpretation.

Once the handshake succeeds, compare endpoint identity against what you expected. Protocol, Cipher suite, ALPN, SNI, Peer CN, SAN, Issuer CN, Valid To, Days Until Expiry, Certificate Verification, and Authorization Error each answer a different part of that question. The main false-confidence risk is treating a completed handshake as proof that every production client will trust the endpoint.

  • Negotiated session, wrong name: check SNI, SAN, and Peer CN. Wrong names usually point to virtual-host routing, CDN edge state, or a default certificate.
  • Correct name, bad dates: use Valid To and Days Until Expiry to decide whether renewal or deployment verification is the urgent step.
  • Not authorized: read Authorization Error and the Certificate Chain. The trace environment may not build the same trust path as every browser or server.
  • Slow connection setup: use Handshake Phase Timeline to see whether DNS lookup, TCP connect, or TLS negotiation consumed the time.
  • Truncated transcript: rely on Trace Findings, Endpoint Facts, and JSON before assuming the missing tail contained no useful evidence.

For high-risk changes, repeat the same trace and compare it with a browser, command-line client, or monitoring probe from the affected environment. Edge routing, DNS answers, local trust stores, middleboxes, and server load can all change the next run.

Technical Details:

TLS runs above TCP. A socket can be reachable while TLS still fails because the listener rejects the handshake, serves a certificate that does not match the requested name, cannot build a trusted chain, or takes too long to complete the encrypted setup. The ClientHello is the main client-side signal because it carries supported capabilities, the optional SNI hostname, and ALPN preferences.

Certificate evidence comes from X.509 material presented by the peer. The leaf certificate is the endpoint certificate; intermediates connect that leaf toward a trusted root when the client can build a valid path. The trace records presented names, issuer information, validity dates, SHA-256 fingerprint, and leaf-first chain rows so that identity, freshness, and chain shape can be checked separately.

The timing values are measurements from one run. DNS caches, resolver choice, anycast or CDN routing, firewall policy, server load, and network distance can move time between phases. A slow TLS phase is especially useful because it separates encrypted negotiation from name lookup and TCP reachability.

Trace Rule Path:

TLS handshake trace rule sequence
Stage Evidence collected Failure or caution
Target normalization Hostname or IP literal, effective port, and optional SNI value. Malformed targets are rejected before a network probe starts; a host-and-port target overrides the separate port field.
DNS lookup Resolved IP address and IP family when a hostname resolves. A DNS failure stops the trace before TCP or TLS evidence exists.
TCP connect Whether the selected address and port are reachable within the timeout. Connection errors point to routing, firewall, listener, or wrong-port problems before certificate review.
TLS negotiation Negotiated protocol, cipher, cipher version, ALPN result, and certificate verification status. A TLS error can happen before certificate fields can be parsed.
Certificate extraction Peer common name, issuer common name, SAN list, validity dates, SHA-256 fingerprint, and certificate chain rows. Presented certificate evidence is not the same as a final trust decision for every client.
Transcript formatting Summary text, optional chain text, optional fuller structured detail, and truncation status. Very large transcript text can be clipped; the structured result remains the better first evidence source.

Key Fields:

TLS trace outputs and interpretation fields
Output field Meaning Useful check
Protocol The TLS version negotiated for this session. TLS 1.3 is the modern target for many HTTPS services; TLS 1.2 may still be acceptable depending on policy and client support.
Cipher suite The cipher suite reported for the completed session. Review warnings for legacy names such as RC4, DES, 3DES, NULL, EXPORT, or MD5.
SNI The server-name hint sent during ClientHello. Use the expected DNS name when a shared IP address or virtual host presents the wrong certificate.
SAN Count and SAN The Subject Alternative Name entries from the leaf certificate. Confirm that the intended hostname appears in the certificate names.
Certificate Verification Whether the trace environment considered the presented certificate path authorized. Investigate Authorization Error and test with the affected client before closing a trust issue.
Days Until Expiry Days between the trace time and the leaf certificate Not After date. Treat expired certificates and certificates with 30 days or less remaining as lifecycle risks to verify.
Handshake Phase Timeline Measured DNS lookup, TCP connect, TLS negotiation, and total probe timing. Use phase timing to decide whether the next investigation belongs with DNS, network reachability, or TLS negotiation.

Certificate verification is non-blocking so certificate details can still be collected when a chain is expired, incomplete, self-signed, or otherwise not trusted by the trace environment. That makes the evidence useful for diagnosis, but it also means Certificate Verification and Authorization Error must be read directly instead of inferring trust from the presence of a transcript.

Privacy Notes:

This diagnostic is server-assisted because browsers cannot directly open arbitrary TLS sockets and inspect the peer certificate chain for any host a user types.

  • The host or URL, effective port, SNI override, trace detail, and timeout are sent to the trace service for the current run.
  • The probe resolves and connects from the trace service network, so results can differ from a laptop, private server, office network, or customer location.
  • A loopback or private address can describe the trace service environment rather than the machine you are using. Avoid private hostnames, sensitive internal addresses, and targets that should not be contacted externally.
  • The diagnostic does not need passwords, client certificates, private keys, cookies, or bearer tokens. Do not paste them into the host field.

Worked Examples:

Certificate Renewal Verification

After replacing a certificate for www.example.com on port 443, a summary trace shows Handshake status as Negotiated, Protocol as TLSv1.3, Certificate validity as Valid, Days Until Expiry as 82 day(s), and a new SHA-256 Fingerprint. The renewal is visible to this trace path, but SAN still needs to include the production hostname before the result is considered healthy.

Shared Address With Missing SNI

A direct trace to 203.0.113.10:443 returns a negotiated session, but Name evidence points at a default certificate and SNI is Omitted. Repeating the run with SNI override set to api.example.com changes SNI to Sent and returns the expected SAN entry. That points to name-based certificate selection rather than a cipher problem.

Slow Encrypted Setup

A trace of api.example.com:443 completes with DNS lookup around 35 ms, TCP connect around 80 ms, and TLS negotiation above 1200 ms. Phase timing marks the run as Slow TLS, so the next check is server load, middleboxes, certificate handling, or a TLS feature that delays negotiation.

Failure Before Certificate Review

A misspelled hostname returns a DNS failure and no rows in Certificate Chain. That result prevents a misleading certificate investigation; the hostname must resolve before TLS protocol, cipher, SAN, or expiry evidence can exist.

FAQ:

Does a negotiated handshake mean the certificate is trusted?

No. A negotiated handshake means TLS completed and evidence was collected. Check Certificate Verification, Authorization Error, SAN, validity dates, and a real client before treating the endpoint as trusted.

Can I paste a full URL or a host with a port?

Yes. Host or URL accepts hostnames, full URLs, host-and-port strings, and bracketed IPv6 values with ports. Paths are ignored for the TLS trace because the handshake happens before an HTTP path is requested.

When should I use SNI override?

Use SNI override when testing a direct IP address, shared listener, CDN edge, or alternate virtual host. Enter the DNS name that should select the expected certificate.

Why might ALPN be blank?

Some TLS services do not negotiate an application protocol through ALPN, and non-HTTP services may not need one. If ALPN is blank for an HTTPS service where HTTP/2 is expected, compare the listener configuration with a browser or command-line client.

What does Not authorized mean?

Not authorized means the trace environment did not accept the certificate path as trusted. It can be caused by an expired leaf, a missing intermediate, a self-signed certificate, a name mismatch, or a trust-store difference.

Why should I avoid localhost or private targets?

The probe runs from the trace service, not from your browser. A loopback address refers to that service environment, and private addresses may fail or describe a different network than the one you intended to test.

What does truncated output mean?

It means the transcript text reached the response limit and was shortened. Use Trace Findings, Endpoint Facts, and JSON for the structured evidence before rerunning with a shorter trace detail setting.

Glossary:

TLS handshake
The opening negotiation that establishes encrypted session parameters and certificate evidence.
ClientHello
The first TLS handshake message from the client, including supported capabilities and optional name hints.
SNI
Server Name Indication, the hostname hint that lets shared listeners choose the correct certificate.
ALPN
Application-Layer Protocol Negotiation, the TLS extension used to agree on the application protocol for the encrypted session.
Subject Alternative Name
The certificate extension that lists DNS names or IP addresses covered by the leaf certificate.
Leaf certificate
The endpoint certificate presented first, before intermediate certificates in the chain.
Certificate chain
The ordered certificates a client uses to connect the leaf certificate to a trusted issuer.
Fingerprint
A digest of certificate bytes used to compare whether two traces saw the same certificate.