TLS Version Checker

A TLS version checker shows which versions of the TLS protocol a website's HTTPS server will accept. Our tool connects to your site on port 443 once for each version, from TLS 1.3 down to TLS 1.0, and reports which connections succeed, along with the cipher suite negotiated for TLS 1.3 and 1.2. You can see straight away whether the modern versions are switched on and whether the deprecated TLS 1.0 and 1.1 are still enabled.

How to use the TLS versions

1. 1 Enter the domainType the host name of the site, for example example.co.uk or www.example.co.uk. Test each host separately if they are served differently.
2. 2 Run the TLS testSign in with your free account and start the check. We make four separate connections to port 443, one per protocol version.
3. 3 Review each versionTLS 1.3 and 1.2 are marked as passes when accepted. TLS 1.0 and 1.1 are flagged as a warning if either is still enabled.
4. 4 Change the server or CDN settingUpdate the protocol list in your web server, control panel or CDN, reload the configuration, then run the check again.

What TLS does and why the version matters

Transport Layer Security is the protocol that encrypts traffic between a browser and a web server. Every HTTPS connection begins with a handshake in which the client and server agree on a protocol version, a cipher suite and the keys to use. If they cannot agree on a version both support, the connection fails before any page is sent.

Each version fixed weaknesses in the one before. TLS 1.0 dates from 1999 and TLS 1.1 from 2006; both rely on older constructions, such as SHA-1 in the handshake and CBC-mode ciphers that were the target of attacks like BEAST and Lucky Thirteen. TLS 1.2 (2008) added modern authenticated encryption, and TLS 1.3, published as RFC 8446 in 2018, removed many legacy options altogether.

Version support affects security and compatibility. Leaving old versions enabled widens the attack surface and fails most compliance checks. Switching off too much can lock out older clients that still need TLS 1.2.

How our TLS version checker tests each protocol

The checker resolves your domain to an IPv4 address and opens a TLS connection to port 443 four times, each time allowing only one protocol version. It sends your host name using Server Name Indication, so a server or CDN that hosts many sites presents the configuration for your domain rather than a default one.

For the older versions, our client deliberately offers the legacy cipher suites they need, so a refusal means the server rejected the version rather than our client being too strict. Certificate validation is turned off for this test, because the aim is to see which protocols the server accepts; an expired or mismatched certificate will not hide the result, so check the certificate separately.

When TLS 1.3 or 1.2 succeeds, we show the cipher suite that was agreed. If no version connects at all, we report that the site could not be reached over HTTPS on port 443 instead of returning a misleading table.

Understanding the results

There are three lines in the result, and each has a clear target.

• TLS 1.3: a pass when accepted. If it is refused, it is a warning rather than a failure, because the site still works for visitors, but you are missing a faster and stronger protocol.
• TLS 1.2: a pass when accepted. If it is refused while TLS 1.3 works, that is a warning, since some clients will be locked out. If neither 1.2 nor 1.3 is accepted, it is a failure.
• TLS 1.0 and 1.1: a pass when both are disabled. If either is still accepted, it is a warning that names the versions found, so you know exactly what to switch off.

Why TLS 1.0 and 1.1 should be switched off

RFC 8996, published by the IETF in March 2021, formally deprecated TLS 1.0 and 1.1 and states that they must not be used. Chrome, Edge, Firefox and Safari had already removed support the year before, so no current browser will connect with them. The only clients that still try are very old devices and outdated scripts, and they are a poor reason to keep a weaker protocol open for everyone else.

PCI DSS has required early TLS to be disabled for card payment environments since mid-2018, and the National Cyber Security Centre advises UK organisations to use TLS 1.2 or 1.3 only. Cyber Essentials assessors and cyber insurers increasingly ask about it, and external vulnerability scans flag old versions as a finding.

Benefits of TLS 1.3

TLS 1.3 completes a new handshake in one round trip instead of two, which shaves time off the first connection, especially on mobile networks. It supports only cipher suites with authenticated encryption and forward secrecy, so even if the server's private key were stolen later, recorded traffic could not be decrypted with it. It also encrypts more of the handshake, including the certificate.

Because it removed the weak options rather than leaving them configurable, TLS 1.3 is harder to misconfigure. Most modern hosting platforms and CDNs support it already, and on your own server it needs OpenSSL 1.1.1 or later.

Where TLS settings live on common platforms

If your site sits behind a CDN such as Cloudflare, the versions visitors see are set at the CDN edge, not on your origin server. Change the minimum TLS version and TLS 1.3 setting in the CDN dashboard, and remember the connection from the CDN to your origin has its own settings.

On Nginx the protocols are set with the ssl_protocols directive, and on Apache with SSLProtocol in the virtual host or SSL configuration. LiteSpeed and OpenLiteSpeed have a protocol version setting in the SSL section of the listener. On shared cPanel hosting the TLS versions are usually controlled by the host, so if old versions are still enabled, ask support to disable them. Managed platforms often expose a minimum TLS version option in their SSL settings.

After any change, reload the web server, then test again. Load balancers and mail or API subdomains often have separate settings, so check each public host name. If your host or CDN offers a choice of cipher suites as well, keep its recommended modern profile rather than building a custom list, which is easy to get wrong.

TLS, search, payments and connected services

Search engines do not rank a site higher for offering TLS 1.3 rather than TLS 1.2, but HTTPS itself is a lightweight ranking signal, and a broken handshake means crawlers cannot fetch your pages at all. A modern protocol set also keeps the first connection quick, which helps the time to first byte that visitors and crawlers experience.

Payments are where old protocols cause real trouble. Card payment providers, PayPal and most UK banks require TLS 1.2 or later for any server that talks to their APIs, so an outdated configuration on your own server can break checkout callbacks and webhooks, not just browser visits. The same applies to accounting software, CRM integrations and stock feeds that connect to your site.

It is sensible to check TLS after moving hosts, putting the site behind a CDN, renewing a certificate on a self-managed server, or upgrading the operating system, since each of these can reset protocol settings to defaults. Keep a note of the result, because clients, auditors and insurers increasingly ask for evidence that legacy TLS is disabled.

Examples you can copy

ssl_protocols TLSv1.2 TLSv1.3;

SSLProtocol -all +TLSv1.2 +TLSv1.3

openssl s_client -connect example.co.uk:443 -servername example.co.uk -tls1_1 < /dev/null

openssl s_client -connect example.co.uk:443 -servername example.co.uk -tls1_3 < /dev/null

Common mistakes to avoid

Frequently asked questions