Encryption in transit is supposed to be the easy part of web security. You install a certificate, redirect HTTP to HTTPS, and move on. In practice, a TLS misconfiguration is one of the most common reasons a site fails a security audit — not because TLS is broken, but because the settings around it drift, expire, or were never hardened in the first place.
Auditors and automated scanners look at far more than "is there a padlock." They inspect the certificate, the chain behind it, the protocol versions you negotiate, the cipher suites you accept, and the security headers you send. A weakness in any one of these maps directly to the OWASP Top 10 (2025) Cryptographic Failures category and can sink an otherwise clean report.
This post walks through the TLS/SSL issues that fail audits, why each is a risk, and how to remediate them.
The TLS Misconfigurations Auditors Flag Most
Here's a quick reference before we dig into each one.
| Issue | Why it's a risk | How to fix |
|---|---|---|
| Expired or soon-to-expire certificate | Browsers hard-fail the connection; users hit interstitial errors and traffic drops to zero | Automate renewal; alert weeks ahead of expiry |
| Hostname / SAN mismatch | The cert doesn't cover the domain served, so clients reject it as untrusted | Issue a cert that lists every served hostname in the SAN field |
| Incomplete certificate chain | Some clients can't build a path to a trusted root and fail validation intermittently | Serve the full chain including all intermediates |
| Deprecated protocols (SSLv3, TLS 1.0/1.1) | Vulnerable to known attacks (POODLE, BEAST); fails PCI DSS and most baselines | Disable them; require TLS 1.2 minimum, prefer TLS 1.3 |
| Weak or insecure cipher suites | RC4, 3DES, export and NULL ciphers offer little real protection | Allow only strong AEAD ciphers; disable legacy suites |
| Missing HSTS | Leaves a window for SSL-stripping downgrade attacks on the first request | Send a Strict-Transport-Security header with a long max-age |
| Mixed content | An HTTPS page loading HTTP resources can be tampered with in transit | Serve every asset over HTTPS; audit hardcoded http:// URLs |
Certificate problems: expiry, mismatch, and broken chains
The certificate itself is the first thing checked, and it fails audits in three predictable ways.
- Expiry. An expired certificate is the most visible failure mode because it takes the site down. Modern browsers refuse to proceed, and there is no graceful degradation. Certificate lifetimes keep shrinking, so the renewal you set up last year may already need to run more often.
- Hostname mismatch. If the certificate's Subject Alternative Name (SAN) list doesn't include the exact hostname being served — for example you serve
www.example.combut the cert only listsexample.com— clients treat it as invalid. - Incomplete chain. Servers must present the leaf certificate and the intermediate certificates that link it to a trusted root. Leave the intermediates out and some clients fail validation while others succeed, producing the maddening "works in my browser" bug.
Remediation: automate issuance and renewal, include every served hostname in the SAN, and always deploy the full chain. Verify from outside your network, where missing intermediates actually surface.
Deprecated protocol versions
SSLv3, TLS 1.0, and TLS 1.1 are retired for good reason. They carry structural weaknesses — POODLE against SSLv3, BEAST against TLS 1.0 — that no amount of cipher tuning fully resolves. Continuing to accept them fails PCI DSS and essentially every modern hardening baseline, even if no client of yours still needs them.
Remediation: require TLS 1.2 as a hard minimum and enable TLS 1.3 wherever possible. TLS 1.3 drops the obsolete primitives entirely and negotiates faster, so it improves both security and performance.
Weak and insecure cipher suites
A modern protocol version doesn't help if the server still offers weak ciphers. Suites built on RC4, 3DES, or anything with EXPORT or NULL in the name provide little meaningful protection and are routinely flagged. The goal is forward secrecy and authenticated encryption (AEAD) — ECDHE key exchange with AES-GCM or ChaCha20-Poly1305.
Remediation: trim your cipher list to a small set of strong AEAD suites and remove the legacy ones. Prefer server cipher ordering so a client can't negotiate down to the weakest option you happen to allow.
Missing HSTS
HTTP Strict Transport Security tells browsers to only ever connect over HTTPS for your domain. Without it, a user's very first request can be made over plain HTTP and intercepted in an SSL-stripping attack before the redirect to HTTPS ever happens. Auditors flag a missing or weak Strict-Transport-Security header as an easy, high-value gap.
Remediation: send Strict-Transport-Security: max-age=31536000; includeSubDomains. Add preload and submit to the preload list only once you're confident every subdomain is HTTPS-only, since it's hard to undo.
Mixed content
Mixed content is an HTTPS page that pulls in scripts, stylesheets, images, or fonts over plain HTTP. The page looks secure, but those sub-resources travel unprotected and can be modified in transit — a real risk for active content like scripts. Browsers now block the most dangerous forms outright, which can quietly break your page.
Remediation: serve every resource over HTTPS. Hunt down hardcoded http:// URLs in templates, CSS, and third-party embeds, and use a Content-Security-Policy to surface anything you miss.
Why continuous scanning beats a point-in-time check
TLS configuration is not static. Certificates expire on a clock. A new vendor script introduces mixed content. An infrastructure change re-enables an old protocol. A configuration that passed an audit in January can fail in March without anyone touching it deliberately.
The expiry case is the clearest argument for continuous monitoring: a certificate that's valid today but lapses next week passes a one-time scan and then takes your site down. Catching that before the outage is purely a function of how often you look.
This is where automated, scheduled scanning earns its place. NANOTESTING performs a real TLS handshake and certificate inspection on every web scan — checking validity and expiry, chain completeness, protocol versions, cipher strength, HSTS, and mixed content — and maps findings to OWASP and other frameworks with an A–F grade. Crucially, when a check can't run, it's reported as an honest coverage gap, never quietly counted as a pass, so you're never misled into thinking you're covered when you aren't.
Conclusion
Most TLS audit failures aren't exotic. They're an expired certificate, a missing intermediate, a leftover TLS 1.0 endpoint, a weak cipher, an absent HSTS header, or a stray HTTP asset on a secure page. Each maps to a concrete risk, and each has a well-understood fix.
Work through the table above, then make the check recurring rather than one-off. A TLS misconfiguration that's caught the day it appears is a quick config change; the same issue caught by a customer — or by an attacker — is an incident. Continuous scanning turns the first outcome into the default.