Inputs
Example
example.com:443 -> separate exact-version probe outcomes, verified certificate identity, negotiated cipher/ALPN evidence, and HTTPS-only HSTS evidence.
TLS Configuration Checker
Run separate exact-version TLS probes and summarize verified certificate identity, negotiated cipher/ALPN evidence, and HTTPS-only HSTS evidence.
Use it for a compact TLS posture check without running a full external SSL Labs style scan.
A first look at what a server actually offers
When TLS breaks, it rarely breaks loudly. A certificate renewed for the wrong hostname, a load balancer that still accepts TLS 1.0, or an h2 offer that negotiates only HTTP/1.1 may surface later as browser warnings, failed API clients, performance investigations, or an auditor's finding.
This checker runs separate exact-version probes for TLS 1.0, 1.1, 1.2, and 1.3, plus a distinct peer- and hostname-verifying default handshake. It reports supported, rejected, locally unsupported, connection-failed, and otherwise inconclusive outcomes separately. The negotiated version, cipher, certificate SAN match, and ALPN describe only their individual handshakes; no full cipher or ALPN enumeration is claimed. HSTS and HTTP/2/3 evidence are evaluated only for a DNS-name HTTPS endpoint on port 443.
Reading the probe like an incident responder
Use the DNS hostname for ordinary virtual-host testing because the checker sends SNI for DNS names. A public IP literal is accepted only for explicit IP-endpoint checks and is matched against iPAddress SAN entries without SNI; it may therefore expose a default virtual host rather than the certificate users receive by name.
Read the results as a set. A successful exact TLS 1.0 probe points at appliance or load-balancer defaults. A SAN mismatch after a migration usually means the new frontend presents the wrong certificate. A failed h2 probe proves only that h2 was not negotiated for that offered protocol and handshake; it does not enumerate every ALPN combination. Missing HSTS on a DNS-name HTTPS endpoint is a separate HTTP policy gap, not a property of the TLS handshake.
Where a quick probe ends and a real audit begins
The same-origin endpoint restricts targets to public DNS names or globally routable IP literals and common implicit-TLS/HTTPS ports. It runs four exact-version capability handshakes plus separate presented and peer/hostname-verified default handshakes from one vantage point. It does not enumerate ciphers or all ALPN offers, check revocation, validate against every trust store, or provide multi-vantage coverage. A clean result is bounded evidence, not a compliance statement.
Frequently asked questions
The browser shows a different certificate than this probe. Why?
Usually SNI or routing: the server picks certificates per requested name, and a CDN may route this probe to a different edge than your browser. Both observations are real; the difference tells you certificate selection depends on the path, which is worth knowing.
Is TLS 1.0 or 1.1 support still a real problem?
Yes, as a policy and audit matter. Modern clients will not use them, but accepting them signals unmaintained configuration, fails common compliance baselines, and leaves the door open for downgrade tricks against legacy clients.
Does the cipher shown represent everything the server supports?
No. It is only the cipher negotiated by the reported default handshake. The checker does not enumerate the server's cipher suites, so an unobserved weak cipher is neither proved enabled nor proved disabled.
What does a missing ALPN value prove?
It proves only that the reported handshake did not negotiate an application protocol. The checker offers h2 separately under TLS 1.2 and TLS 1.3 on HTTPS port 443; it does not claim to enumerate every protocol the server could negotiate with other offers or clients.
Should every site send HSTS?
Every production HTTPS site should send a sensible max-age. Be deliberate with includeSubDomains and especially with preload: preloading is close to irreversible and has broken subdomains that quietly still needed HTTP.
Can I check an internal host with this?
No. The live endpoint only accepts public DNS names or globally routable IP literals. For internal endpoints, run a local probe from a machine that can reach them; the same reading order applies.