SSL/TLS Hygiene in 2026: What to Fix Today
TLS 1.3 has been mandatory in spirit for years. Here is what an external scan still finds in 2026 on production sites, and which fixes are non-negotiable.
Every year the conventional wisdom says "TLS is solved, move on." Every year I find the same five things in external scans on production sites. TLS 1.3 has been the right answer since 2018; the gap between "exists" and "deployed correctly" remains a full job. Here is the short list of what an external scan still trips on in 2026 and what to do about each finding.
Finding 1: TLS 1.0 / 1.1 still accepted
These have been formally deprecated since 2020. Major browsers refuse them. Major payment processors require their absence. They still appear on internal-facing services and on the long tail of customer-facing services whose load balancer config was last touched in 2017. Disabling them is one config line and almost never breaks anything that you actually have customers on — the broken client is an automated scraper from 2014 that nobody is paying you for.
Disable 1.0 and 1.1. Make 1.2 the floor. Make 1.3 the preferred. There is no reasonable counter-argument in 2026.
Finding 2: weak ciphers still enabled in 1.2
Even when TLS 1.0/1.1 are gone, the 1.2 cipher suite list often contains historical artefacts: CBC modes with HMAC-SHA1, RSA key exchange (no forward secrecy), 3DES, even RC4 on the most antique boxes. The attack surface for each of these is bounded but real: BEAST, Lucky13, ROBOT, and a half-dozen others rely on a client and server agreeing to use a weak suite that neither would pick if they had the option.
Pin the cipher order on the server side. Keep only forward-secret AEAD suites: ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-*-CHACHA20-POLY1305, and the corresponding 128-bit variants. Drop everything else. Mozilla's "intermediate" config is the right reference if you want a copy-pasteable starting point.
Finding 3: certificate expiry within 30 days
The single most common operational TLS finding is a certificate that expires this month. The fix is automation, not vigilance. Let's Encrypt + a renewal cronjob, ACME on the load balancer, or a paid cert with a managed renewal service — any of these works. What does not work is "the ops engineer who last renewed it doesn't work here anymore." Calendar reminders are not a control.
A related finding is the cert chain that's missing the intermediate. The leaf is valid, the root is in every browser store, but the intermediate isn't bundled in the server response. Some browsers fetch the intermediate via AIA; others don't and show a warning. Always ship the full chain.
Finding 4: weak Diffie-Hellman parameters
For servers still doing DHE key exchange, the parameter size should be at least 2048 bits. A surprising number of Apache and Nginx configs have a 1024-bit (or worse, 512-bit) Diffie-Hellman group baked in from a default config file written ten years ago. Generate a fresh 2048-bit group during deployment or, better, drop DHE entirely and rely on ECDHE — which doesn't have this footgun.
Finding 5: OCSP stapling not enabled
When a browser wants to check whether a cert has been revoked, it has two options: ask the CA's OCSP responder (slow, privacy-leaking), or trust that the server has stapled a fresh OCSP response into the TLS handshake. Stapling is faster for the client and stops the CA from getting a log of every connection to your site. Enabling it is one line on both Apache and Nginx; the only operational cost is making sure the staple is refreshed before expiry.
How to scan the deployed config
Configuration files lie. The CDN's actual TLS config matters more than what your terraform thinks is deployed. Pull the live handshake on production with our SSL analyzer — it surfaces the protocol list, cipher list, certificate chain, expiry dates, and OCSP stapling status in one pass. For the headers piece (HSTS in particular, since broken HSTS undermines everything else on this list), our headers checker walks the redirect chain and verifies the policy.
Done correctly, the whole TLS posture audit for a single hostname takes under five minutes and produces a short list of fixes that an ops engineer can knock out in an afternoon. Done in spreadsheet form once a year, it produces a slow-burning backlog that becomes a customer-visible failure the day Chrome ships its next deprecation. The math, again, is not subtle.