SSL/TLS Misconfigurations

What it is

TLS (still commonly called SSL in casual usage) is the encryption layer that protects almost all web traffic, mail submission, API calls, and a long list of other protocols. A "TLS misconfiguration" is any deviation from current best practice on any of the moving parts:

• Certificate validity. Expiry dates, the chain of trust, the matching of certificate names to hostnames.
• Protocol versions. TLS 1.2 and 1.3 are the current standards. SSLv2, SSLv3, TLS 1.0, and TLS 1.1 are deprecated and should not be supported.
• Cipher suites. RC4, DES, 3DES, and other weak primitives. Export-grade ciphers. Anonymous Diffie-Hellman.
• Key strength. RSA keys below 2048 bits, weak elliptic curves.
• Forward secrecy. Cipher suites that do not provide forward secrecy let an attacker who later compromises the private key decrypt past traffic.
• HSTS, CAA, and supporting policy. The DNS and HTTP-level controls that complement the TLS handshake itself.
• Certificate transparency. Every public certificate is logged. Watching the log is half of certificate hygiene.

A modern TLS audit on a large external surface usually finds dozens of small issues across hundreds of endpoints. None of them on its own is a headline. Together they shape the organisation's overall posture.

Why it matters

The visible business impact of TLS issues is asymmetric. Most problems sit quietly until something breaks publicly.

• Certificate expiry breaks production. When a customer-facing certificate expires unnoticed, browsers display a full-page warning. Customers cannot log in. APIs fail. Calls flood support. Notable expiries have taken down Microsoft Teams, Pinterest, Cisco, Spotify, and many others over the years. The fix takes minutes; the credibility damage takes longer.
• Compliance failures. PCI DSS specifically prohibits TLS 1.0 and weak ciphers on any system handling cardholder data. ISO 27001 and SOC 2 audits regularly flag weak TLS as a finding.
• Decryption attacks against weak crypto. POODLE (SSLv3), BEAST (TLS 1.0), CRIME and BREACH (compression), Lucky 13, FREAK, Logjam, ROBOT, and the broader DROWN family all exploited weaknesses in older TLS configurations. Modern attacks recycle these against the long tail of unpatched and misconfigured endpoints.
• Misissued certificates are a compromise indicator. A certificate showing up in a CT log for your domain that you did not request is a signal that something has gone wrong, possibly a compromised DNS account, a rogue insider, or a CA mistake.
• Trust signalling. Browsers, mail clients, and API consumers all make trust decisions based on certificate properties. Weak TLS makes the application look careless even if the underlying logic is sound.

A 2020 expiry incident on a major mobile carrier infrastructure component took payment systems offline for hours. The 2021 Let's Encrypt root expiry event broke devices across the internet, particularly older Android handsets and some embedded systems. These are not edge cases. They happen regularly, almost always because monitoring was inadequate.

How attackers exploit it

TLS misconfigurations open up a few distinct attack avenues.

Downgrade and protocol attacks. When a server still supports TLS 1.0 alongside TLS 1.2, an active attacker on the network can sometimes force the negotiation to the weaker version and then exploit known weaknesses. The same applies to weak cipher suites left enabled "for compatibility with old clients".

Decryption of captured traffic. Without forward secrecy, an adversary who records encrypted traffic and later obtains the private key (through compromise, legal process, or any other route) can decrypt the recorded sessions. State-level actors and advanced criminal groups are known to capture and store traffic for later analysis.

Certificate impersonation. Attackers who can obtain a certificate for a target's domain can perform man-in-the-middle attacks, particularly when DNS or BGP control is also available. Misissuance from compromised CAs has happened (DigiNotar in 2011 is the textbook case) and continues to be a concern.

Subdomain certificate abuse. Attackers obtaining a wildcard or a specific certificate for a subdomain in a takeover scenario gain a TLS-valid foothold under the trusted brand.

Information leakage. Certificate transparency logs are public. Defenders monitor them, and so do attackers. CT logs reveal the existence of new infrastructure (sometimes long before a launch is publicly announced), which is intelligence about upcoming targets, internal naming conventions, and project structures.

For most opportunistic attackers, TLS misconfigurations are not the first thing they look at, but they shape the overall difficulty of the target. A site with strong TLS, valid HSTS, and clean certificate hygiene is a harder target than one with a sprawl of weak configurations.

