{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
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 }}
Optional exact-version attempts use one resolved address and the same overall budget. TLS 1.0/1.1 may be blocked by the probe runtime.
{{ protocol_sweep ? 'On · test TLS 1.0–1.3' : 'Off · single handshake' }}
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.
SignalStatusEvidenceNext checkCopy
{{ row.signal }}{{ row.status }}{{ row.evidence }}{{ row.nextCheck }}

Protocol sweep unavailable: the service returned only single-handshake evidence. No per-version support conclusion is available.

No complete handshake phase timeline was captured.

FieldValueMeaningCopy
{{ row.label }}{{ row.value }}{{ row.detail }}
 
{{ transcriptText }}
RequestedOutcomeObserved evidenceCopy
{{ row.label }}{{ row.status }}
{{ row.detail }}
Observed: {{ row.negotiated_protocol || 'None' }} · {{ formatDuration(row.duration_ms) }}
{{ row.cipher }} · ALPN: {{ row.alpn || 'Not negotiated' }} · Certificate: {{ row.authorized ? 'Authorized' : 'Not authorized' }}

Exact-version attempts against {{ protocolSweep.ip }}. Node {{ protocolSweep.runtime.node }} / OpenSSL {{ protocolSweep.runtime.openssl }}; up to 1.2 seconds per version within the shared invocation budget. Failed attempts do not prove universal server non-support. TLS 1.0/1.1 are deprecated and may be limited by runtime policy.

Similar tools

An HTTPS connection can fail before the website receives a request. A certificate renewal, a change to a shared server, or a stricter client can interrupt the TLS handshake that establishes the protected connection. Transport Layer Security (TLS) lets the client and server agree on a protocol version and cryptographic settings, establish shared encryption keys, and authenticate the server when its certificate can be verified.

The protocol version, cipher suite, and certificate describe different aspects of encryption and identity.

Protocol version
The TLS rules used for this connection, such as TLS 1.2 or TLS 1.3. The selected version depends on what both participants support and permit.
Cipher suite
The selected combination of cryptographic algorithms. Its meaning depends on the TLS version. A cipher name does not establish which certificate was presented or whether its identity was trusted.
Certificate identity and trust
A certificate binds a public key to identity information. Trust requires an acceptable certification path and other checks, including validity and the intended service name. A recognizable issuer name alone does not establish trust.

Completing encryption and accepting a server's identity are separate judgments. A diagnostic connection may deliberately continue when certificate verification fails so that an expired, self-signed, incorrectly named, or incomplete certificate chain can be inspected. That makes the evidence useful for troubleshooting; it does not make the connection suitable for sending passwords. The certificate's subject alternative names (SANs) describe the names or addresses it covers, while the client's trusted certificate authorities determine which issuers it accepts.

Shared hosting adds another distinction. A hostname can resolve to an address that serves many domains. Server Name Indication (SNI) sends the requested DNS name during the handshake so the server can choose the appropriate certificate and configuration. Connecting to the same address without that name can return a default site's certificate. Supplying SNI selects a name to request; certificate verification must still establish whether the returned identity is acceptable.

Application-Layer Protocol Negotiation (ALPN) makes a different choice within the TLS connection. It can select an application protocol such as HTTP/2 or HTTP/1.1. ALPN does not choose the TLS version or certify that a website will respond correctly. Encryption can complete without an ALPN selection.

For a direct HTTPS connection over TCP, setup normally includes a Domain Name System (DNS) lookup, a Transmission Control Protocol (TCP) connection, and TLS negotiation. DNS finds an address, TCP reaches the listener at that address and port, and TLS establishes the protected session. Separating these durations helps distinguish a slow name lookup from connection delay or negotiation delay. None of those measurements includes downloading a page or waiting for the application to produce its response.

One negotiated version cannot reveal every version a server accepts. A successful TLS 1.3 connection leaves open whether a separately constrained TLS 1.2 connection would also work. Local cryptographic restrictions, incompatible signature algorithms, network interruptions, and deadlines can make failed attempts inconclusive. TLS 1.0 and TLS 1.1 are deprecated. Detecting interoperability with them is a maintenance check, not a reason to enable them.

A remote probe observes a connection from its own network and trust environment to one chosen resolved address at a particular time. DNS answers, routing, server load, and distributed hosting can make that observation differ from a browser's connection. Such evidence can narrow a fault after a certificate or listener change, but it cannot represent every address, client, or Internet location, or certify overall security or compliance.

How to Use This Tool:

Start with a public service you are authorized to check. The initial settings use port 443, summary detail, automatic hostname-based SNI, a 9-second requested timeout, and no protocol sweep. Opening the page or restoring its settings does not start a probe.

  1. Enter a hostname, HTTP or HTTPS URL, or public IP address in Host or URL. Use Port for the TLS listener, from 1 through 65535. An embedded listener port such as api.example.com:8443 takes precedence; bracket an IPv6 address when appending a port. A URL supplies connection information, not a page to fetch.
  2. Set SNI override in Advanced when a direct IP connection or shared listener needs a particular DNS name. Leave it blank to use a hostname target automatically; a bare IP target sends no SNI by default.
  3. Choose Trace detail for the evidence you need to read. The default summary and Summary (compact) contain the same core connection facts. Verbose (handshake + chain) adds certificate-chain text, and Verbose (full details) also includes the structured connection summary. These choices change the presentation, not which TLS versions are tested.
  4. Enable Protocol sweep if you need separate exact-version observations for TLS 1.0, 1.1, 1.2, and 1.3. Leaving it off requests only the normal handshake, which negotiates a version automatically. The optional sweep follows that initial attempt and remains separate from its certificate and timing evidence.
  5. Select Run trace, then check Trace diagnosis for the handshake and certificate findings. If the initial handshake fails but sweep evidence is available, the version observations remain accessible.
    The Timeout control in Advanced accepts 500 milliseconds to 20 seconds. The shared service deadline can stop the work sooner, so increasing this value does not guarantee more time for every sweep attempt.
    If validation blocks the run, remove credentials or spaces from the target and check the host, port, and advanced values. For a connection or service error, correct any known listener issue and select Retry trace. A service failure does not establish that a TLS version is unsupported.

Interpreting Results:

Read Certificate verification alongside the intended hostname and certificate dates. Authorized records acceptance by the remote probe's verification environment. SAN present only means that name entries were returned; it is not a separate hostname-match verdict. If verification is Not authorized, inspect the names, dates, and issuer sequence and repeat the check with the affected client. The certificate failure message is general, so it cannot identify the precise cause.

The Review flags count is an operational checklist for the initial handshake. It is not a security grade, and a clear result does not establish complete cipher coverage or universal trust. The exact seven conditions appear below. Sweep outcomes do not change that count.

For a returned Protocol sweep, distinguish an exact success from an unsuccessful or unperformed test. The observed protocol must match the requested version before the result can be called negotiated.

Outcome What the observation supports
Negotiated The requested version completed on this connection. Its cipher, ALPN selection, and certificate authorization are reported separately; negotiation alone does not establish trusted identity.
Peer rejected The peer returned a protocol-version or handshake alert. Read the accompanying reason. A handshake alert can involve cipher, signature, or policy compatibility rather than absence of that protocol version.
Runtime limited The probe's TLS software or cryptographic policy could not complete the attempt. This is especially relevant to TLS 1.0 and TLS 1.1 and leaves the server's compatibility unresolved.
Timed out The attempt reached its own limit or the shared deadline. No completed negotiation or conclusive rejection was captured.
Connection failed The connection failed or closed, or the observed version did not match the requested one. Investigate the listener and network path before drawing a protocol-support conclusion.
Not attempted Too little shared time remained to start this version. No connection attempt was made for that row.

Protocol sweep unavailable means the service returned only single-handshake evidence. That valid initial result is retained, but there are no per-version observations to interpret. A later manual run can request the sweep again; changing the detail selection cannot reconstruct data that was not returned.

When the initial handshake fails and a sweep is returned, use the sweep's observations independently. A successful version attempt does not supply the missing full certificate inspection or phase timeline for the initial connection. An overall service or network failure can instead leave no result to inspect.

Endpoint ledger holds the address, SNI, negotiated settings, certificate identity, and available chain. Its ALPN value h2 means HTTP/2, while http/1.1 means HTTP/1.1. Not negotiated is an absent selection, not an inferred HTTP/1.1 result. Phase timeline compares the three initial setup durations. A dominant phase suggests where to investigate, but repeated measurements from the affected network are needed before calling it a persistent performance problem.

Keep the Handshake transcript or combined JSON when recording a troubleshooting case. The diagnosis, endpoint, and sweep tables support CSV and DOCX, while the timing chart supports images and millisecond CSV data. Available sweep evidence also accompanies the transcript and JSON. The transcript is a readable connection summary, including the selected extra detail; it is not a packet capture or a record of every handshake message.

Technical Details:

