highSeverity: highRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical โˆ’40, high โˆ’20, medium โˆ’10, low โˆ’4, info โˆ’1. Higher severity means fix it sooner.TLS / web server configWhere it livesImplementationThis fix is applied in: TLS / web server config. That's the surface you'll edit, DNS, response headers, or a static file.~15 minTime to fixEffortRoughly 15 minutes of hands-on work, propagation aside. Most of these are copy-paste.+20 posture+20 postureScore impactPoints this fix recovers in the ApeCyber posture score (0โ€“100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Weak TLS versions: turn off TLS 1.0 and 1.1, require 1.2 and 1.3

Dropping the obsolete protocol versions removes the known downgrade and decryption attacks

The threat

This one is not about your certificate, which can be perfectly valid. During the handshake the scanner offered your server a range of TLS versions and found it still willing to speak TLS 1.0 or TLS 1.1. Those versions are retired: the industry deprecated them in 2020, and they carry known, named weaknesses (BEAST, POODLE, and protocol downgrade among them) that let an attacker positioned on the same network as a visitor pull apart traffic everyone assumed was private.

The danger is quiet because the connection still looks secure, the padlock is right there, so nobody notices a weak version was used. An attacker does not have to break TLS 1.3, they only have to force the conversation down to the weakest version you still accept. Removing 1.0 and 1.1 entirely takes that option off the table, and because this is a web server setting rather than a certificate, the fix is a one-line config change and a reload.

The exact fix

nginx. In your server (or http) block, pin the allowed versions to modern ones and let the client pick the cipher on TLS 1.3:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
sudo nginx -t && sudo systemctl reload nginx

Apache. In your TLS virtual host:

SSLProtocol -all +TLSv1.2 +TLSv1.3
sudo apachectl configtest && sudo systemctl reload apache2

Managed host. On Cloudflare, set SSL/TLS, then Edge Certificates, then Minimum TLS Version to 1.2. Netlify and Vercel already refuse anything below TLS 1.2 by default, so if a site behind one of them is flagged, the weak endpoint is usually an origin server or a separate subdomain sitting behind the platform. Fix it at that origin.

Tip: before flipping this on a site with older customers, know that TLS 1.2 is supported by every browser since roughly 2013 and every current mobile OS. The only exceptions are ancient embedded devices and Internet Explorer on Windows XP, effectively no one, and none of them should be trusting a weak channel with real traffic anyway.

Verify it

openssl s_client -connect yourdomain.com:443 -tls1_1 </dev/null 2>&1 | grep -iE "handshake failure|no protocols|alert"

Forcing a TLS 1.1 handshake should now fail, and you want it to: a matched line (a handshake failure or protocol alert) means the server refused the weak version. Swap -tls1_1 for -tls1_2 and the same command should instead connect cleanly.

Proof

apecyber.com, graded A / 100 on Netlify, negotiates only modern TLS, so the TLS 1.0 and 1.1 handshakes this check probes for are refused outright. The ApeCyber scanner attempts those weak versions passively from the outside on every scan and simply records that they are declined, touching nothing on your server.