SSL/TLS Mistakes That Still Break Websites in 2026

Getting HTTPS is a one-click affair now — which is exactly why the problems have changed shape. Sites rarely lack a certificate anymore; they run one that expired on Saturday, or still accept a protocol that was deprecated five years ago. TLS configurations rot silently: nothing looks wrong until a browser throws a full-page warning or an auditor refuses to sign off.

Table stakes, quietly rotting

A TLS setup has moving parts: a certificate that expires, protocol versions that age out, cipher suites that get broken, redirects that someone forgets after a migration. None of these announce themselves when they degrade. And because scanning the internet is fully automated — by researchers, compliance tools, and attackers alike — a weak TLS config is public information within hours of appearing. Here are the failures that still show up constantly, and how to close each one.

Expired and expiring certificates

Still the number-one TLS failure, and the most visible: browsers show a full-page warning and most visitors leave. The expiry date is stamped in the certificate, so it is never a surprise in principle — but auto-renewal fails quietly. A DNS change breaks the renewal challenge, a migration leaves an old certificate pinned at the CDN, a manually issued cert on a forgotten subdomain hits its date.

Two details make monitoring non-optional. Certificates expire at exact timestamps, not business hours — plenty die on weekends, when nobody is watching the inbox the warning email went to. And lifetimes keep shrinking: public certificates are capped at 200 days as of March 2026, on a published path down to 47 days by 2029. Renewal is becoming something that happens many times a year, forever.

Fix:use managed certificates from your host or CDN, keep auto-renewal on, and verify the automation actually ran after any DNS or hosting change. Treat “expires in under 30 days” as a real problem, not a reminder.

Hostname mismatch

The certificate is valid — for a different name. Classic causes: a cert issued for www.example.com served on the bare example.com(or the reverse), a new subdomain that never got added to the certificate’s name list, a load balancer answering with its default cert. To your visitors, the warning looks identical to an expired certificate. Fix: issue certificates covering every name you serve, and test both the apex domain and www.

TLS 1.0 and 1.1: deprecated, still enabled

These are the BEAST- and POODLE-era protocols. The IETF formally deprecated them in RFC 8996, mainstream browsers dropped them in 2020, and PCI DSS has required them off since 2018 — if you take card payments, an enabled TLS 1.0 is a compliance failure, not a style point. Leaving legacy protocols on keeps downgrade paths alive for connections that can be nudged into negotiating badly.

The flip side: make sure TLS 1.2 and 1.3 are both on. TLS 1.3 is faster — fewer round trips per connection — and removes the legacy cryptography entirely. There is no reason to be without it in 2026.

Weak crypto that lingers

Modern certificate authorities will not issue the bad stuff, but self-managed servers and old appliances still carry it:

• SHA-1 signatures — collision attacks are practical, and browsers stopped trusting SHA-1 certificates back in 2017.
• Weak keys — RSA below 2048 bits no longer meets baseline guidance.
• Weak cipher suites— RC4, 3DES, and old CBC-mode suites left enabled “for compatibility” with clients that no longer exist.

Fix:do not hand-tune cipher lists from a 2016 blog post. Use the Mozilla Server-Side TLS guidelines — the “intermediate” profile fits almost everyone — and their config generator for your exact server and version.

The missing HTTP-to-HTTPS redirect

Your site can have a perfect certificate and still serve plaintext: if port 80 does not redirect, everyone who types your domain without https:// browses unencrypted. Redirect all HTTP traffic to HTTPS with a 301 or 308, then add an HSTS header so returning browsers never send that first insecure request at all — covered in our security headers guide.

Certificate transparency

Every publicly trusted certificate is recorded in public Certificate Transparency logs, and browsers expect proof of that logging before trusting a cert. Managed certificates handle this automatically, so it is mostly a check-that-it-is-there item. CT also works in your favor: watching the logs for your own domain reveals any certificate issued that you did not request — an early signal that something is wrong.

How to check your TLS

The browser padlock only proves the connection your browser chose; it says nothing about what else the server would accept. A few quick manual checks:

# Does HTTP redirect to HTTPS?
curl -sI http://yourdomain.com

# When does the certificate expire?
openssl s_client -servername yourdomain.com -connect yourdomain.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates

Legacy protocol and weak cipher support is harder to probe by hand — the server has to be asked, offer by offer. This is where a scanner earns its keep.

How to fix it

• Certificates:managed and auto-renewed (ACME/Let’s Encrypt, or the certs bundled with your CDN and host).
• Protocols: TLS 1.2 and 1.3 only. On nginx: ssl_protocols TLSv1.2 TLSv1.3;. On a CDN or load balancer (Cloudflare, CloudFront, ALB), set the minimum TLS version in the console — that one setting fixes every origin behind it.
• Ciphers: apply the Mozilla intermediate configuration; regenerate it when you upgrade your server.
• Redirect: force HTTPS at the edge, then add HSTS.

While you are cleaning up DNS, your email records deserve the same pass — see SPF, DKIM, and DMARC explained.

How BoringSec checks this

BoringSec’s SSL scanner does not just read your certificate — it performs a real TLS handshake and actively probes what your server accepts, around 13 checks in total: certificate validity and chain trust, expiry with graduated severity (critical if expired, high under 30 days, medium under 60), hostname/SAN match, key strength, signature algorithm, certificate transparency, TLS 1.3 and 1.2 presence, TLS 1.0/1.1 enabled (critical/high), weak cipher suites, and the HTTP-to-HTTPS redirect. Recommendations reference the Mozilla Server-Side TLS guidelines.

Findings are evidence-first: a critical or high finding without captured proof is auto-downgraded to medium. When a critical is confirmed — an expired certificate is one — it caps your Security Score at 30 out of 100, because no headline number should look healthy above that. Grading details are in the methodology.

FAQ