TLS 1.3 is not supported

MediumConfirmedQuick wintls.protocols.no-tls13

What this check looks for

The server does not offer the current version of TLS. Connections still work over the older version, but they are slower to set up and lack its safety improvements.

Why it matters

TLS 1.3 removes every legacy cipher construction as a matter of design, and it completes the handshake in one round trip instead of two — a visible difference on mobile networks. It is also what a top security grade is defined against.

When the check passes, your report says: “The server supports TLS 1.3”.

What it costs your score

When this check fails it removes 8 points from your TLS score, before the status, confidence and repeat multipliers are applied. TLS carries a weight of 15 in the overall score.

It shares the tls.protocols family ceiling of 40 points: however many findings that family produces, together they cannot remove more than that from TLS. One underlying problem showing up in several places is still one problem.

Severity: medium
Default confidence: confirmed
Status when triggered: warn
Deduction: 8 points
Family cap: tls.protocols · 40
Category: TLS
Module: Tls protocols
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Enable TLS 1.3 alongside TLS 1.2.

It is faster, structurally safer, and required for the top grade.

Confirm the server is linked against OpenSSL 1.1.1 or later: nginx -V or apachectl -V.
Add TLSv1.3 to the enabled protocol list and reload.
Leave TLS 1.2 enabled — dropping it locks out clients that are still current.

How to confirm it worked

openssl s_client -connect ‹host›:443 -servername ‹host› -tls1_3 </dev/null 2>&1 | grep 'Protocol' — expect TLSv1.3

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

Apache

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder     off
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305

Caddy

‹host› {
	tls {
		protocols tls1.2 tls1.3
	}
}

Cloudflare

SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2.

Put this in the http block so it applies to every server block; a per-server ssl_protocols directive silently overrides it for that server only.
Set it in the main configuration, not in .htaccess — SSLProtocol is a server-context directive and .htaccess cannot change it.
Caddy already defaults to TLS 1.2 and 1.3; an explicit block is only needed to pin them.
This setting governs the connection between visitors and Cloudflare's edge only. It does not change what the origin server negotiates, and an origin that is reachable directly — by IP, or through any DNS record that is not proxied — still accepts what it accepted before. This scan measured the origin, so apply the server-side configuration as well.

Technical detail

No TLS 1.3 handshake succeeded against ‹host›. RFC 9846 (which obsoleted RFC 8446) removed static RSA key exchange, CBC-mode ciphers, compression and renegotiation outright, so a whole class of downgrade and padding-oracle attacks does not apply to it. Support is present in OpenSSL 1.1.1 and later, nginx 1.13+, Apache 2.4.36+ and every current Caddy. This is the affirmative achievement dotvitals requires for an A+, so a scan that could not test it does not satisfy it either.