Skip to content

Discovery sources

Tidehawk finds certificates from two kinds of source: a live connection to the host, and public certificate transparency directories. No single directory is load-bearing.

Tidehawk connects to the hostname on its tracked port and reads the certificate the server presents. This runs on every scan and depends on nothing outside your client’s own infrastructure.

It is the only source that sees a certificate which never reached a public log, so self-signed and internally issued certificates show up here and nowhere else.

These are queried in order, and the first one to answer wins.

Order Source Notes
1 Certspotter Primary. Covers the whole subdomain tree in one query
2 Censys Used only where your deployment is configured with Censys credentials
3 crt.sh Free public fallback

A source with no credentials configured is skipped, and one that has been failing repeatedly is skipped for a cooldown and tried again later, so a single directory having a bad day cannot stop discovery. Each source Tidehawk does try gets several attempts before it moves on.

Because the lookup covers the subdomain tree, one query for example.com returns certificates for mail.example.com too. That is also why Tidehawk refuses overlapping domains: see add domains.

Certificate transparency directories are rate-limited, and Tidehawk respects those limits rather than pushing through them. The Certspotter free tier allows ten whole-domain queries an hour, and crt.sh is a free public service that Tidehawk queries gently.

Two things follow from that.

Sibling scans are shared. Where a domain under the same registrable domain completed a full scan in the last hour, Tidehawk reuses its directory results and runs only the per-host TLS probe. A client with twenty subdomains therefore costs one directory query rather than twenty.

Scans wait rather than degrade. When the hourly quota is spent, a scan is put back on the queue to run once the window refills, so you get a complete scan a little later instead of a partial one now. After several such waits Tidehawk runs with whatever sources are available, rather than leaving a domain unscanned indefinitely.

Each domain records the quality of its last scan.

Quality Meaning
Full The primary directory answered
Partial The primary failed, the fallback directory answered
Degraded Only the active TLS scan ran, so no transparency log coverage

A degraded scan still finds the certificate your client is actually serving, but it can miss issued certificates that are not currently deployed. Degraded scans are counted on the dashboard next to Scans · 24h.

The Domains page has a Discovery column with one of five labels.

Label Meaning
Scanning No scan has completed for this domain yet
Failed The last scan recorded a failure reason
No certs The scan completed and found no certificates
Degraded The last scan was degraded
Healthy A normal scan with certificates found

Selecting a row opens a panel with the last scan time, the quality, and the failure reason where there is one.

On a client page you may see one of these banners.

  • Discovery in progress — a scan is running; the page refreshes itself.
  • Certificate lookup temporarily unavailable — public certificate records are unreachable and Tidehawk is retrying automatically. No action needed.
  • Discovery is taking longer than usual — the scanner is catching up and will resume shortly. This is also what a scan waiting on a quota window looks like.
  • Discovery paused — service resuming — the monitoring service is briefly offline. It resumes on its own.
  • Discovery failed — every retry was exhausted. This one has a Retry now button.

Detail on what to do with each is in scan is stalled or deferred.