Certificate transparency explained: the public logs, crt.sh, and the certificate you did not order

What certificate transparency is

For most of the web's life a certificate authority could issue a certificate for any name to anyone who passed its checks, and nobody but the two parties would know. When an authority was tricked or broken into, as DigiNotar was in 2011, the certificates it issued for other people's domains were found by accident, in use, weeks later. Certificate transparency (RFC 6962, revised as RFC 9162) is the answer: every publicly trusted certificate is submitted to public, append-only logs when it is issued, and each log returns a signed timestamp that is presented alongside the certificate, usually embedded in it. Browsers insist on it. Chrome has refused certificates without those timestamps since 2018 and Apple's platforms have required the same since late that year, so a public certificate that is not in the logs does not work in the major browsers.

The logs are built as Merkle trees, so anyone can prove an entry is present and that nothing already written has been altered. For a domain owner the consequence is simpler than the machinery. Every certificate any public authority issues for your names is on the record by the time it is used, whether you ordered it or not, and a record can be watched.

crt.sh

The logs themselves are for machines: each is a stream of entries fetched by index, in the order they were written. crt.sh, run by Sectigo, ingests the logs and indexes them by name, so you can ask for every certificate ever issued for a domain and get an answer as a web page or as JSON. It is free, shared, and rate limited, and it is where hostnag's watch reads from.

Two quirks show up when you read it. A certificate usually appears twice, once as the precertificate the authority logged before issuing and once as the final certificate, with the same serial number under two different log ids. And a busy name's list runs to thousands of entries going back years, because a log never forgets.

Why a certificate you did not order matters

A certificate for your domain in somebody else's hands is a working key to your visitors' trust. Whoever holds it, and can steer traffic to themselves through a DNS change, a compromised network or a hosting account, can serve a site that claims to be yours, and every browser will agree that it is. It happens in a few ways.

Somebody else passed domain validation. An attacker with control of your DNS, or of a path on your web server, can answer the challenge an authority sets. The certificate is the first thing they obtain and often the first evidence anyone sees.

An authority mis-issued. Rare now, and the reason transparency exists.

A colleague or a vendor ordered one. A marketing site on a new host, a product that terminates TLS for a subdomain you pointed at it. Legitimate, and still worth knowing: a third party now holds a key for a name of yours.

A look-alike is not this. A certificate for a misspelt copy of your domain is in the logs under that name, not yours, and no watch on your domain sees it. Transparency shows you your own names.

When an unexpected certificate appears, the issuing authority is named in the entry, and an authority must revoke a certificate the domain's holder did not authorise. Then find the hole. In the words of hostnag's alert, "If you did not order this, check who has access to your DNS and your CA account."

Subdomains

A watch on example.com covers everything under it by default: the query is for the wildcard form crt.sh takes, and it matches every hostname below the domain. That is where the surprises live: a certificate for a hostname you forgot, a staging host someone gave a real certificate, a vendor subdomain that still resolves. It is also a reminder that the logs are public. Every hostname you have ever certificated is readable by anyone, which is why internal names belong under a wildcard certificate or a private authority rather than in the public record. The subdomain setting can be switched off to watch the bare domain alone.

A second setting, on by default, ignores certificates that had already expired when they surfaced. An entry can turn up late, and an old certificate surfacing late in the logs is history, not news.

How hostnag's watch works

Add the domain and the first run is a baseline: hostnag writes down what the logs already hold and the highest log id it saw, and reports nothing. The past is on the monitor page, not in your inbox.

Each later run asks crt.sh again, folds each precertificate and certificate pair into one certificate by serial and issuer, keeps the newest 500 entries, and treats every entry above the last run's highest id as new. Each new certificate raises its own Changed alert, never a digest: "New certificate for example.com", with the issuer, the names it covers, the issue date, and one more word: expected, or unexpected.

That word is the useful part. hostnag compares the new certificate's serial number with the certificates your own certificate monitors last read from their hosts. A match means the certificate is yours, a renewal that has landed, and the alert says "Expected: yes". No match means "Expected: no", with the line about DNS and your CA account. So watch the domain in the logs and the hosts with certificate monitors, and your own renewals are recognised on sight while everything else is called out. The monitor page keeps the newest entries in a list, issuer, names and date, with the word EXPECTED engraved where the match holds.

Alerts follow the group's notify-on-change switch, which is on by default. A run in which crt.sh timed out or throttled the request is retried inside the run and, if it still fails, is a Couldn't check: the watch never invents a new certificate out of a failed read.

Daily, on every plan

The watch runs once a day, 1440 minutes, on every plan, and that interval cannot be shortened. Certificate monitors run as often as every 60 minutes on Pro and every 15 on Business; the watch stays daily because crt.sh is one shared service for everyone, and hostnag polls it the same way for every customer. A day is the right unit for the job anyway. The point of the watch is not to catch a certificate in the minute it is issued but to make sure you hear about it at all, and to hear about it from your own monitor rather than from a customer.

The watch is part of the Pro and Business plans. On a downgrade, an organization's watches are paused, never deleted.

Look for yourself

curl -sG https://crt.sh/ --data-urlencode 'q=%.example.com' --data-urlencode 'output=json' \
  | jq -r '.[] | [.not_before, .issuer_name, .common_name] | @tsv' | sort -r | head -20

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -serial -issuer

The first command prints the newest twenty certificates for the domain and everything under it: when each was issued, by whom, and for what name. The second prints the serial number and issuer of the certificate your host is serving right now, so you can find it in the first list. That is the same comparison hostnag makes to mark a certificate expected. Be gentle with crt.sh: one query when you need one, never a loop.

Check it now, then watch it

Check it now: the SSL checker reads the certificate a host serves right now, its days left, the names it covers, its fingerprint, and whether the chain and hostname check out, so you know what your own side looks like before you read the logs.

Watch it for good: certificate transparency watch reads the logs for your domain and its subdomains once a day and raises one alert per new certificate, marked expected when a certificate monitor of yours is already serving it.