How to Audit TLS Configuration: What Your Security Scanner Should Check in 2026

Why TLS Auditing Still Matters in 2026

You might assume TLS is a solved problem. Let's Encrypt made free certificates ubiquitous. Browsers enforce HTTPS. TLS 1.3 is widely deployed. So why does A02 remain in the OWASP Top 10?

Because deployment is not the same as correct deployment. Here's what we see in practice:

• Legacy protocol support: Many servers still accept TLS 1.0/1.1 connections alongside 1.2/1.3 for "backward compatibility." This enables downgrade attacks.
• Certificate lifecycle failures: Auto-renewal works until it doesn't. A misconfigured cron, a DNS change, or a load balancer swap can silently break renewal. The cert expires, and nobody notices until users start seeing browser warnings — or worse, until an attacker exploits the gap.
• Missing HSTS: Even sites with valid TLS often skip the Strict-Transport-Security header, leaving users vulnerable to SSL stripping on their first visit.
• Inherited configurations: Server configs get copied from Stack Overflow answers written in 2018. The cipher suite list includes RC4 "just in case." Nobody audits it because "HTTPS is working."

A proper TLS audit catches all of these. Let's walk through each check.

Check 1: TLS Protocol Version

What to Check

Connect to the target and identify which TLS protocol version the server negotiates. Flag any connection that uses:

• SSLv3 — Vulnerable to POODLE. Deprecated since 2015 (RFC 7568).
• TLS 1.0 — Vulnerable to BEAST, Lucky13. Deprecated since 2021 (RFC 8996). PCI DSS non-compliant since 2018.
• TLS 1.1 — No known critical vulnerabilities, but deprecated by RFC 8996 alongside TLS 1.0. All major browsers dropped support by 2020.

What Good Looks Like

The server should negotiate TLS 1.2 or TLS 1.3 exclusively. TLS 1.3 is preferred — it removed all legacy cipher suites, eliminated the RSA key exchange (which lacks forward secrecy), and reduced the handshake to a single round trip.

Why It Matters

Even if a server supports TLS 1.3, accepting TLS 1.0 connections means an attacker can force a downgrade. The attacker intercepts the initial handshake and modifies the client's supported versions list to only include TLS 1.0, then exploits the weaker protocol. This is not theoretical — downgrade attacks are well-documented and tooled.

Check 2: Cipher Suite Strength

What to Check

After the TLS handshake, examine the negotiated cipher suite. Flag any suite containing these weak components:

What Good Looks Like

For TLS 1.2, use only AEAD cipher suites: AES-128-GCM, AES-256-GCM, or ChaCha20-Poly1305. Prefer ECDHE key exchange for forward secrecy. TLS 1.3 solves this by design — it only supports strong AEAD ciphers and removed all legacy options.

Why It Matters

A weak cipher suite means the encryption protecting your users' data can be broken. Even if the server prefers strong ciphers, supporting weak ones means an attacker can force their use via a downgrade attack. The fix is simple: remove weak ciphers from the server configuration entirely.

Check 3: Certificate Validity

What to Check

Two certificate issues matter most:

Expired certificates. Extract the notAfter field from the server's certificate and compare it to the current time. An expired certificate means browsers will show a full-page warning, users will either leave or click through (training them to ignore security warnings), and automated clients may fail silently.

Self-signed certificates. Compare the certificate's subject and issuer fields. If they're identical, the certificate is self-signed. Self-signed certs provide encryption but zero identity verification — any attacker can generate one for any domain. Browsers show a warning, but users who click through have no protection against man-in-the-middle attacks.

What Good Looks Like

A valid certificate from a trusted CA (Let's Encrypt, DigiCert, Sectigo, etc.) with at least 30 days until expiry. Certificate transparency logs should show the cert. Wildcard certificates are acceptable but should be monitored for scope creep.

Why It Matters

Certificate expiry is the most common TLS finding in external penetration tests — not because it's hard to fix, but because auto-renewal fails silently. The certificate was valid when deployed. The renewal cron ran for months. Then a DNS provider change, a server migration, or a load balancer swap broke the ACME challenge, and nobody noticed until the cert expired. Automated monitoring catches this before users do.

Check 4: HSTS Header

What to Check

Make an HTTPS request to the target and check for the Strict-Transport-Security response header. A missing HSTS header is a finding.

What Good Looks Like

The response should include:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000 — enforce HTTPS for 1 year
• includeSubDomains — apply to all subdomains (prevents subdomain-based attacks)
• preload — eligible for browser preload lists (eliminates the first-visit vulnerability entirely)

Why It Matters

Without HSTS, a user's first visit to your site (or any visit via an HTTP link) goes over plaintext HTTP before being redirected to HTTPS. During that brief window, an attacker on the same network can intercept the request and serve a fake HTTP version of the site — this is the classic SSL stripping attack demonstrated by Moxie Marlinspike in 2009 and still effective against sites without HSTS in 2026.

HSTS with preloading is the only complete fix. Once a domain is on the browser preload list, the browser will never make an HTTP request to it — even on the very first visit.

Putting It Together: A Severity Model

Not all TLS findings are equal. Here's how to classify them:

This model matches SecurityClaw's tls-crypto-auditor severity classification. The key insight: stack findings. A server with TLS 1.0 support AND a weak cipher AND missing HSTS has three separate issues, each independently fixable. Report them individually so the remediation team can prioritize.

Common Misconfigurations Found in the Wild

These are the patterns that show up repeatedly in real-world TLS audits:

1. The "Backward Compatibility" Trap

The server admin enables TLS 1.0 because "some old clients might need it." In practice, no legitimate client in 2026 requires TLS 1.0. Every modern browser, mobile OS, and API client supports TLS 1.2 at minimum. The only "clients" that benefit from TLS 1.0 support are attackers performing downgrade attacks.

2. The Load Balancer Blind Spot

The application server has perfect TLS configuration, but the load balancer or CDN in front of it terminates TLS with a different (weaker) configuration. The security team audits the application server directly and sees TLS 1.3. Users connect through the load balancer and get TLS 1.0. Always audit the endpoint that users actually connect to.

3. The Forgotten Certificate

Let's Encrypt auto-renewal works perfectly on the primary domain. But the staging environment, the API subdomain, or the legacy admin panel on a different server has a certificate that was manually installed two years ago. It expired six months ago. Nobody noticed because nobody visits it directly — but it's still in DNS and still accepting connections.

4. HSTS on the Main Domain Only

The main site sends HSTS headers, but subdomains don't. Without includeSubDomains, an attacker can SSL-strip a subdomain and use it as a pivot point. Cookie scope issues make this especially dangerous — cookies set for .example.com are sent to all subdomains, including the one the attacker is intercepting over HTTP.

5. The Self-Signed Internal Service

Internal APIs use self-signed certificates because "it's internal." But internal doesn't mean safe — lateral movement after initial compromise is the standard attack pattern. Self-signed certs on internal services mean an attacker who gains network access can trivially MITM internal API traffic. Use a private CA instead.

How to Fix Each Issue

Disable Weak Protocols (Nginx)

# nginx.conf — only allow TLS 1.2 and 1.3
ssl_protocols TLSv1.2 TLSv1.3;

Disable Weak Protocols (Apache)

# httpd-ssl.conf
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Set Strong Cipher Suites (Nginx)

# AEAD ciphers only — no RC4, DES, NULL, EXPORT, MD5
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;

Fix Certificate Expiry

If using Let's Encrypt with certbot:

# Test renewal
sudo certbot renew --dry-run

# Check certificate expiry
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Set up monitoring: check certificate expiry daily and alert when less than 30 days remain. Don't rely solely on auto-renewal — verify it's actually working.

Enable HSTS

# Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# Apache
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Start with a short max-age (e.g., 300 seconds) to test, then increase to 31536000 (1 year) once confirmed working. Submit to hstspreload.org for browser preload list inclusion.

The Bottom Line

TLS auditing is four checks: protocol version, cipher suite, certificate validity, and HSTS. That's it. None of them are complex. All of them are automatable. And yet A02 (Cryptographic Failures) remains in the OWASP Top 10 because most organizations don't audit these systematically.

The gap isn't knowledge — it's automation. Security teams know TLS 1.0 is bad. They know expired certs are bad. They know HSTS matters. What they lack is a scanner that checks all four on every target, every time, and classifies the findings with actionable severity levels.

SecurityClaw's tls-crypto-auditor skill does exactly this — it connects to the target, enumerates the TLS configuration, checks the certificate, verifies HSTS, and produces findings with severity classifications that map directly to remediation priorities. It runs as part of every campaign automatically, so A02 coverage is no longer something you have to remember to check.

Whether you use SecurityClaw, OWASP ZAP, Nuclei, or a custom script — make sure TLS auditing is part of your automated scanning pipeline. Four checks. Zero excuses.