The fix, in one snippet
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
After the main handshake, Scan.now makes two further connection attempts to port 443. Each sends a ClientHello whose maximum offered version is capped: first TLS 1.0, then TLS 1.1. If the server completes either handshake instead of replying with a protocol_version alert or closing the connection, the check fails and reports which versions were accepted. This is an ordinary handshake attempt with no application data; nothing is exploited. A server that negotiates only TLS 1.2 and 1.3 passes. Because RFC 8996 moves TLS 1.0 and 1.1 to Historic status and states that they MUST NOT be used, acceptance of either is rated high. Whether TLS 1.3 is offered at all is a separate, lower-severity check: tls-1-3-support. Cipher suite quality is covered by weak-ciphers.
Why it matters
TLS 1.0 dates from 1999 and 1.1 from 2006. Neither supports authenticated-encryption (AEAD) cipher suites, both derive keys with a PRF built on MD5 and SHA-1, and 1.0's CBC construction is the basis of the BEAST attack. Protocol-downgrade attacks work by pushing a client that supports old versions down to one of them; a server that refuses the old versions ends the attack at the handshake. Chrome, Firefox, Safari and Edge all disabled TLS 1.0 and 1.1 in 2020, so real browsers will not be hurt by turning them off. Accepting them mostly serves ancient API clients and embedded devices, and it fails compliance baselines: PCI DSS has required disabling TLS 1.0 for new implementations since 2018 and NIST SP 800-52 Rev. 2 requires TLS 1.2 or later for government servers. The SSL and TLS guide explains what changed between versions.
How to fix it
Restrict the server to TLS 1.2 and 1.3. nginx:
ssl_protocols TLSv1.2 TLSv1.3;Apache:
SSLProtocol -all +TLSv1.2 +TLSv1.3Node.js (built-in tls / https server):
https.createServer({ key, cert, minVersion: 'TLSv1.2' }, app).listen(443);Cloudflare: SSL/TLS > Edge Certificates > Minimum TLS Version > TLS 1.2. Note that this governs the edge; your origin's own configuration still matters for direct connections. Verify from a shell (a healthy server prints a handshake failure):
openssl s_client -connect example.com:443 -tls1_1 < /dev/nulltestssl.sh gives a full protocol and cipher matrix if you want to audit a whole fleet. Check your access logs for the TLS version column before switching, so you know which legacy clients, if any, will be cut off.
Where this fits
Deprecated TLS versions accepted (1.0 / 1.1) is check 4 of 12 that the website vulnerability scanner runs under transport security (https / tls), ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Certificate expiry (high), where the certificate has expired or will expire within 30 days. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Deprecated TLS versions accepted (1.0 / 1.1) closes one route in. Immediately below it: HTTP redirects to HTTPS, where port 80 serves page content instead of redirecting to HTTPS, or the redirect chain is wrong; Certificate key strength, where the certificate's public key is weaker than current guidance: An RSA key shorter than 2048 bits, or a DSA key; Certificate signature algorithm, where a certificate in the chain is signed with SHA-1, MD5 or another broken hash.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Exposed .env configuration file, where a .env configuration file is served from the web root, and Exposed .git repository, where the site's .git directory is reachable over HTTP. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Deprecated TLS versions accepted (1.0 / 1.1) (high severity)
Scanner check id: tls-deprecated-versionsThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
