The server accepts TLS 1.0 or TLS 1.1 connections

Why it matters

RFC 8996 formally deprecates TLS 1.0 and TLS 1.1 and notes that they lack support for current and recommended cryptographic algorithms and mechanisms.

What to do

1. Look at the finding: it shows which of the two versions was negotiated and with which cipher suite.
2. Set the minimum TLS version to 1.2 in your CDN or hosting panel, or in the server configuration, for example ssl_protocols TLSv1.2 TLSv1.3; in nginx.
3. If old devices or integrations still depend on these versions, plan their upgrade before you turn the versions off.

What we read

We resolve your site's HTTPS address once and make a small, fixed number of TLS handshakes to that one server address, six at most for all TLS checks together. No page is requested over them. An ordinary, certificate-verified handshake is made before and after, and both must succeed and agree.

One handshake offers only TLS 1.0 and one offers only TLS 1.1. It is reported when either is actually negotiated. It passes only when the server refuses both with the protocol_version alert.

Example & evidence

Illustrative example — one audit, not a live result.

An audit makes its test handshakes to the server of bakery.example:

ordinary handshake      TLS 1.3 negotiated, certificate verified
offer TLS 1.0 only      refused: alert protocol_version
offer TLS 1.1 only      TLS 1.1 negotiated
ordinary handshake      TLS 1.3 negotiated, certificate verified

TLS 1.1 was negotiated, so the site is reported. A possible correction: the minimum version is set to TLS 1.2; both test handshakes are then refused with protocol_version, and nothing is reported.

Confirm & check again

Check for yourself: run openssl s_client -connect your-host:443 -tls1_1 from a system whose OpenSSL still offers that version, or read the minimum TLS version in your CDN or hosting settings.

Check again: Full audit — run a new audit of the site. The finding closes when both test handshakes are made again to your server and each is refused with the protocol_version alert, with the ordinary handshakes before and after succeeding. Any other outcome leaves it unconfirmed.

Limits & sources

A timeout, a reset connection, a DNS or certificate failure and any refusal other than the protocol_version alert are left unconfirmed, not passed.

If the audit's own TLS library cannot offer TLS 1.0 or 1.1, the check is recorded as not checked.

One server address is tested at one time from one location. A site served from several addresses, or through a CDN that answers differently elsewhere, can behave differently there.

Confidence: High because the finding rests on a handshake that was actually negotiated at the old version, between two ordinary verified handshakes to the same server.

Sources

• IETF, RFC 8996: Deprecating TLS 1.0 and TLS 1.1 — formally deprecates TLS 1.0 and TLS 1.1, moves them to Historic status, and notes that they lack support for current and recommended cryptographic algorithms and mechanisms. Checked 14 October 2026.
• IETF, The Transport Layer Security (TLS) Protocol Version 1.2, section 7.2.2 — defines the protocol_version alert as sent when the version the client tried to negotiate is recognized but not supported, and insufficient_security as returned when a negotiation fails specifically because the server requires ciphers more secure than those the client supports. Checked 14 October 2026.
• IETF, The Transport Layer Security (TLS) Protocol Version 1.3, section 6.2 — defines the protocol_version alert as sent when the protocol version the peer attempted to negotiate is recognized but not supported. Checked 14 October 2026.

Editorial review: 15 October 2026