SSL/TLS Misconfigurations That Silently Leave Your Website Exposed

Your website has HTTPS. There is a padlock in the browser. You paid for an SSL certificate and installed it. Security handled, right?

Not even close. The presence of HTTPS tells you almost nothing about the quality of your TLS configuration. Beneath that padlock, your server might be negotiating weak ciphers, supporting deprecated protocols, or misconfigured in ways that undermine the entire purpose of encryption.

Why is the padlock not a security guarantee?

The browser padlock means that an encrypted connection was established between the browser and your server. It does not mean:

• The encryption is strong enough to resist interception
• The certificate chain is properly configured
• Deprecated protocols are disabled
• The server is not vulnerable to known TLS attacks
• All resources on the page are served over HTTPS

Many websites with valid certificates have TLS configurations that a competent attacker can exploit. Here are the most common misconfigurations we encounter.

Why are deprecated TLS versions still a problem?

TLS 1.0 and TLS 1.1 have known vulnerabilities and are deprecated by all major browser vendors and standards bodies. Yet many servers still accept connections using these protocols for backward compatibility.

If your server negotiates TLS 1.0 with a client, that connection is vulnerable to attacks like BEAST and POODLE. Even if modern browsers default to TLS 1.3, an attacker performing a man-in-the-middle attack can force a protocol downgrade, because every protocol your server accepts is part of its attack surface.

Fix: Disable TLS 1.0 and 1.1 entirely. Support only TLS 1.2 and TLS 1.3. The percentage of legitimate traffic that requires older protocols is negligible in 2026.

How do weak cipher suites undermine your encryption?

Even with TLS 1.2, the security of the connection depends on which cipher suite is negotiated. Cipher suites using RC4, DES, 3DES, or export-grade encryption are weak and should never be offered.

Additionally, cipher suites without forward secrecy mean that if your server's private key is ever compromised, all past recorded traffic can be decrypted retroactively. This is not a theoretical risk. Intelligence agencies and advanced attackers are known to record encrypted traffic for future decryption.

Fix: Configure your server to prefer AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) with ECDHE key exchange. Disable all cipher suites that lack forward secrecy.

What goes wrong with certificate chains?

A properly configured certificate chain includes your server certificate, all intermediate certificates, and leads to a trusted root CA. Missing intermediate certificates cause validation failures in some clients while working fine in others, creating inconsistent security.

Common certificate chain problems:

• Missing intermediates: Your certificate works in Chrome (which fetches missing intermediates) but fails in other clients.
• Wrong order: Certificates are sent in the wrong order, causing unnecessary validation overhead and potential failures.
• Expired intermediates: The intermediate CA certificate has expired, even though your server certificate is still valid.
• Cross-signed confusion: Multiple certificate paths exist, and some clients follow a path that leads to an expired root.

What happens when HSTS is missing?

HTTP Strict Transport Security (HSTS) tells browsers to always use HTTPS for your domain. Without it, users are vulnerable to SSL stripping attacks during their first visit or if they type your URL without https://.

An attacker on the same network can intercept the initial HTTP request and prevent the redirect to HTTPS. The user's browser communicates in plaintext, and the attacker proxies the connection to your HTTPS site. The user sees no padlock but may not notice.

Fix: Add the Strict-Transport-Security header with a long max-age. Consider HSTS preloading for maximum protection.

Why does mixed content matter?

Your page loads over HTTPS, but some resources like images, scripts, or stylesheets load over HTTP. This is mixed content, and it undermines the security of the entire page. An attacker can modify the HTTP-loaded resources to inject malicious content into your otherwise secure page.

Modern browsers block mixed active content (scripts, iframes) but may still allow mixed passive content (images). Both are problems.

How should you manage certificate expiration?

It sounds basic, but certificate expiration remains one of the most common causes of HTTPS outages and security warnings. Automated certificate management through Let's Encrypt or your cloud provider's certificate manager should be standard practice. And as with any asset, you cannot protect certificates you do not know exist, so keep an inventory of every domain and subdomain that serves TLS.

Beyond expiration, monitor your certificates for:

• Certificates about to expire within 30 days
• Certificates issued by authorities you do not recognize (potential compromise)
• Wildcard certificates that cover more domains than intended
• Certificates with weak key sizes (RSA below 2048 bits)

Which misconfigurations pose the biggest risk?

Here is how the common SSL/TLS misconfigurations map to exposure:

How do you audit your TLS configuration?

Manual TLS auditing is tedious and error-prone. OnScanner's automated SSL/TLS and configuration analysis evaluates your server's protocol support, cipher suite configuration, certificate chain validity, and security headers on every scan, live and never from cache. It identifies exactly which misconfigurations exist and what risk they pose.

Automated checks catch the configuration flaws. To understand how a TLS weakness combines with application-level issues into a real attack path, a manual penetration test puts a human adversary against the full stack. Transport security is one layer of a broader program, and our complete guide to web application security testing shows where it fits.

Do not assume the padlock means you are secure. Verify it.

Frequently asked questions

Does a valid SSL certificate mean my site is secure?

No. A valid certificate only proves that a certificate authority vouched for your domain and that browsers can establish an encrypted session. Your server can still accept deprecated protocols, negotiate weak ciphers, serve a broken chain, or omit HSTS, and each of those weaknesses can be exploited while the padlock displays normally.

Which TLS versions should my server support in 2026?

Support only TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 are deprecated by all major browsers and standards bodies and carry known vulnerabilities. The share of legitimate traffic that still requires the older protocols is negligible, while every deprecated protocol you leave enabled remains a downgrade path an attacker can force a connection onto.

How often should I check my TLS configuration?

Continuously, or at minimum after every infrastructure change. Certificates expire, intermediates get rotated, load balancers get reconfigured, and a CDN update can silently change your cipher order. Automated monitoring that rescans your TLS setup and alerts on expiring certificates within 30 days, new weak ciphers, or unexpected issuers turns a silent failure mode into a routine maintenance task.