TLS 1.0 and 1.1 Are Being Shut Out — Time to Check What Your Server Negotiates

The long-promised browser shut-off of TLS 1.0 and 1.1 is finally happening. All the major browser vendors announced back in 2018 that they'd pull support in early 2020 — then the pandemic hit, government and health sites that still ran old TLS suddenly mattered a great deal, and the rollout was paused. That pause is over. As of this summer, current releases of Chrome, Edge and Firefox treat a TLS 1.0/1.1-only site as broken: not a subtle padlock warning, but a full-page security interstitial most visitors will never click through.

If every server you run already negotiates TLS 1.2 or better, this is a ten-minute verification exercise. If one of them doesn't — an old load balancer, a forgotten subdomain, an appliance with a web UI — its traffic is about to fall off a cliff. Here's how to check, what to change, and the trade-offs to think through before you flip the switch.

Why TLS 1.0 and 1.1 had to go

TLS 1.0 dates to 1999, TLS 1.1 to 2006, and the cryptographic world has moved on around them:

• Broken primitives. Both versions permit MD5 and SHA-1 in ways modern protocols don't, and TLS 1.0's CBC construction enabled the BEAST attack. Downgrade tricks against these protocol generations (POODLE and friends) are a well-worn attacker playbook.
• No modern ciphers. Neither version supports the AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) that make up essentially all of today's well-configured TLS traffic.
• Compliance already left. PCI DSS required TLS 1.0 to be gone from payment environments back in mid-2018. If you take card data, this deadline passed two years ago.
• The standards are following. Formal deprecation of TLS 1.0/1.1 is working its way through the IETF process now — the browsers are simply moving first, as they usually do.

The good news: TLS 1.2 has been around since 2008 and TLS 1.3 since 2018. Every remotely current server stack supports at least one of them.

What browsers actually do now

The current behavior, as of this month:

• Chrome and Edge show a full-page ERR_SSL_OBSOLETE_VERSION / "connection not fully secure" interstitial on TLS 1.0/1.1-only sites.
• Firefox shows a similar error page. There's a temporary override button — reportedly kept as a pandemic concession for straggler sites — but it's explicitly on borrowed time.
• Safari has committed to the same direction across its 2020 releases.

The practical translation: a TLS 1.0-only site isn't "less secure" in your visitors' eyes anymore. It's down.

Test what your server actually negotiates

Don't assume — check. openssl s_client lets you force a specific protocol version and see whether the server accepts it:

# Does the server still accept TLS 1.0? (You want this to FAIL)
openssl s_client -connect example.com:443 -tls1 < /dev/null

# TLS 1.1? (Should also fail)
openssl s_client -connect example.com:443 -tls1_1 < /dev/null

# TLS 1.2? (Should succeed)
openssl s_client -connect example.com:443 -tls1_2 < /dev/null

A refusal looks like handshake failure or an immediate disconnect — that's what you want for the first two. A successful connection prints the negotiated protocol and cipher in the session summary; on the TLS 1.2 test you should see Protocol : TLSv1.2 and a modern suite like ECDHE-RSA-AES256-GCM-SHA384.

Two things people forget to test:

• Every hostname, not just the main site. The API subdomain, the old blog, the staging box with a real cert — each terminates TLS somewhere, and that somewhere may be configured differently.
• The actual edge. If a load balancer or CDN terminates TLS in front of your servers, its settings are the ones that matter, and they're often configured in a dashboard nobody has opened since setup.

Enabling TLS 1.2 and 1.3

On nginx, protocol support is one directive (TLS 1.3 needs nginx 1.13+ built against OpenSSL 1.1.1):

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    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;
    ssl_prefer_server_ciphers off;
}

On Apache (2.4 with OpenSSL 1.1.1 for TLS 1.3):

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

Reload, then re-run the s_client tests above to confirm 1.0 and 1.1 now fail and 1.2/1.3 succeed. If your OpenSSL is too old for TLS 1.3, don't block on it — TLS 1.2 with the suites above is a perfectly respectable place to be in 2020; 1.3 is a bonus (faster handshakes, cleaner cryptography), not a requirement.

If a managed service terminates your TLS, look for a "minimum TLS version" setting and raise it to 1.2 — most major CDNs and load balancers expose exactly that toggle now.

The legacy-client trade-off — smaller than you fear

The reason old TLS survived this long is fear of stranding old clients. It's worth naming exactly who you'd strand:

• Android 4.3 and earlier (2013-era devices) lack TLS 1.2 in the default stack.
• Old embedded clients and payment terminals — the long tail that made PCI's 2018 deadline painful.

Meaningful traffic from these is, for most sites in 2020, a rounding error — by most published measurements, TLS 1.0/1.1 usage is down to a low single-digit percentage of connections and falling. Check your own logs rather than guessing: most servers can log the negotiated protocol per request (nginx's $ssl_protocol variable, Apache's %{SSL_PROTOCOL}x). If old-TLS traffic is 0.3% of requests and it's all bots, the decision makes itself. And remember the counterweight — the modern clients now throwing interstitials at weak configs vastly outnumber the legacy ones you'd lose.

Verify once, then keep verifying

The trap with TLS configuration is that it's write-once, drift-forever: a server rebuild, a config restored from an old backup, a new load balancer with default settings — and TLS 1.0 quietly comes back, or worse, your certificate chain breaks with it. This deadline is a good prompt to make TLS part of what you continuously monitor, not something you check the year a browser forces you to.

CompleteStatus checks your certificates and TLS layer on an ongoing basis alongside uptime — expiry warnings before the padlock breaks, and alerts when the security posture of an endpoint changes — all in one dashboard. Create a free account, add your domains, and treat this month's TLS cleanup as the last one you ever have to do manually.