What CertTracker Checks

Every poll of every monitor runs the same battery of checks. Some of those checks are always-on and surface as the primary status of the monitor; others are opt-in and surface as advisory alerts. This article walks through everything CertTracker looks at, what triggers each check, what you see in the UI, and what the email looks like.

At a glance

The "always detected" rows mean the condition is captured server-side on every poll, regardless of opt-in status. Opt-in only controls whether you get an email about it; the data is always available in the monitor detail view.

Always-on checks

1. Certificate expiration

The poller pulls the certificate chain at every interval and records the leaf's NotAfter. The notifier then watches that timestamp:

• More than 30 days out (or your custom threshold, if higher than 30): no email.
• 8–30 days out: weekly reminder.
• 2–7 days out: daily reminder.
• Final 24 hours: hourly reminder.
• Already expired: daily reminder.

The threshold is per-monitor (Edit monitor → Expiry threshold). It defaults to 30 days but can be raised to anything you like; the closer-in cadences kick in automatically once the cert enters those windows.

These emails cannot be turned off while the monitor exists. If you don't want to be alerted, pause the monitor.

2. Certificate change

When the leaf's SHA-256 fingerprint changes between two successive polls, CertTracker records the change to the change history and sends an alert. The monitor's status pill flips to Changed and stays there until someone clicks Mark Expected or Acknowledge as Issue from the email or the monitor detail modal. Until acknowledged, the email repeats once every 24 hours.

Renewals, re-issues, ACL changes — anything that produces a new leaf — show up here. The change history table lets you see the prior cert side-by-side with the new one.

3. Endpoint availability

For monitors on Business or Enterprise plans polling at 5-minute intervals, CertTracker tracks reachability separately from cert validity. If the TCP connect or TLS handshake fails:

• First failure: alert email sent immediately.
• Still down after 1 hour: one reminder.
• Subsequent: silent until recovery.
• Recovery: one "back online" email.

Availability is only tracked on the 5-minute interval — longer intervals make "is it down?" too unreliable to alert on. Below Business the field is collected but not surfaced as an alert.

Advisory checks (opt-in)

The advisory checks below are detected on every poll and stored in the database, but emails are only sent when the company has opted in via Administration → Alert Addresses → Manage Advisory Alerts. Toggle each one independently.

When opted in, advisories follow a once-per-day-per-monitor cadence until they're either resolved at the endpoint (the next successful poll clears the underlying condition) or acknowledged in the monitor detail modal. Multiple advisories on the same monitor coalesce into a single digest email.

4. Hostname mismatch

Triggers when the hostname being monitored is not listed in the certificate's Common Name or Subject Alternative Name (SAN) list, using strict RFC 6125 matching. Wildcard SANs are honored — *.example.com matches api.example.com but not example.com itself.

Common causes:
- Monitor was added with a typo in the hostname.
- A new cert was issued without the monitored hostname in its SAN list (often happens when an ops change misses a service in the cert request).
- The endpoint is serving a default vhost cert when a SNI-specific cert was expected.

5. Weak cipher or deprecated protocol

Triggers when the TLS handshake negotiates a cipher suite or protocol version that's no longer considered safe. Examples:

• Protocols: SSLv2, SSLv3, TLS 1.0, TLS 1.1
• Ciphers: RC4, RC2, DES, 3DES, EXPORT-grade, NULL, anonymous DH
• Key strength: DH key smaller than 2048 bits

When the handshake fails outright (server refuses the connection), CertTracker classifies the failure from the OpenSSL error string. There are some edge cases where the error text doesn't cleanly disambiguate "cipher rejected" from "protocol rejected" — both rc4.badssl.com and tls-v1-1.badssl.com return the identical SSLV3_ALERT_HANDSHAKE_FAILURE, for example. We err toward marking those as deprecated_protocol but it isn't always right; manual review of the cert detail modal will tell you what's actually being offered.

6. Weak certificate signature algorithm

Triggers when any certificate in the chain — leaf, intermediate, or root — is signed using a hash algorithm that's no longer trusted by major browsers: MD2, MD4, MD5, SHA-1, or RIPEMD. The chain is captured during the deep TLS audit (runs every 24 hours) and walked end-to-end; the advisory detail tells you exactly which position is weak so you can fix the right link.

The sha1-intermediate.badssl.com pattern (SHA-256 leaf chained off a SHA-1 intermediate) does fire this advisory.

7. Weak public-key size

Triggers when the leaf certificate's public key is below the minimum strength recommended by NIST SP 800-57 Part 1 Rev. 5 (Table 2) and required by the CA/Browser Forum Baseline Requirements §6.1.5:

• RSA and DSA — fewer than 2048 bits. RSA-2048 corresponds to roughly 112-bit symmetric-equivalent security and is the floor every publicly trusted CA will issue against. RSA-1024 is broken in practice.
• ECC (ECDSA / ECDH-based) — fewer than 256 bits. NIST P-256 / secp256r1 is the floor; older curves like P-192 / secp192r1 and P-224 / secp224r1 are below the modern bar.
• Ed25519 / Ed448 — always considered strong at their native field sizes; no advisory.

Public Key size and algorithm are visible in the monitor detail modal (e.g. RSA 2048-bit, EC 256-bit (secp256r1)). The advisory detail string names which family is too small and what the recommended minimum is, so it's clear what to upgrade to.

8. Excessive validity period

Triggers when the certificate's validity span (NotAfter − NotBefore) exceeds 398 days, the maximum that Apple and Chrome enforce for publicly trusted server certificates. Certs issued by a public CA that exceed this won't be trusted by modern browsers regardless of expiration date.

