0
Not checked
Run the checker to evaluate TLS security.
TLS Version Checker
Check supported TLS protocols, negotiated cipher suites, forward secrecy, certificate details, and transport security weaknesses.
Enter a public hostname to check supported TLS versions, cipher suites, and forward secrecy.
Best TLS Version
—
highest supported protocol
Forward Secrecy
—
ephemeral key exchange
Negotiated Cipher
—
default handshake result
Handshake Time
—
TLS negotiation duration
Certificate
—
trust and validity
Legacy TLS
—
TLS 1.0 / 1.1 support
Weak Ciphers
0
insecure or outdated suites
Server
—
resolved endpoint
🛡️ Supported TLS Versions
🔎 Security Findings
🧬 Supported Cipher Suites
📋 Connection Details
Hostname
—
Port
—
IP Address
—
ALPN Protocol
—
Key Exchange
—
Cipher Strength
—
Certificate Subject
—
Certificate Issuer
—
Certificate Expiry
—
💡 Recommended Improvements
📤 Scan Summary
🧾 Raw API Result
HOW IT WORKS
Real TCP+TLS Handshakes, Not a Simulation
Browsers can't choose an individual TLS protocol version, enumerate a server's cipher suites, or inspect handshake internals - so this checker's .NET backend opens its own raw TCP connections and performs real, controlled TLS handshakes: one to find the strongest protocol and cipher the server offers by default, then (optionally) one attempt per protocol version to see which of TLS 1.0 through 1.3 the server still accepts. The same SSRF protections used across our security tools apply here too - private, loopback, link-local and cloud-metadata addresses are always rejected before any connection is attempted. Cipher-suite enumeration is a best effort: .NET can only pin individual cipher suites for testing on Linux, and it doesn't implement long-retired suites like RC4, DES or NULL at all, so those can never show up as "supported" through this tool even when present - a genuine platform limitation, not a false negative. Because a full scan can open dozens of handshakes, checks are both rate-limited and capped in how many can run at once.
TLS Version Checker FAQ
Why does forward secrecy matter?
With an ephemeral (ECDHE/DHE) key exchange, each session uses a temporary key that's discarded afterward, so recording encrypted traffic today and later stealing the server's private key still wouldn't let anyone decrypt it. Static RSA key exchange doesn't have this protection.
Why can't this tool find every cipher suite a server supports?
Testing an individual cipher requires the client to offer only that one suite and see if the server accepts it - .NET only supports doing this on Linux, and it never implements several historic suites (RC4, DES, NULL, EXPORT, anonymous) at all, so those can't be probed through this tool regardless of platform.
Can I check an internal or private server?
No. Hostnames that resolve to localhost, private IP ranges, link-local addresses or cloud metadata endpoints are rejected before any connection is attempted, on any port.
What does "Use SNI" turning off actually test?
Disabling SNI connects using the resolved IP address instead of the hostname, so the server can't route the connection to a per-hostname certificate the way most modern reverse proxies do - useful for checking a server's default/fallback certificate and TLS behavior.
Why does a scan sometimes take longer than other tools?
A full scan can open a couple of dozen separate TCP and TLS handshakes (one per protocol version, plus one per candidate cipher suite), each with its own timeout - that's inherently slower than the single-request tools elsewhere on this site.