TLS Version Checker: Which TLS Versions Does a Server Offer?

Transport Layer Security has gone through several versions, and not all of them are safe to offer today. TLS 1.3, published in 2018, and TLS 1.2, published in 2008, are the current versions. TLS 1.1 and 1.0, and the SSL versions before them, contain known weaknesses and are considered obsolete. Yet many servers still offer them, because their configurations were written years ago and never revisited, or because someone feared breaking an old client. A version checker answers the basic question — what does this server actually offer — so that the fear can be replaced with evidence.

The TLS Version Checker reviews a pasted protocol summary, such as output from a configuration report or a server's documented settings, and reports which TLS versions are enabled and which should be disabled. It works from information you paste in; it does not probe a live server or require credentials, and you should never paste secrets, keys or certificate private material into it. A version list is configuration information, not sensitive data, and that is all the tool needs. If you need a live view of a public server, use your server's own reporting or a reputable scanning service that you trust, and keep the pasted-input check for reviewing configuration summaries.

Why versions matter is worth stating plainly. Each TLS version defines the negotiation, the algorithms and the protections available for a connection. Older versions permit weaker algorithms, weaker negotiation protections, and behaviours that later versions fixed. An attacker who can persuade a client and server to negotiate an old version — a downgrade attack — inherits all of those weaknesses even if both sides also support newer versions. Disabling old versions removes that path entirely: a client that cannot negotiate a modern version simply cannot connect, which is a visible failure you can investigate, rather than a silent weak connection you never notice.

Reading a version report

A clean report is short: TLS 1.2 and TLS 1.3 enabled, everything older disabled. That is the target for almost every public service today. A report showing TLS 1.1 or 1.0 enabled is a finding, not a curiosity, and it should be scheduled for removal. A report showing SSL 3.0 or earlier is a serious finding: those protocols have been broken for years, and their presence suggests a configuration that has not been reviewed in a very long time, which usually means other settings are out of date too. Treat an SSL finding as a prompt for a full configuration review, not a single-line fix.

Version reports sometimes surprise their owners in the other direction: a server that should support TLS 1.3 does not. That usually means the server software is old, or TLS 1.3 was never enabled after an upgrade. Enabling it is generally safe and beneficial, because clients that support it will use it and clients that do not will fall back to TLS 1.2. If your server software cannot support TLS 1.3 at all, that is a signal to plan an upgrade, since the software is likely missing other security fixes as well.

Also check consistency across endpoints. A main website may be modern while an old subdomain, an API endpoint, or a forgotten staging server still offers obsolete versions. Attackers look for the weakest endpoint, not the strongest, so a version audit should cover every public hostname a service uses, not only the homepage. Keep a list of hostnames and check them together; a spreadsheet of hostnames and versions, updated at each audit, is a simple and effective record.

Worked example: an old version found on a shop site

Suppose a small shop's configuration summary shows TLS 1.0, 1.1, 1.2 and 1.3 all enabled. The checker flags 1.0 and 1.1 for removal. The owner worries about losing customers on old devices, so instead of guessing, she checks a month of server logs for the negotiated version of real connections. The result is reassuring: fewer than one in a thousand connections used TLS 1.0 or 1.1, and those came from automated scanners and a single outdated monitoring script, not from customers. She updates the monitoring script, disables 1.0 and 1.1 on a staging server, tests checkout with current browsers and phones, and then applies the change to production during a quiet hour.

A week later, error rates are unchanged, no customer has complained, and a repeat check shows only TLS 1.2 and 1.3 offered. The shop also gains a small side benefit: the configuration is now simpler to explain and to audit, because there are fewer versions and fewer edge cases to reason about. The total work was a few hours, most of it spent checking logs and testing rather than making the change itself. That ratio is typical and healthy: the change is one line, and the confidence comes from the checks around it.

If the logs had instead shown real customers on old versions, the plan would have differed. The owner would have identified those customers' devices, warned them if possible, set a date for removal, and perhaps kept the old versions only on a separate legacy endpoint with restricted access. The point is that the decision follows evidence about actual users, not anxiety about hypothetical ones, and a version checker plus a log review supplies that evidence.

Planning the removal safely

Removal is safest as a staged change. First, disable the oldest version, monitor for a week, and then disable the next. Staging the change means any problem points at a single version, which makes diagnosis easy. Keep the previous configuration saved and tested so it can be restored quickly; a rollback plan that has never been tried is a hope, not a plan. Announce the change to support staff before it happens, so that if a customer does report a connection problem, the team recognises it immediately instead of troubleshooting blindly.

Also consider what else changes at the same time. A version removal is a good moment to review cipher suites, because old versions and weak suites often travel together in old configurations. Removing TLS 1.0 without removing the weak suites that only old versions used is still progress, but the full benefit comes from cleaning both. Do not, however, bundle too many changes into one deployment: if something breaks, you want to know which change broke it. One theme per change, tested and monitored, is the pace that keeps services safe and teams calm.

Document the final state. A short note recording which versions are enabled, when the old ones were removed, and what the log review showed, saves the next person from repeating the investigation. When a future audit asks why TLS 1.0 is disabled, the note answers in one paragraph. Good security practice is often just good record-keeping applied to configuration decisions.

For companion checks, the SSL/TLS Configuration Checker reviews the broader configuration that surrounds version settings, and the DNS Lookup helps verify the domain records behind a hostname before you audit its endpoints. For certificate-side checks, see SSL Certificate Checker Guide.

FAQs

Is TLS 1.2 still safe, or must everything move to 1.3? TLS 1.2 with strong suites and secure settings remains safe and widely used. TLS 1.3 is preferred where supported, but a well-configured TLS 1.2 is not an emergency; obsolete versions below 1.2 are the urgent problem.

Will disabling TLS 1.0 break search engines or payment providers? Modern search engines and payment providers support TLS 1.2 and above, and many require it. If a specific partner still needs an old version, that partner has a security problem of its own, and the conversation should be about their upgrade, not your downgrade.

How often should versions be checked? At least annually, after server upgrades, and whenever a new protocol version or vulnerability is announced. Add the check to the same routine as certificate renewal so it is never forgotten.