Skip to content
WatchTower15Docs

Security scanning

Uptime tells you a service answered. Security posture tells you whether the things attackers exploit — an expiring certificate, a silently changed DNS record, a lapsing domain registration — are healthy. WatchTower15 monitors that posture continuously as part of the same outside-in check fleet, and turns findings into alarms your team can act on.

What’s checked today

Section titled “What’s checked today”
Area What WatchTower15 watches Why it matters
SSL/TLS certificates Validity dates, days-to-expiry, issuer, self-signed and chain-valid flags, the certificate’s key and how many certificates the server presents. An expired or broken chain is an instant outage and a trust failure.
TLS protocols & ciphers Which TLS versions (1.0, 1.1, 1.2, 1.3) a domain accepts, the cipher each negotiates, and whether it accepts a weak cipher (RC4, 3DES, NULL, export-grade or anonymous). TLS 1.0 and 1.1 are deprecated, and a weak cipher or a short key weakens the encryption your visitors rely on.
DNS records & changes Full record set (A, AAAA, MX, TXT, CNAME, NS, SOA, CAA) with change detection between scans. An unexpected DNS change can mean a hijack, a misconfiguration, or an expired delegation.
Domain expiry Registration expiry, registrar and nameservers via WHOIS/RDAP. A lapsed registration is a catastrophic, entirely avoidable outage.
WHOIS / registrant changes Registrant and registrar detail, with change detection. A change to registrant or nameservers can be the first sign of a domain takeover.

Certificate health

Section titled “Certificate health”

The certificate check performs a live TLS handshake and extracts the chain — common name, issuer, validity window, computed days-to-expiry, and whether the certificate is self-signed or the chain fails to validate. It also reads the certificate’s key (type and size) and how many certificates the server presents. When an endpoint isn’t directly reachable for a handshake, it falls back to public Certificate Transparency logs, so you retain certificate visibility even for hosts you can’t probe directly. A certificate read from those logs has no protocol or cipher measurement, and its chain is not checked: the page says so.

A site that can only be reached over TLS 1.0 or 1.1, or only with an unencrypted (NULL) cipher, is still measured, but a modern browser could not connect to it, so its chain reads Invalid. A site that offers only RC4, 3DES, export-grade or anonymous ciphers can’t complete a handshake with the scanner at all, so its certificate and protocols read Not measured.

TLS protocols and ciphers

Section titled “TLS protocols and ciphers”

Once a certificate has been read, the same daily SSL scan measures how the domain negotiates TLS:

  • Protocols. One handshake each for TLS 1.0, 1.1, 1.2 and 1.3. The Protocols and ciphers card on the domain’s SSL Certificate tab shows each as Enabled, Not offered (1.2, 1.3) or Disabled (1.0, 1.1), with the cipher it negotiated. TLS 1.0 and 1.1 are deprecated, so Enabled (deprecated) counts as a finding. Disabled and Not offered mean that no handshake completed at that version with any cipher the scanner offers; a version served only with RC4, 3DES or export-grade ciphers shows up as that weak cipher, not as the version.
  • Weak ciphers. For each of five classes (RC4, 3DES, NULL, export-grade and anonymous key exchange) the scanner sends one hello that offers that class’s ciphers and reads the answer. It never completes a handshake and never sends application data. A class the host accepts is a finding.
  • The certificate’s key. A key shorter than 2048-bit RSA or 224-bit elliptic curve, or any DSA key, is a finding.

That is at most nine more connections per domain per day, to a host the scanner already connects to daily. A check that could not finish reads Not measured, and the card then says the findings count only what was measured.

DNS & WHOIS change detection

Section titled “DNS & WHOIS change detection”

Every DNS and WHOIS scan is compared against the last accepted result and flagged when it changes, with the two scans linked so you can see exactly what moved and when. Transient resolver failures are classified as lookup_unavailable and excluded from change detection — so a flaky upstream never masquerades as a suspicious change.

Two further noise filters keep the signal trustworthy:

  • A settle window. A new DNS answer must hold across consecutive scans before it is accepted as a change, so a zone mid-propagation doesn’t report a change per flip.
  • The SOA serial is ignored. Providers increment it on a schedule without any record actually changing; comparing it would manufacture a change every day.

Domain-expiry watch

Section titled “Domain-expiry watch”

Registration expiry is tracked daily. Paired with the Domain expiring soon alarm rule (warning at 60 days, critical at 30 by default, both tunable per domain), it turns the single most preventable outage into a calendar you can’t miss.

From finding to alert

Section titled “From finding to alert”

Security findings flow through the same alarm engine as everything else. The directly relevant built-in rules:

  • SSL certificate expiring soon — metric, warns then escalates as expiry nears.
  • Weak TLS configuration — metric, a warning when the daily scan finds one or more weak findings (above); it resolves when a later scan finds none, and a scan that could not measure TLS neither opens nor resolves it.
  • Domain expiring soon — metric, same shape for registration.
  • DNS changed / WHOIS changed — boolean, warning-level heads-up on any change.

Attach a notification policy — ideally targeted at a tag like tier:public — and certificate and DNS posture is covered for every current and future domain that carries it.

On-host security scanning

Section titled “On-host security scanning”
Section titled “Related”