How to detect it

Detection has two halves: continuous scanning of live endpoints and continuous monitoring of certificate transparency logs.

Live endpoint scanning. For every external IP and hostname:

• Connect to TLS-using ports (443, 465, 587, 993, 995, plus any custom ports).
• Enumerate supported protocol versions.
• Enumerate supported cipher suites.
• Pull the full certificate chain.
• Check key size, signature algorithm, validity dates, and SAN entries.
• Check for HSTS, CAA, and supporting headers.

Tools like testssl.sh, sslyze, and SSL Labs (for one-off checks) cover this well. For continuous coverage at scale, the same approach can be scripted across an inventory.

Certificate transparency monitoring. Every certificate issued by a public CA gets logged in CT logs within hours. Services like crt.sh, Cert Spotter, and Facebook's CT tooling expose the data. Watch for:

• New certificates issued for your domains and subdomains.
• Certificates issued by CAs you do not normally use.
• Certificates with unusual validity windows or unfamiliar issuance patterns.
• Wildcard certificates issued to subdomain takeover-prone hostnames.

Specific findings to flag:

• Any certificate within 30 days of expiry without a renewal already in motion.
• Any certificate already expired (severity: critical, will be visibly broken).
• Hostname mismatches (the certificate covers the wrong name).
• Self-signed certificates on production endpoints.
• TLS 1.0 or 1.1 still enabled.
• RC4, 3DES, or export-grade ciphers in the supported list.
• Cipher suites without forward secrecy.
• RSA keys under 2048 bits.
• Missing or incomplete certificate chains.
• Mismatched intermediate certificates (causing some clients to fail).
• Missing CAA record (any CA can issue for your domain in principle).

How to remediate

The fixes are usually well-known, just not always prioritised:

1. Replace expiring certificates before they expire. Automate renewal with ACME (Let's Encrypt, ZeroSSL) or your CA's API where possible. Manual renewals get forgotten.
2. Disable deprecated protocols. Turn off SSLv2, SSLv3, TLS 1.0 and TLS 1.1 across all endpoints. Most modern clients will fall back gracefully to 1.2 or 1.3.
3. Tighten cipher suites. Modern guidance (Mozilla Modern config or equivalent) gives you a known-good cipher list. Apply it everywhere.
4. Enforce minimum key strength. RSA 2048 bits or higher. ECDSA on P-256 or P-384.
5. Require forward secrecy. Disable any cipher suite without ECDHE or DHE key exchange.
6. Publish a CAA record. Restrict which CAs can issue for your domain. This stops a wide class of misissuance attacks.
7. Enable HSTS with a long max-age. Optionally with preload submission for browsers to enforce it on first visit.
8. Address chain issues. Most "works in browser, breaks in mobile app" issues come from incomplete intermediate chains. Configure the full chain on every endpoint.
9. Investigate unexpected CT log entries. A certificate you did not request is not always malicious (vendors and partners sometimes issue under your domain with permission you forgot about) but it always deserves a look.
10. Standardise certificate management. A single source of truth, automated renewal, central monitoring. Spreadsheets and reminder calendars do not scale.

Best practices

• Treat TLS as a continuous control, not a project. Configurations drift. New endpoints appear. Certificates expire on their own schedule.
• Automate certificate issuance and renewal. ACME-based automation removes the most common cause of expiry incidents (humans forgetting).
• Monitor every external endpoint at least daily. Live scans against known IPs, plus CT log monitoring for new ones.
• Apply consistent TLS configuration profiles across all infrastructure. Pick a baseline (Mozilla Modern is widely used), document it, enforce it.
• Test client compatibility before tightening. A protocol or cipher disablement that breaks a small but real percentage of legitimate users will get rolled back. Validate before you ship.
• Watch for unmanaged certificate sources. Marketing platforms, CDN edges, third-party SaaS providers, and vendor-managed properties often issue certificates under your domain. Inventory them.
• Use short-lived certificates where possible. 90-day Let's Encrypt certificates with automated renewal are operationally simpler and reduce the window of exposure if a key is ever compromised.
• Review CAA, HSTS preload, and certificate inventory together once a quarter. Drift is invisible until you look for it.