A full certificate-based TLS 1.3 handshake begins with a client offering protocol versions and cryptographic options. The server selects compatible settings, contributes to key establishment, and supplies its certificate and proof of possession of the corresponding private key. Finished messages confirm the handshake's integrity. Certificate-path and service-name checks determine whether the identity is acceptable to that client.

In TLS 1.3, a cipher suite such as TLS_AES_256_GCM_SHA384 identifies authenticated encryption and the hash used in key derivation. Certificate signatures and key exchange are separate choices. The negotiated protocol is the connection's actual TLS version; version text associated with a cipher can instead describe the oldest protocol supporting that suite.

Rules for testing versions

Normal negotiation selects mutually permitted settings under the probe's ordinary TLS policy. Exact-version testing restricts the protocol choice for an additional connection, while retaining the other compatibility requirements.

  1. The target is resolved once, and every returned address is checked against the public-address restrictions. One permitted address is selected for the initial handshake and every optional version attempt. A hostname uses the remote resolver's view, which can include cached answers.
  2. The normal handshake runs first. When requested and time remains, the additional connections attempt TLS 1.3, TLS 1.2, TLS 1.1, and TLS 1.0 sequentially. Results are displayed in ascending order, from TLS 1.0 to TLS 1.3.
  3. Each additional connection sets both the minimum and maximum allowed versions to the requested version. Success requires the negotiated version to match. There is no fallback to another version and no automatic retry of a failed version.

All connections retain the chosen address, port, SNI, and the ALPN offer of h2 and http/1.1. There are at most five connections: the initial handshake and four exact-version attempts. This does not enumerate all resolved addresses or all ciphers.

The remote work has a shared deadline of at most 8 seconds, potentially shorter when less service time is available. DNS and the initial handshake consume that same budget. Each sweep attempt receives at most 1.2 seconds and may receive less; 200 milliseconds are reserved for completing the response, and a new attempt is skipped when less than 150 milliseconds of usable budget remains. The selected timeout can shorten the initial attempt but cannot extend the shared deadline.

Legacy attempts retain the existing cipher, signature, and cryptographic security restrictions. Requesting an exact old version does not lower global TLS security settings. The probe's TLS software version identifiers are not reported, so they cannot establish compatibility with a particular software release or every legacy server.

Certificate identity and chain evidence

The leaf certificate identifies the service at the start of the returned chain. Available evidence includes leaf and issuer common names, subject alternative names, validity start and end dates, and a SHA-256 fingerprint. Up to 200 SAN entries and 12 certificate-chain entries are collected, with the leaf first. A chain can stop earlier when further issuer evidence is unavailable.

Common names describe certificate subjects and issuers; current service-identity guidance relies on the appropriate SAN entries. A DNS wildcard such as *.example.com matches one label, such as api.example.com, rather than the bare domain or a deeper name such as a.b.example.com. An IP identity needs an appropriate IP-address SAN. SNI should carry a DNS name even when the connection target is an IP address.

The returned peer chain is not an independently reconstructed trust path. Issuer names and row counts cannot prove its signatures or completeness, and an absent root certificate alone does not prove a server error because root trust comes from the client's trust configuration. The authorization result applies to the probe's configured verification environment. When earlier trust checks fail, an independent hostname-check result may not be available.

A SHA-256 fingerprint is a digest of the certificate's encoded bytes. Matching fingerprints identify the same certificate for comparison; a changed fingerprint can accompany renewal or a different server certificate. A fingerprint supplies neither a trust decision nor a revocation result.

Formula Core

Connection timing

For a completed initial handshake, the three phase durations measure successive parts of setup from the remote probe's perspective.

Phase Measured interval
DNS lookup Resolving and checking the target's addresses before connection.
TCP connect Starting the connection to the selected address through TCP establishment.
TLS negotiation TCP establishment through completion of the TLS handshake.

The fallback total adds DNS duration D, TCP duration C, and TLS duration H, all in milliseconds.

Tsum = D+C+H

A finite returned total from 0 through 120,000 milliseconds takes precedence, even if it differs from the phase sum. When that total is absent, nonfinite, or outside the accepted range, the phase sum is used. Each individual phase must also be a finite duration in that range for a complete diagnostic result. These bounds check reported measurements; they do not extend the shorter service deadline.

Missing measurements prevent a complete phase timeline. Unavailable or null timing evidence from an incomplete connection must not be interpreted as an instantaneous phase. A measured zero is retained and can reflect millisecond clock resolution or the absence of a DNS lookup for a literal address. Displayed durations use at most two decimal places and switch to seconds at 1,000 milliseconds; the chart axis and phase CSV retain milliseconds.

