Certificate Transparency monitoring

What the logs actually contain

Publicly trusted certificate authorities write issued certificates to public logs. Monitors and auditors use those logs so an issuance is not a private event between the applicant and the authority. A certificate in a log has names, an issuer, and a validity period. It does not have a field that says this is installed on a particular IP address. Monitoring the log is monitoring issuance.

Certwatch reads those logs through public Certificate Transparency log services. For a customer domain the first service is tried, with a second service as a fallback only when nothing is stored yet. The public checker uses one page of the first service and does not fall through to the second. Parsing keeps names that belong to the domain you asked about and drops the rest. Issuer names are shortened for the table. Dates are stored as the not-before and not-after the service returned.

How an account monitors, and how the checker does not

On an account, a cron trigger enqueues work and does not itself download logs. A queue consumer handles one page per message. Later pages follow on later messages, so a busy domain fills in over time instead of in one request that could time out or blow the response cap. Daily caps stop new customer fetches when the budget for that UTC day is spent. The page says paused for budget. The next day continues.

The public checker is deliberately smaller. You submit a domain that passes the same public-name rules as the rest of the product: a registrable-style hostname, no IP address, no wildcard, no internal or reserved suffix, and a length limit. One page is fetched, at most 40 certificates are shown, soonest expiry first, and the slim result is cached for 24 hours. A cache hit does not call upstream and does not count against the lookup cap. Uncached calls have their own daily cap and a per-IP limit. They do not increment the customer Certificate Transparency cap.

Timeouts and upstream errors use the same handling as a customer fetch. The checker shows an unavailable page and does not cache the failure, so a later try can succeed. It still counted as an uncached call if the request was sent. A cap hit never sends the request at all.

What monitoring will miss

It will miss certificates that expired before the first good read, more often than not, because the primary source is aimed at unexpired issuances. It will miss private authorities. It will miss the difference between issued and deployed until you add an endpoint. It can include a certificate you did not request, which is a reason to monitor rather than a defect: the log is showing an issuance for a name in the domain.

It will not include every historical certificate the moment you add a popular domain. One page is not the full history. Customer refreshes keep going. The checker stops. If the result says it was capped, treat it as a sample of the soonest expiries on that page, not as a complete census. The mozilla.org demo is a longer public example of the same logs-only approach, filled under its own daily page budget, and Certwatch is not affiliated with Mozilla.

How to use the result

Read the upcoming expiries first. A cluster of dates inside 30 days is the operational fact. The issuer tells you which client or account likely requested the certificate, in the informal sense that different authorities are different workflows, not in the sense that the log names your internal team. The names tell you whether a hostname you forgot is on a certificate that is about to expire.

Then decide if the domain should be monitored. An account keeps later pages and later days. A paid plan adds email, and Team adds Slack and other webhooks. A probe adds the served certificate. The checker is the front door, linked from the home page, the navigation, the demo, and these guides, and each result page asks crawlers not to index it. The tool page itself is the indexable URL, with a canonical link from those result pages, so a thin per-domain URL is not a pile of doorway pages.

Questions

Look up a domain or start monitoring

The public checker reads one page of Certificate Transparency and does not connect to the domain. An account keeps the inventory. Alerts, when you want them, start on a paid plan.

Check a certificate Create an account

See pricing for what Free, Pro, and Team include. The mozilla.org demo is logs only and is not affiliated with Mozilla. Related: Certificate Transparency · Choosing a certificate monitoring tool · 90-day renewals.