Certificate Transparency can be searched periodically or consumed as a stream. The difference matters, because the value of a certificate signal decays in hours.
Search against stream
| Periodic search | Live stream | |
|---|---|---|
| Latency | Your polling interval — usually hours | Seconds to minutes after submission |
| Query shape | One brand string at a time | Every entry, filtered by you |
| Volume handled | Whatever the search returns | Millions a day, filtered locally |
| Best for | Retrospective investigation | Detection |
Because certificate issuance typically precedes use by hours, a six-hour polling interval can consume most of the warning the channel provides. A stream turns it into minutes.
Filtering a stream
For each certificate observed:
for each SAN:
normalise (lowercase, strip trailing dot, punycode-decode)
if SAN in watchlist -> ALERT
if brand-string appears as a label -> queue
if SAN is ours -> drop
else -> drop
Then, always:
dedupe by certificate fingerprint
dedupe by SAN first-seen- Punycode-decode before matching. A homograph domain arrives in the log as
xn--and will not match a brand string otherwise. - Match on labels, not substrings.
northwindas a whole label is a signal; as part of a longer word it is noise. - Drop your own names first, before any other rule. Renewals are the largest single source of volume.
Keep every observation, alert on almost none
Storing every matched SAN with a first-seen timestamp costs very little and gives you the history that answers “when did this start” during an incident. The alerting rule should stay narrow; the recording rule should be generous. They are different decisions and are frequently conflated.