Wiki / TLS Hardening

Fixing CertTracker advisories: a TLS hardening guide for Apache, Nginx, and IIS

Last updated

Fixing CertTracker advisories: a TLS hardening guide for Apache, Nginx, and IIS

CertTracker flags nine distinct TLS advisories on the endpoints it monitors. Each advisory points to a real configuration issue on the server — a deprecated protocol still enabled, a weak cipher still offered, a hostname missing from a SAN list. None of them affect whether the certificate is valid; they affect whether the server is configured well around that certificate.

This guide is the index. Click through to the advisory you're seeing on a monitor for the specific fix instructions on Apache, Nginx, IIS, and several other common stacks.

The full advisory list

Advisory What it means Article
Weak cipher or deprecated protocol Server negotiates SSL/TLS versions or cipher suites that are no longer considered secure (TLS 1.0/1.1, RC4, 3DES, etc.). Fix weak ciphers and deprecated TLS protocols
Weak signature algorithm The certificate itself is signed with MD5, SHA-1, or another hash modern browsers no longer trust. Fix weak signature algorithm
Excessive validity period Certificate's NotAfter − NotBefore span exceeds the 398-day public-trust maximum. Fix excessive certificate validity
Hostname mismatch The monitored hostname isn't listed in the certificate's CN or SAN. Fix hostname mismatch
Modern clients cannot connect The endpoint refuses both TLS 1.2 and TLS 1.3 — every modern browser will reject it. Fix modern client incompatible
OCSP stapling not enabled Server is not stapling OCSP responses, forcing clients into per-connection CA round-trips. Fix OCSP stapling
HSTS header missing Site serves HTTPS but does not emit a Strict-Transport-Security header. Fix missing HSTS header
HSTS max-age too short HSTS header is present, but its max-age is below your company's configured threshold. Fix HSTS max-age too short

A note on triage order

If a single endpoint has multiple advisories firing at once, fix them roughly in this order — earlier ones often block later ones:

  1. Modern clients cannot connect — nothing else matters if real browsers can't reach the site.
  2. Weak cipher / deprecated protocol — the typical root cause of "modern clients cannot connect," and the most common single advisory.
  3. Hostname mismatch — usually requires reissuing the certificate, so it has the longest fix lead time.
  4. Weak signature algorithm — also usually requires reissuance, but the leaf only (intermediates are handled by the CA).
  5. Excessive validity period — reissuance with a shorter requested span.
  6. OCSP stapling — server config only, no cert change needed.
  7. HSTS missing / too short — application or reverse-proxy header tweak, no cert change needed.

How CertTracker surfaces these

Advisories are detected by a deep TLS audit that runs asynchronously once every 24 hours per monitor — separate from the every-5-minute cert poll. When you're working on a fix and don't want to wait a full day to see if it took, click Force Poll in the monitor detail modal: it triggers an immediate re-audit alongside the cert re-poll, and the Active Advisories list updates within minutes. Acknowledge resolved advisories from the same modal.

To get emails when advisories fire, go to Administration → Alert Addresses → Manage Advisory Alerts and toggle the categories you want. Multiple advisories on the same monitor coalesce into a single digest email so you're not spammed when fixing a server reveals four overlapping issues.

Where to find these buttons in the UI

Two CertTracker buttons matter when you're working on a fix. They live in different places:

Force Poll — a small cyan-outlined circular-arrow icon (⟳) on each monitor's row in the Monitors list, at the right end of the row (next to the Edit, Pause, and Delete icons). It only renders for monitors whose poll interval is not 5 minutes — 5-minute monitors poll often enough that a dedicated force button is redundant. Clicking it queues the monitor to be re-polled on the next 5-minute poller tick, regardless of its configured interval. As of this release, it also re-runs the deep TLS audit, so the Active Advisories list refreshes on the same cycle.

Re-scan — an orange-outlined button labeled ⟳ Re-scan inside the monitor detail modal, in the right end of the Active Advisories section header. It's visible only when the monitor has at least one unacknowledged advisory — i.e. exactly when you'd want it. Click a monitor row to open the detail modal, scroll to the Active Advisories section (below TLS & Hostname Match), and the button is on the right side of the section title. It works on every poll interval, including 5-minute monitors. Clicking it does the same thing as Force Poll plus the audit re-run, and the status line below the header confirms the request was queued.

When you're actively iterating on a server-config fix and want to test repeatedly, Re-scan is the right button — it scopes the action to the monitor you're already looking at and is always visible when advisories are firing.

Testing externally

Every fix in these articles ends with a verification step. We recommend testing your changes from outside your network using one of:

  • Qualys SSL Labs (ssllabs.com/ssltest/) — comprehensive, slow, gives you an A through F grade. Use this when you want the full picture.
  • testssl.sh (testssl.sh) — open-source command-line tool that runs the same kind of audit locally. Great for internal endpoints SSL Labs can't reach.
  • openssl s_client — quick one-shot checks of a specific protocol or cipher. Examples are in each per-advisory article.

After any change, force a re-poll in CertTracker (monitor detail modal → Force Poll) and confirm the advisory clears on the next scheduled poll, usually within five minutes.