The initial total ends with that connection's negotiation. It excludes the optional sweep, browser-to-service request time, page loading, and application response time. Sweep durations describe separate connection attempts, so they are not additional phases of the initial handshake.

Certificate days remaining

Remaining whole days are calculated from the leaf certificate's expiration time and the recorded observation time, rather than from the date when someone later opens the report.

d = ⌊ texpiry − tobserved 86400000 ⌋

Both timestamps use milliseconds, and 86,400,000 milliseconds is one 24-hour day. The floor operation rounds downward, including for negative values. The resulting integer d controls the lifetime label.

Lifetime status Whole days remaining
Expired Below 0
Renew soon 0 through 30, inclusive
Current Above 30

For example, 30 days and 12 hours remaining becomes 30 whole days and therefore Renew soon; 31 whole days becomes Current. At zero whole days the badge says Expires today, meaning less than 24 hours remain rather than a calendar-date comparison. Even one second after expiration rounds to −1 day, so the exact validity timestamp is more useful than the rounded age near that boundary.

Current describes only this expiration threshold. It does not establish that the certificate's validity start has passed, that its names match, or that its path is trusted. Certificate checks depend on the verification clock. Displayed date strings may use the probe's locale, while the calculation uses timestamps.

How review flags are counted

Each matching condition contributes one flag to the initial handshake's count, from 0 through 7. With no matching conditions, the summary reads Handshake evidence looks clear. One or more matches produce Handshake evidence needs review.

Condition adding one flag Interpretation limit
Negotiated protocol is not TLS 1.3 TLS 1.2 also triggers review. This alone does not establish an insecure connection or a vulnerability.
Cipher name contains RC4, 3DES, DES, MD5, NULL, or EXPORT The comparison ignores letter case and checks name fragments. It is a narrow heuristic, not a complete cryptographic assessment.
Certificate lifetime is Renew soon or Expired The threshold is 30 floored days or less. Expiration contributes one flag, not an additional flag on top of renewal.
Certificate verification is not authorized The probe's verification failed; the public message does not isolate every possible cause.
At most one chain certificate was returned Investigate missing intermediates or the available chain evidence. A short chain alone is not a complete trust verdict.
No SAN entries were returned The name evidence needs review. Having entries would still not prove a match to the intended hostname.
The transcript is marked truncated Some text may be missing. Long transcript content is capped at 320,000 characters before a truncation notice.

These conditions combine compatibility, certificate, and evidence-completeness checks. Their count is not a weighted severity score. They do not perform a revocation lookup, exhaustive cipher scan, or independent security certification.

Privacy and Scope:

The host, effective port, SNI, detail choice, timeout, and optional sweep selection are sent to the remote diagnostic service after a run is requested. That service connects to the target and returns the observed server information. Processing is not browser-local, and the target can observe the probe connections. No passwords, private keys, or client certificates are required.

  • Only permitted public addresses are probed. A hostname resolving to any blocked address is rejected, including mixed public and private answers. This is a single-service diagnostic, not permission for broad scanning.
  • The connection uses TLS immediately. It does not perform a plaintext STARTTLS upgrade, send an HTTP request, follow redirects, test HTTP/3 over QUIC, or supply a client certificate for mutual TLS.
  • URL settings can restore the target, port, SNI, detail, timeout, and sweep selection. Results and the selected result tab are not restored, and reopening the link does not run a probe. Shared links and browser history can expose those settings.
  • Reports can contain certificate names, addresses, fingerprints, and connection settings. Review that information before sharing it.

Worked Examples:

These are hypothetical troubleshooting cases, not live observations of the example names.

Modern versions succeed while legacy support remains unresolved

Suppose an authorized check of your service with Protocol sweep enabled produces an initial TLS 1.3 handshake, Negotiated for exact TLS 1.2 and TLS 1.3, and Runtime limited for TLS 1.0 and TLS 1.1. The two successful attempts establish interoperability with those versions at the selected address. The legacy results do not prove that the server has disabled them. Verify the listener's configured policy and use an appropriately controlled client test if that distinction matters; enabling deprecated protocols is not a remedy for an inconclusive probe.

A public IP returns the wrong virtual host's certificate

A direct connection to your service's public IP with blank SNI override can present the shared listener's default certificate. If its SAN entries cover a different site, enter the intended DNS name, such as api.example.com, as the override and run again with the same address and port. A different leaf fingerprint and the intended SAN entries would explain the certificate-selection difference. Check Certificate verification as well, because selecting the expected certificate does not by itself establish trust.

References: