---
title: Are TLS 1.0 and 1.1 really off? How to check with the TLS Version Checker
description: An auditor, a PCI scan or a customer questionnaire asks you to prove that TLS 1.0 and 1.1 are disabled. To check which TLS versions a server accepts, offer it each version in turn and record which handshakes succeed. Here's how to do it with the free TLS Version Checker, how to read the protocol row, the openssl loop that produces evidence, and where the setting lives when an old version is still on.
canonical: https://watchfor.io/blog/how-to-check-tls-versions
---

# Are TLS 1.0 and 1.1 really off? How to check with the TLS Version Checker

2026-10-04 · WatchFor Team · Guides · guides, ssl, security

An auditor, a PCI scan or a customer questionnaire asks you to prove that TLS 1.0 and 1.1 are disabled. To check which TLS versions a server accepts, offer it each version in turn and record which handshakes succeed. Here's how to do it with the free TLS Version Checker, how to read the protocol row, the openssl loop that produces evidence, and where the setting lives when an old version is still on.

To check which TLS versions a server supports, try a handshake with each
version on its own, TLS 1.0, 1.1, 1.2 and 1.3 (and SSL 3.0), and note which
ones the server completes and which it refuses. A browser can't tell you
this: it always negotiates the newest version both sides speak, so a server
that still accepts TLS 1.0 looks exactly like one that doesn't.

The free [TLS Version Checker](/tls-version-checker) runs that handshake
matrix from a WatchFor probe and shows every version as accepted or refused,
with the cipher a modern client gets and an overall grade. No signup.

## What this tool answers

*Which TLS protocol versions does this server accept right now?* Reach for
it when an auditor or a PCI DSS scan asks for proof that early TLS is off,
after changing a load balancer, CDN or nginx TLS policy, when an old client
(an embedded device, a legacy Java service, a payment terminal) suddenly
can't connect, or when a scanner lists "TLS 1.0 enabled" and you need to
know which endpoint it means.

## A real example

### Checking TLS versions to prove 1.0 and 1.1 are disabled

The request usually reads: "Provide evidence that TLS 1.0 and TLS 1.1 are
disabled on all public endpoints." A screenshot of a config file isn't
evidence of what the server does; a handshake test is. We ran one against a
large public site that has switched the old versions off.

In the [TLS Version Checker](/tls-version-checker) we entered `github.com`,
kept port **443** and pressed **Grade this server**. The scan took 890 ms
from the Vilnius probe:

![The protocol and hardening sections of the TLS Version Checker result for github.com: TLS 1.3 and TLS 1.2 in green, TLS 1.1, TLS 1.0 and SSL 3.0 struck through; cipher TLS_AES_128_GCM_SHA256, key exchange X25519, forward secrecy yes, weak ciphers none; HSTS yes, 365 days, preload; OCSP stapling no; CAA record present; post-quantum no](/blog/how-to-check-tls-versions-protocols.webp)

The protocol row is the answer:

| Version | Result |
| --- | --- |
| TLS 1.3 | accepted |
| TLS 1.2 | accepted |
| TLS 1.1 | refused |
| TLS 1.0 | refused |
| SSL 3.0 | refused |

A modern client got TLS 1.3 with `TLS_AES_128_GCM_SHA256` over an X25519 key
exchange, no weak cipher was accepted, and the overall grade was **A+**: TLS
1.3 on, the old versions off, forward secrecy, and HSTS for 365 days with
`preload`.

**The answer:** yes, only TLS 1.2 and 1.3. For an audit, keep the
screenshot with its date, and the `openssl` output from the command-line
section, which shows the server's own refusal (`alert protocol version`) for
each old version. Repeat it for every public hostname and port: the apex,
`www`, the API, mail and anything behind a different load balancer.

If your own server shows TLS 1.0 or 1.1 in red, the fix is one setting where
TLS ends:

| Where TLS ends | Setting |
| --- | --- |
| nginx | `ssl_protocols TLSv1.2 TLSv1.3;` |
| Apache | `SSLProtocol -all +TLSv1.2 +TLSv1.3` |
| Cloudflare | SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2 |
| AWS ALB | A security policy without TLS 1.0/1.1 |

Cloudflare's default minimum is TLS 1.0, which is how many sites end up with
it on; the [SSL/TLS grade guide](/blog/how-to-test-your-ssl-tls-grade) walks
through one such case.

## How to read the results

| What you see | What it means |
| --- | --- |
| **Protocols, green** | Accepted and considered secure (TLS 1.2, TLS 1.3). |
| **Protocols, red** | Accepted but obsolete (TLS 1.0, TLS 1.1). Each one caps the grade at B; SSL 3.0 caps it at F. |
| **Protocols, struck through** | The server refused a handshake with that version. |
| **Grade and chips** | The overall A+ to F grade, the highest version, and HTTP/2 or post-quantum when present. |
| **Findings** | Worst first; "Obsolete TLS versions enabled" appears when 1.0 or 1.1 is accepted. |
| **Cipher** | The suite a modern client negotiated, not a list of every suite per version. |
| **Weak ciphers** | Any RC4, 3DES, DES, EXPORT or NULL suite the server still accepts. "None" is what an audit wants. |
| **Hardening and certificate** | HSTS, OCSP stapling, CAA, post-quantum, and the certificate details. |

## More ways to use it

- **Before switching old versions off.** Run it to see what's on now, then
  check your logs for clients that still negotiate 1.0 or 1.1 before you
  remove them.
- **When an old client stops connecting.** If the row shows only 1.2 and 1.3,
  the client is too old to speak either, or lacks every cipher the server
  offers. Upgrade the client or put a compatible endpoint in front of it.
- **Every endpoint, not just the website.** Put `465`, `993` or `8443` in
  **Port**; mail and admin endpoints often run older TLS stacks.
- **After a CDN or load balancer change.** Policies are per listener; a new
  one can come with different defaults.

## Tips and gotchas

- **Your own openssl may refuse to try.** OpenSSL 3 disables TLS 1.0 and 1.1
  at its default security level, so `-tls1` fails with "no protocols
  available" before it reaches the server. Add
  `-cipher 'DEFAULT:@SECLEVEL=0'`, as below, or you'll "prove" a version is
  off when it isn't.
- **One location, one front end.** Anycast and GeoDNS can route other
  regions to servers with a different policy.
- **Accepted isn't negotiated.** Browsers pick TLS 1.3 when they can, so a
  server with 1.0 on still shows 1.3 in the browser's security panel.
- **HTTP/3 is separate.** QUIC always uses TLS 1.3; the matrix tests TLS over
  TCP, which is where old versions live.
- **The why behind the versions** is in
  [TLS 1.2 vs 1.3](/blog/tls-1-2-vs-1-3); TLS 1.0 and 1.1 were formally
  deprecated by RFC 8996 in 2021.

## Check it from the command line too

Offer each version on its own; `SECLEVEL=0` lets your client attempt the old
ones:

```bash
for v in tls1 tls1_1 tls1_2 tls1_3; do
  printf '%-8s ' "-$v"
  echo | openssl s_client -connect github.com:443 -servername github.com -$v \
    -cipher 'DEFAULT:@SECLEVEL=0' 2>&1 \
    | grep -m1 -oE 'alert protocol version|Protocol *: *TLSv1(\.[0-3])?$'
done
```

```text
-tls1    alert protocol version
-tls1_1  alert protocol version
-tls1_2  Protocol: TLSv1.2
-tls1_3  Protocol: TLSv1.3
```

`alert protocol version` is the server refusing that version, the evidence an
auditor wants. The same loop against a server that still accepts the old
versions:

```text
-tls1    Protocol: TLSv1
-tls1_1  Protocol: TLSv1.1
```

(That's `example.com`, the first two lines with the hostname swapped.)

## Keep watching it

A TLS policy can come back with the next load balancer or CDN change. An
[SSL monitor](/ssl-monitoring), on plans that include the TLS grade, runs
the full version scan once every 24 hours; since TLS 1.0 or 1.1 caps the
grade at B, a **TLS Grade** alert rule set to A opens an incident the day an
old version is re-enabled. The monitor's **Minimum TLS Version** rule is a
different check: it alerts when the negotiated version falls below your
floor, which catches a server that can no longer do 1.3 or 1.2.

## FAQ

**How do I check which TLS versions a server supports?**
Test each version separately: the TLS Version Checker does it in one run, or
use `openssl s_client -connect host:443 -tls1_1` (and `-tls1`, `-tls1_2`,
`-tls1_3`) and see which handshakes complete.

**How do I disable TLS 1.0 and 1.1?**
Set the minimum protocol where TLS terminates: `ssl_protocols TLSv1.2
TLSv1.3;` in nginx, `SSLProtocol -all +TLSv1.2 +TLSv1.3` in Apache, or
Minimum TLS Version 1.2 on your CDN or load balancer. Re-test afterwards.

**Is TLS 1.2 still secure?**
Yes, with modern cipher suites (ECDHE key exchange, AES-GCM or
ChaCha20-Poly1305). Keep TLS 1.2 for compatibility and enable TLS 1.3 next
to it; how they compare is in [TLS 1.2 vs 1.3](/blog/tls-1-2-vs-1-3).

---

Canonical page: https://watchfor.io/blog/how-to-check-tls-versions · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt