{{ outputText }}
| Field | Value | Copy |
|---|---|---|
| {{ r.k }} | {{ r.v }} | |
| No summary. | ||
TLS is the negotiation that turns a plain TCP connection into an encrypted session. Before a browser, API client, mail server, or another networked service can exchange protected data, the client and server have to agree on a protocol version, a cipher, and the certificate material that identifies the server.
This tool captures that opening exchange for a real endpoint. You supply a host and port, the tool performs a live lookup and handshake through its helper, and the result comes back as a readable summary, a text transcript, and structured JSON that can be copied or downloaded for comparison.
That makes it useful when the problem is not simply "up" or "down." A certificate renewal may have reached one edge node but not another. A name may work while the direct IP shows a different certificate. A service on port 8443 may negotiate differently from the same host on 443. In all of those cases, a clean snapshot of what the endpoint actually presented is more useful than a guess.
The main caution is trust. A successful trace here proves that the helper negotiated TLS and inspected the peer certificate. It does not prove that a browser or another strict client would trust that certificate for the target name, because the helper deliberately allows inspection of whatever the peer presents.
This is also a live network check rather than a local parser. The host, port, optional SNI value, mode, and timeout leave the browser, the helper resolves and contacts the target, and the result reflects what that network path saw at that moment.
Start with the smallest question that can move the investigation forward. If you only need to know what certificate and negotiated session a host is presenting, keep the default summary mode and look at the summary table before reading the longer transcript. The summary already tells you the resolved IP, the effective SNI value, the negotiated protocol, the cipher, ALPN, issuer and subject common names, validity dates, fingerprint, and subject alternative names when those fields are available.
Read the identity fields together rather than one at a time. A modern protocol and a strong-looking cipher do not rescue a hostname mismatch, an expired certificate, or a certificate issued for the wrong service. The quickest sanity check is usually the combination of target host, SNI, peer common name, subject alternative names, issuer, and validity window.
SNI matters whenever the target is shared. If you connect to an IP address directly, the helper sends no SNI unless you provide one, so a shared address can return the default certificate instead of the one you expected. The override field exists for that case and for situations where a name-based route is suspected to be serving the wrong certificate.
When the run fails, do not skip straight to certificate theory. A DNS failure means the name never resolved. A connect error means the TLS session did not reach the secure stage. A timeout means the connection stalled before completion. Those outcomes usually point to resolution, routing, filtering, or listener behavior before they point to certificate content.
| Observed result | What it tells you | Best next check |
|---|---|---|
dns_failed |
The helper could not resolve the target name to an address. | Verify the hostname and its DNS records before looking at TLS details. |
connect_error |
The TCP or TLS connection failed before certificate details could be extracted. | Check reachability, port exposure, and whether the service is actually speaking TLS. |
timeout |
The connection did not complete inside the effective timeout window. | Look for routing problems, filtering, overloaded listeners, or a too-short timeout. |
| Summary present but names look wrong | The handshake succeeded, but the endpoint likely presented a different virtual host or certificate. | Compare the target with SNI, then rerun with an explicit SNI value if needed. |
The client accepts a plain hostname, a full URL, or a host-and-port string, including bracketed IPv6 with a port. It normalizes the host before the request is sent, pulls a port out of pasted input when one is present, and rejects malformed values early. On the helper side, the port is clamped to the valid 1 to 65535 range, the timeout is clamped to 0 to 20000 milliseconds, and localhost is rejected.
Resolution happens before the TLS connection. If the helper cannot turn the host into an IP address, the run stops with a DNS error and there is no certificate summary to inspect. If the helper does resolve the host, it chooses an SNI value deterministically: an explicit override wins, a hostname defaults to itself, and a raw IP sends no SNI unless you provide one.
Once the socket reaches the secure stage, the helper records the negotiated protocol, cipher, and ALPN value, then parses the presented X.509 certificate. That is how the tool derives the peer common name, issuer common name, validity dates, fingerprint, and subject alternative names. It also walks the peer certificate chain from the leaf upward and records up to 12 certificates in leaf-first order.
The mode selector changes the text rendering, not the network work. In the current implementation, both summary modes return the same compact text block. The handshake-and-chain mode adds a readable certificate-chain section, and the full-details mode appends the raw summary JSON. Output is capped at 320000 characters, so very large traces are flagged as truncated rather than allowed to grow without bound.
The helper response is marked no-store, which signals that the returned trace should not be cached. The package does not advertise server-side retention beyond the request itself, but it also does not claim a local-only workflow, so treat target details as information that leaves the browser for the duration of the trace.
| Mode | Returned text shape | Practical use |
|---|---|---|
| Summary (Node TLS) | Compact summary text | Fast first pass when you mainly need protocol and certificate facts. |
| Summary (compact) | The same compact summary path as the default mode | Short evidence block when you do not need extra chain detail. |
| Verbose (handshake + chain) | Summary plus a leaf-first certificate-chain listing | Issuer and chain review when a rollover or intermediate mismatch is suspected. |
| Verbose (full details) | Verbose text plus the raw summary JSON | Deeper comparison, record keeping, or handoff to another operator. |
| Field | Meaning in this tool | Why it matters |
|---|---|---|
| Resolved IP | The address returned by DNS before the TLS connection starts. | Helps distinguish DNS routing issues from certificate or protocol issues. |
| SNI | The effective server name sent during the handshake. | Critical when a shared IP hosts multiple certificates. |
| Protocol and Cipher | The negotiated TLS version and cipher reported by the socket. | Shows what session the helper actually established. |
| Peer CN, SAN, Issuer CN | Identity and issuing-certificate details extracted from the presented certificate. | Lets you check whether the endpoint is presenting the expected identity chain. |
| Valid From and Valid To | The certificate validity window as rendered by the helper. | Useful for spotting certificates that are expired or not yet valid. |
| SHA-256 Fingerprint | A digest of the certificate bytes. | Useful when you need to confirm that two endpoints are serving the exact same certificate. |
dns_failed, connect_error, or timeout, stay with the network path until that problem is explained.A filled summary means the helper reached a negotiated TLS session and extracted certificate data from the peer. That is already useful evidence, but it is not the same thing as a complete security verdict. The question to ask next is not "Did TLS work?" but "Did this endpoint present the identity and session details I expected?"
Date checks are usually the fastest second pass. If the certificate is already past its validity end date, or if it is not yet within its validity window, the handshake transcript becomes proof of a timing problem rather than proof of readiness. Those dates are especially helpful during certificate rollovers and environment cutovers.
Name checks come next. A mismatch between the target name and the subject alternative names is often more important than the protocol version. If the names are wrong while the rest of the summary looks healthy, the common causes are missing SNI, the wrong virtual host behind a shared address, or a deployment that reached the wrong tier first.
Example 1: checking a hostname after a renewal. Suppose you trace https://example.com:443/ with the default mode. The parser strips the scheme, keeps the host and port, and the summary returns a protocol, cipher, issuer, subject names, and a new validity end date. That is the fastest way to confirm that the endpoint is at least presenting the renewed certificate on that path.
Example 2: checking a shared IP. Suppose a service is known to live behind 203.0.113.10:443. A run with no SNI may return a certificate for the default virtual host or fail to show the name you expected. A second run with the same IP and an explicit SNI value can reveal whether the real issue is certificate selection on a shared listener rather than the certificate file itself.
Example 3: stopping at DNS before touching TLS. If you trace nonexistent.invalid, the run should stop at name resolution and report dns_failed. That outcome is valuable because it keeps the investigation honest: there is no point debating protocol versions, chains, or subject names until the target resolves.
No. The helper is intentionally able to inspect certificates even when they would not pass a strict trust check. Treat the trace as evidence of what the peer presented, not as a final trust decision.
Yes. The input parser accepts a plain hostname, a URL, or a host-and-port string, and it can extract a port from bracketed IPv6 input as well.
Use it when a shared address or listener may return a different certificate depending on the server name sent during the handshake. It is especially useful when testing direct IP paths.
No. The helper sanitizes host input and rejects localhost, so this tool is aimed at reachable external or network-visible targets rather than loopback testing.
Because the current implementation renders both summary labels through the same compact text path. The longer modes are the ones that add extra chain detail or raw JSON.
It means the returned text hit the tool's output cap. The underlying summary object is still present, but the transcript was shortened to keep the response manageable.