SSL/TLS Misconfigurations That Put Your Site at Risk

HTTPS is binary to most visitors — the padlock is either there or it is not. To an attacker, TLS is a spectrum. A certificate can be valid and trusted while the configuration behind it still allows downgrade attacks, leaks across subdomains, or breaks silently next month when it expires. Here is what a scan looks for beyond "is it HTTPS".

Certificates that are about to expire

Expiry is the most common and most avoidable TLS incident. With certificate lifetimes shrinking, manual renewal is no longer realistic. Automate issuance and renewal (ACME / Let's Encrypt or your platform's managed certificates) and alert well before the expiry date, not on it. A scan surfaces the days-remaining so a short-lived cert does not surprise you.

Incomplete certificate chains

A server that sends its leaf certificate but omits the intermediate will work in your browser — because your browser already cached the intermediate — and fail for someone else's. This is the classic "works for me" TLS bug. Always serve the full chain:

openssl s_client -connect example.com:443 -servername example.com -showcerts

If the output shows only one certificate, your chain is incomplete.

Weak protocols and ciphers still enabled

TLS 1.0 and 1.1 are deprecated and should be disabled; so should export-grade and RC4 ciphers. Modern guidance:

• Support TLS 1.2 and TLS 1.3 only.
• Prefer forward-secret suites (ECDHE).
• Disable RC4, 3DES and anything labeled EXPORT.
• Turn on OCSP stapling to speed up revocation checks.

Mixed content on HTTPS pages

An HTTPS page that pulls a script, stylesheet or image over http:// gives an attacker a foothold on an otherwise secure page — and browsers will block the active parts anyway, breaking your UI. Find and fix every absolute http:// reference, or let the browser upgrade them:

Content-Security-Policy: upgrade-insecure-requests

No HTTP-to-HTTPS redirect

If http://yoursite.com serves content instead of redirecting, every first visit is a plaintext request. Redirect all HTTP to HTTPS with a 301/308, then enforce it with HSTS so the browser never tries HTTP again (see mistake #1 in the security headers guide).

Wildcard certificates stretched too far

One *.example.com certificate across unrelated services means one stolen private key compromises all of them. Convenient, but it widens the blast radius. Scope certificates to the services that actually need to share them.

Check it continuously, not once

TLS configuration drifts: a new subdomain, a load balancer swap, a forgotten renewal. Fold a TLS check into the same cadence you use for headers — How to Read a Website Security Scan Report covers turning these findings into a weekly plan, and the pricing page shows the scan limits for keeping it scheduled.