TLS 1.0 is enabled
What this check looks for
The server still accepts TLS 1.0, a version from 1999 that browsers removed in 2020. Keeping it available lets a connection be pushed down to it.
Why it matters
No visitor benefits — every browser that would use it has been removed from the web. Meanwhile it fails a PCI DSS assessment outright and keeps a downgrade path open for an attacker who can interfere with the connection.
When the check passes, your report says: “The server refuses TLS 1.0”.
What it costs your score
When this check fails it removes 25 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
- high
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 25 points
- Family cap
- tls.protocols · 40
- Category
- TLS
- Module
- Tls protocols
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Restrict the server to TLS 1.2 and TLS 1.3.
Nothing current uses TLS 1.0, and leaving it enabled keeps a downgrade path open.
Set the enabled protocols to TLS 1.2 and 1.3.
Apply it in the server-wide context so no virtual host is left behind.
Reload and re-test; a config test alone does not apply it.
How to confirm it worked
openssl s_client -connect ‹host›:443 -servername ‹host› -tls1 </dev/null 2>&1 | tail -1 — expect a handshake failure
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
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;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‹host› {
tls {
protocols tls1.2 tls1.3
}
}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
A TLS 1.0 handshake succeeded against ‹host›. ‹source›. TLS 1.0 depends on MD5 and SHA-1 in its key derivation and PRF, has no AEAD suites, and is the target of BEAST (CVE-2011-3389) and the Lucky 13 family. PCI DSS has forbidden it since June 2018. Disabling it costs nothing: clients old enough to need it cannot validate a current certificate anyway.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.