Our TLS Version Checker scans a server to determine which TLS protocol versions are supported. It tests TLS 1.0, 1.1, 1.2, and 1.3 and reports which are enabled. This is critical for security audits — legacy versions (TLS 1.0 and 1.1) are deprecated due to known vulnerabilities, while TLS 1.2 and 1.3 provide modern, secure encryption.
How to Use
1Enter the server domain or hostname to test.
2Click "Check" to scan supported TLS versions.
3Review which TLS versions are enabled.
4Disable legacy versions and ensure TLS 1.2/1.3 are active.
Use Cases
•Audit TLS version support for security compliance
•Detect deprecated TLS 1.0 and 1.1 on servers
•Verify TLS 1.3 is properly enabled
•Prepare for PCI DSS and industry compliance audits
Frequently Asked Questions
TLS 1.0 and 1.1, and SSLv2 and SSLv3 if your server still offers them at all. Both older TLS versions are deprecated by the major browser vendors, and each carries known weaknesses: weak key exchange in 1.0 and padding oracle problems across both. Nothing current requires them. TLS 1.2 and 1.3 are what should remain, and since TLS 1.2 is still needed for older clients, disabling 1.0 and 1.1 while keeping 1.2 is the usual end state rather than a jump straight to 1.3 only.
It removes entire categories of attack rather than negotiating them safely. TLS 1.3 deleted support for compression, static RSA key exchange, non-forward-secret Diffie-Hellman and a dozen cipher suites that had accumulated problems over fifteen years, so there is no configuration left to get wrong. It also completes a handshake in one round trip instead of two, and every session is forward secret by default rather than by choosing the right cipher.
A few seconds, because it completes one connection per version and each is a round trip to your server rather than a computation. The time is therefore dominated by network latency to your host and by how quickly your server completes a handshake, and a server that throttles or sits behind a slow proxy makes it noticeably longer. That is also the argument for running it on a schedule rather than on demand, since there is nothing in the result that changes second to second.
It affects very few clients, and the ones it affects are already outside support. No current browser sends TLS 1.0 or 1.1 by default, so the impact is concentrated in old embedded devices, long-unmaintained libraries and some scanning and monitoring tools. Measure rather than guess: check your own server logs for the protocol versions actually negotiated over a period, and if something you care about depends on an old version, scope TLS 1.0 to that client through a separate host rather than enabling it globally.
Yes, even though no current client offers it. An attacker who can influence the handshake does not have to use a modern browser — they can craft a request offering only the old version, and a server that still accepts it has nowhere to go but down. Disabling old versions removes the target, which is why the finding persists despite nobody negotiating them legitimately.
Compatibility. 1.3 is not universally supported by older clients, and some environments — long-lived embedded devices, older libraries — cannot negotiate it. Running both gives modern clients the better protocol and keeps older ones working, at no security cost, because 1.2 with a modern AEAD suite and forward secrecy is a perfectly good configuration.
Usually a different vantage point. A load balancer, a CDN edge or a middlebox may terminate TLS differently depending on where the connection comes from, so a host can negotiate modern versions for one visitor and old ones for another. Run the check from a second network before concluding the audit was wrong — and investigate the edge configuration if the results differ.
That the TLS library on this server no longer implements it, so no handshake from here can probe it. SSL versions fall into this category. It is reported as a limitation rather than as a clean result, because claiming a version is absent when nothing attempted it would be a measurement that was never made.
Set an explicit minimum of 1.2 and a maximum of 1.3, rather than relying on defaults, then test against the client population you actually have. Watch your logs for failures during the change — a client that cannot negotiate anything you still offer will show up as a handshake failure with a distinctive error. Raising the floor gradually and watching is safer than a single cut.
What Is Tested
Each version is offered on its own and the answer recorded, because a server that still accepts an old version is a different situation from one that merely prefers modern ones.
1Pin each probe to one version with both the minimum and maximum set to it. This is the step that makes the result meaningful — a version counts as supported only when a handshake restricted to it completes.
2Report each version's result as supported or not, which is the finding. Deprecated versions still negotiable are the ones that matter, because an attacker with a downgrade path needs somewhere to push a client.
3State what could not be tested. Versions the local library has removed are excluded rather than reported as absent, since claiming a result for a version no handshake here can attempt would be asserting something nobody measured.
A version being accepted is not proof it is in use — almost no client offers TLS 1.0 today. It is proof the option exists, which is what an attacker needs and what configuration should remove.
Tips & Best Practices
•Support only TLS 1.2 and TLS 1.3 for optimal security
•Test from multiple clients to catch configuration inconsistencies
•Document any legacy protocol support with business justification
Technical Details
Protocols: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 Methods: Direct connection testing with protocol-specific handshakes Compliance: NIST, PCI DSS, and Mozilla guidelines Output: Version matrix with security ratings and recommendations
