{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
{{ summaryAnnouncement }}
TLS endpoint and listener inputs
Try example.com, https://example.com, api.example.com:8443, or [2001:db8::1]:443.
443 is the standard HTTPS listener; valid ports run from 1 through 65535.
{{ runMessage }}
Start with the summary; use verbose modes when a certificate or low-level handoff needs more context.
The neutral blank default uses the target hostname when the target is not an IP literal.
{{ formatDuration(timeout_ms) }}
Raise the budget for distant or intermittently slow endpoints; the neutral default is 9 seconds.
{{ tableExportStatus }}
SignalStatusEvidenceNext checkCopy
{{ row.signal }}{{ row.status }}{{ row.evidence }}{{ row.nextCheck }}
{{ jsonExportAnnouncement }}
{{ chartExportStatus }}
{{ tableExportStatus }}
FieldValueMeaningCopy
{{ row.label }}{{ row.value }}{{ row.detail }}
{{ transcriptAnnouncement }}
{{ 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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

TLS trace stages and the evidence each stage can provide
StageObserved evidenceWhat a failure narrows
DNS lookupResolved IPv4 or IPv6 address and elapsed millisecondsName resolution, resolver reachability, or an invalid hostname
TCP connectConnection time to the selected address and portRouting, firewall, listener, or transport reachability
TLS negotiationProtocol, cipher, ALPN, SNI, certificate, trust result, and elapsed millisecondsTLS policy, certificate presentation, trust, or negotiation failure
Evidence projectionCertificate lifetime, chain and name counts, review flags, and readable transcriptWhich 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.

ttotal = { treportedwhen 0 to 120000 ms and finite tDNS+tTCP+tTLSotherwise }

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.

d= TexpiryTobserved 86400000

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.

Rules that produce TLS review flags
CheckClear conditionReview condition
ProtocolExactly TLS 1.3Any other negotiated version
Cipher nameNo legacy token is foundName contains RC4, 3DES, DES, MD5, NULL, or EXPORT
Certificate lifetimeMore than 30 whole days remain0 to 30 days remain, or the value is negative
Trace-environment trustCertificate path is authorizedAuthorization fails
Chain shapeMore than one certificate is returnedLeaf certificate only
Name evidenceAt least one subject alternative name is returnedNo subject alternative names are returned
TranscriptOutput is completeOutput 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.