The fix, in one snippet
ssl_protocols TLSv1.2 TLSv1.3;
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
Scan.now's primary handshake offers TLS 1.3 through the supported_versions extension alongside TLS 1.2, and records which version the server selects together with the negotiated cipher suite (for example TLS_AES_256_GCM_SHA384). The check passes when the server picks TLS 1.3. It is reported as low severity when only TLS 1.2 is negotiated, and it is skipped entirely if no HTTPS connection could be made at all (see https-available). Scan.now does not test 0-RTT early data or session resumption behaviour; those are configuration details beyond a passive scan. Acceptance of the old versions 1.0 and 1.1 is a separate, more serious finding: tls-deprecated-versions.
Why it matters
TLS 1.3 (RFC 8446) removed everything that had caused trouble in earlier versions: static RSA and static Diffie-Hellman key exchange, CBC-mode and RC4 suites, SHA-1 and MD5, compression, and renegotiation. Every TLS 1.3 connection has forward secrecy, meaning a private key stolen next year cannot decrypt traffic recorded today. The handshake takes one round trip instead of two and encrypts the server certificate, so a network observer no longer sees which certificate was presented. A carefully configured TLS 1.2 deployment is still secure, but it relies on you having chosen the right suites and ordering; TLS 1.3 makes the safe configuration the only configuration. Browsers have negotiated TLS 1.3 by default since 2018, so enabling it costs nothing in compatibility. See the SSL and TLS guide for the handshake differences.
How to fix it
TLS 1.3 requires OpenSSL 1.1.1 or later (or an equivalent library). Any current Linux distribution ships it. nginx 1.13.0+:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
Apache 2.4.36+ with OpenSSL 1.1.1+:
SSLProtocol -all +TLSv1.2 +TLSv1.3
Node.js 12 or later negotiates TLS 1.3 by default; nothing to set beyond a minimum version:
https.createServer({ key, cert, minVersion: 'TLSv1.2', maxVersion: 'TLSv1.3' }, app);
Cloudflare enables TLS 1.3 at the edge by default; the toggle is under SSL/TLS > Edge Certificates if it was turned off. Confirm from the command line:
openssl s_client -connect example.com:443 -tls1_3 < /dev/null 2>/dev/null | grep 'Protocol'
If the output shows TLSv1.3, the check will pass on the next scan. The SSL checker reports the negotiated version and suite in one step.
Where this fits
TLS 1.3 support is check 10 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 Weak cipher suites accepted (medium), where the server is willing to negotiate legacy cipher suites such as RC4, 3DES, export-grade, NULL or anonymous suites, or offers TLS 1.2 suites without forward secrecy. 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
TLS 1.3 support closes one route in. Immediately below it: HSTS preload eligibility, where the domain does not yet meet the requirements for the browser HSTS preload list; HTTP/2 support, where the server negotiates only HTTP/1.1 over TLS and does not advertise HTTP/2.
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: TLS 1.3 support (low severity)
Scanner check id: tls-1-3-support
The 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.