Private CAs are not bound by the 398-day rule, so on internal endpoints this advisory may not represent a real problem. It's still flagged because it usually points to a misconfigured cert request profile.

9. Modern clients cannot connect

Triggers when the endpoint accepts neither TLS 1.2 nor TLS 1.3 — only deprecated versions (1.0, 1.1, SSLv3). Real browsers refuse to connect to deprecated-only TLS endpoints regardless of cert validity, so users see connection errors. This is the signal that used to live in availability status before the poller dropped to SECLEVEL=0 to capture cert data even from these endpoints.

10. OCSP stapling not enabled

Triggers when the server is reachable but does not staple an OCSP response in the TLS handshake. Without stapling, every client has to make a separate OCSP round-trip to the CA on each connection — a privacy leak (the CA sees who's visiting) plus a measurable latency hit. On most server platforms enabling stapling is a one-line configuration change.

11. HSTS missing or too short

Two related triggers controlled by a single opt-in flag and a per-company minimum max-age (default 180 days, configurable in the Manage Advisory Alerts modal):

• HSTS missing — site responds over HTTPS but does not send a Strict-Transport-Security header at all. Without HSTS, an attacker can downgrade the first request to plain HTTP and capture credentials.
• HSTS max-age below configured minimum — the header is present but max-age= is shorter than the threshold you've set. The browser preload list requires at least 1 year (365 days); 6 months (180 days) is a common minimum.

The includeSubDomains and preload directives are reported in the TLS Audit panel but don't generate their own advisories.

How opt-in works

1. Go to Administration.
2. On the Alert Addresses card, click Manage Advisory Alerts.
3. Check the categories you want emails for. All four default to off.
4. Click Save preferences.

Once enabled, the next notifier pass (within minutes) will pick up any unacknowledged advisories on monitors in your company and send the digest emails. The poller doesn't need to re-detect — anything already in the database starts emailing immediately.

How acknowledgement works

Each advisory email has a Review & Acknowledge button that deep-links to the relevant monitor's detail view in the portal. On that view, every unacknowledged advisory has its own Acknowledge button. Clicking it:

• Marks the advisory as acknowledged in the database.
• Stops further email reminders for that specific advisory.
• Removes it from the detail modal's Active Advisories list.

If a future poll re-detects the same condition (because someone re-enabled TLS 1.1, say), a fresh advisory row is created and the alert cycle starts over. Acknowledgement only suppresses the currently-known instance.

You can also see the underlying TLS metadata (negotiated version, cipher, hostname-match status, handshake error) in the detail modal regardless of whether you've opted in to email alerts.

Informational fields (no advisories)

The TLS Audit panel surfaces four diagnostic fields derived from the audit data that don't generate advisory emails on their own — they're shown so an admin investigating an endpoint can see them at a glance:

• Server Cipher Pref — Whether the server enforces its own cipher-list ordering ("server-enforced", best practice) or follows whichever order the client offered ("client-controlled"). Determined by offering two known-accepted ciphers in opposite orders and comparing the server's pick.
• Session Resumption — Whether the server supports TLS session resumption via session tickets (RFC 5077) or session IDs (RFC 5246). When supported, repeat connections from the same client can skip the full handshake — meaningful latency improvement for repeat visitors.
• Forward Secrecy — "✓ all ciphers" (every accepted cipher uses DHE/ECDHE/X25519 key exchange, or is TLS 1.3 which is FS by spec), "partial" (some accepted ciphers are RSA-kex), or "✗ none" (server only accepts RSA-kex — every recorded session is decryptable if the long-term key later leaks).
• Compliance — Pass/fail roll-up against three industry standards: PCI-DSS 4.0 (TLS 1.2+ required, early TLS forbidden, strong ciphers only, no SHA-1 in chain), NIST SP 800-52r2 (TLS 1.2+, all ciphers must offer forward secrecy, no weak primitives), and Mozilla Modern (TLS 1.3 only, AEAD ciphers only). All derived server-side from data the poller already collects.
• CAA Records — DNS-published list of Certificate Authorities authorized to issue certs for the domain (RFC 8659). "✓ letsencrypt.org" means only LE may issue; if a cert was somehow obtained from a different CA the domain owner has an audit trail. "✗ no CAA records published" means any CA may issue. Looked up server-side via DNS; walks up the domain hierarchy per RFC.

How the deep audit runs

The audit probes (protocol versions, cipher suites, chain signatures, OCSP stapling, HSTS, cipher preference, session resumption) run once per 24h per monitor, piggy-backing on the regular poll cycle. They run in a background thread so they don't block the 5-minute cert-poll cadence even when a probe takes 30+ seconds against a slow or unresponsive endpoint.

The audit fires whenever the TCP connection succeeded (Status = Online), even on endpoints where the default-config TLS handshake failed. The probes are most useful on TLS-handshake-failure endpoints — they're how CertTracker discovers, say, that a server only accepts TLS 1.1 or only RC4 ciphers when the modern handshake bounces. The audit is skipped only when even the TCP connect fails (Status = Unreachable), since probes would just time out there.

A per-cycle cap (5 audits per 5-minute cycle by default) prevents a backfill or force-re-audit from spawning hundreds of concurrent threads.

What we do not check

CertTracker is a TLS observability tool, not a vulnerability scanner. We do not:

• Probe for specific CVEs (Heartbleed, BEAST, POODLE, etc.) beyond what shows up naturally in cipher/protocol negotiation.
• Test for CT log inclusion or DNS CAA records (CAA on the roadmap).
• Check HTTP response codes, response time SLAs at sub-minute granularity, or content correctness.
• Audit internal-only or non-TLS endpoints.

If any of those would be valuable to you, open a ticket — most of our roadmap comes from customer requests.