Whether a certificate is valid is only one part of a server's TLS configuration. Two servers can both present perfectly valid certificates while negotiating very different connections underneath — one accepting only modern protocols with strong ciphers, the other still willing to fall back to a decade-old protocol version if a client asks for it. TLS Configuration checks that negotiation directly: which protocol versions a server accepts, what it picks by default, and how the handshake itself behaves.
Protocol Versions
TLS has gone through several versions, and a server can usually be configured to accept more than one:
- TLS 1.3 — the current version. Faster handshake, and it removed the weak cipher options earlier versions allowed. A server that supports it and prefers it is in good shape.
- TLS 1.2 — still widely used and still considered secure when configured with modern ciphers. Most of the web runs on a mix of 1.3 and 1.2.
- TLS 1.1 and TLS 1.0 — formally deprecated since 2021 (RFC 8996). Browsers stopped supporting them years ago. A server that still accepts one of these isn't necessarily under active attack, but it's carrying configuration that serves no real client anymore and only widens what an attacker downgrading a connection could target.
A server rejecting TLS 1.1 or TLS 1.0 is the expected, healthy outcome — not a failure. The tool reports each protocol as supported, not supported, or, where the check itself couldn't be completed cleanly, unable to test — that third state exists specifically so an inconclusive result is never reported as a false pass or a false fail.
Cipher Suite and Negotiated Version
Once a connection is open, the client and server agree on exactly one protocol version and one cipher suite for that session — the cipher suite is the specific combination of algorithms used for key exchange, encryption, and integrity checking. This tool connects the way a normal browser would (no forced version) and reports what the server actually chose, which is a more useful signal than the full list of what it's merely capable of.
ALPN, HTTP/2, and SNI
- ALPN (Application-Layer Protocol Negotiation) is negotiated during the TLS handshake itself and determines whether the connection proceeds as HTTP/2 (
h2) or falls back to HTTP/1.1 — before a single HTTP request is sent. - SNI (Server Name Indication) lets a client tell the server which hostname it's requesting during the handshake, before the certificate is even selected. This is what allows one IP address to serve TLS certificates for many different domains. A server that requires SNI will fail the handshake entirely if it's omitted.
Certificate Fields Shown Here
This tool shows enough of the certificate — subject, issuer, expiry, hostname match, chain status — to tell whether it's part of a healthy configuration, but it isn't meant to replace a dedicated certificate inspection. For the full breakdown, use the SSL Certificate Checker.
Connection Timing
Where it can be measured reliably, the tool reports TCP connection time separately from TLS handshake time — the handshake happens after the TCP connection is already open, and slow negotiation (an overloaded server, an unusually expensive cipher, a distant OCSP check) shows up specifically in that second number rather than the first. This is a measurement of that one connection at that one moment from NetSH's server, not a general latency benchmark.
Frequently Asked Questions
My server doesn't support TLS 1.0 or 1.1 — is that a problem?
No — that's the expected, secure configuration. Both were formally deprecated in 2021 and no current browser will use them anyway. Not supporting them is correct, not a gap.
What does "unable to test" mean for a protocol?
It means the check couldn't reach a clean conclusion — for example, the testing server's own TLS stack may not be able to attempt that specific old protocol version at all, independent of whatever the target server would have done. That's reported honestly as inconclusive rather than guessed at as a pass or fail.
How is this different from the SSL Certificate Checker?
The SSL Certificate Checker answers whether the certificate itself is valid — issuer, expiry, hostname coverage. This tool answers a different question: what the server's actual TLS negotiation looks like, including protocol versions accepted, the cipher and ALPN it picks, SNI behavior, and handshake timing.
Why does SNI matter?
Most hosting today puts many HTTPS domains behind one IP address, and SNI is what lets the server know which certificate to present before the handshake completes. A server that requires SNI and doesn't get it will fail the connection outright — which is normal, not a misconfiguration.
Check a hostname's TLS negotiation with the TLS Configuration tool.