How to fix the modern clients cannot connect advisory

The modern_client_incompatible advisory is the most urgent advisory CertTracker fires. It means the endpoint accepts neither TLS 1.2 nor TLS 1.3 — every real browser and most modern clients will refuse to connect, regardless of how valid the certificate is.

What triggers the advisory

During a poll, CertTracker tries to negotiate TLS 1.3, then TLS 1.2. If both fail and the only successful handshake (if any) is on TLS 1.0 or 1.1, the advisory fires. In practice this means:

• The server is configured to accept only TLS 1.0 / 1.1 (deliberately disabled the modern protocols), or
• The cipher list configured is so narrow that no shared cipher exists for TLS 1.2/1.3 negotiation, or
• The TLS library on the server is so old it doesn't implement TLS 1.2 at all.

Why it matters urgently

If users are reporting "the site is down" but the server says it's up, this is the likeliest cause.

Fix

The fix is the same as the weak cipher / deprecated protocol article — enable TLS 1.2 and TLS 1.3 with a modern cipher list. Follow that article for the per-server config snippets.

The key difference: this advisory means TLS 1.2/1.3 aren't just deprioritized, they're missing entirely. After applying the recommended modern config, do an explicit positive check:

# Should SUCCEED:
openssl s_client -connect your-host.example.com:443 -tls1_2 < /dev/null
openssl s_client -connect your-host.example.com:443 -tls1_3 < /dev/null

If either one still fails, the server config didn't take effect. Common reasons:

• OpenSSL version too old — TLS 1.3 requires OpenSSL 1.1.1+ (released September 2018). If you're on a vintage build, upgrading the system openssl is unavoidable.
• Cipher list excludes all TLS 1.2/1.3 ciphers — even if ssl_protocols TLSv1.2 TLSv1.3; is set, an overly restrictive ssl_ciphers line can leave no actual cipher suites to negotiate. Replace your cipher list with the modern one from the weak-cipher article.
• Config file not reloaded — nginx -t passing doesn't mean a config was applied. Make sure your reload actually ran (sudo systemctl reload nginx).

Verify the fix

1. Test from outside your network — Qualys SSL Labs will explicitly call out missing TLS 1.2 support in red. Aim for at least one TLS 1.2 cipher suite supported and TLS 1.3 enabled.

2. Re-scan in CertTracker. Trigger a re-scan from the CertTracker UI. The fastest path: open the monitor's detail modal (click the monitor row on the Monitors page), scroll to the Active Advisories section, and click the orange ⟳ Re-scan button on the right side of the section header. The status line below the header will confirm the cert re-poll and TLS audit are queued; the next 5-minute poller tick (within ~5 minutes) runs both, and the advisory clears if your fix took. See Where to find these buttons in the UI for visual landmarks. This advisory clears as soon as either TLS 1.2 or TLS 1.3 succeeds in negotiation.

Special case: deliberate TLS 1.0/1.1-only legacy systems

Some legacy systems — embedded devices, ancient enterprise software — only support TLS 1.0 / 1.1 and cannot be upgraded. If you're knowingly running such a system and don't expose it to modern browser clients, the right answer is:

1. Restrict access (VPN, firewall, IP allowlist) so it isn't on the public web.
2. Document the exception.
3. Acknowledge the advisory in the CertTracker monitor detail modal — that suppresses the recurring email until the cert changes or new advisories fire.

Don't ignore it just because it's noisy. Acknowledging is the deliberate way to say "yes, we know, and yes, it's intentional."

Related advisories

• Weak cipher or deprecated protocol — same root cause, less catastrophic outcome.

Back to the TLS hardening hub.