Watching Certificate Transparency logs for your own domain

Since 2018, browsers require every publicly trusted certificate to be recorded in at least two public, append-only logs before they will accept it. The system is called Certificate Transparency, and it exists so that a certificate issued by mistake or by fraud can be noticed. The side effect is a complete, public, searchable history of every host name that ever had a certificate, for every domain, including yours.

That history is the most useful free data set in external security. Perimetry reads it on every audit. This guide explains what it reveals and how the report uses it.

Three things the logs tell you

1. Every subdomain you ever exposed

Any host name that received a certificate is in the logs, whether it still exists or not: staging.yourdomain.com, old-crm.yourdomain.com, test-2019.yourdomain.com. Development servers get certificates automatically from Let’s Encrypt and are forgotten a month later; the log entry stays for ever. The list is the starting point for the subdomain takeover check and for finding hosts that nobody remembers running.

Wildcard certificates (*.yourdomain.com) hide individual names from the logs, which is sometimes given as a privacy reason to use them. The trade-off is that a wildcard certificate’s private key, if stolen, works for every subdomain.

2. Who issued certificates for your names, and when

Each log entry names the certificate authority and the date. A domain served by Let’s Encrypt that suddenly shows a certificate from another authority deserves a question: did a colleague set up a new service, did a hosting provider change authorities, or did someone else obtain a certificate for a name under your domain? The last case is how a subdomain takeover or a DNS hijack usually becomes visible: the attacker needs a certificate to serve HTTPS, and the certificate is public within minutes.

Perimetry compares each issuer against your CAA record (see DNSSEC and CAA) and reports issuance by an authority the record does not allow.

3. When certificates expire

The logs record the validity period. For the hosts your audit actually connects to, Perimetry reads the live certificate instead, which is more reliable, and reports expiry within 30 days as high severity and expiry within 7 days or already expired as critical. For hosts that no longer answer, the logged certificate still tells you what was there.

The change section

The value of the logs is in the difference between two readings. The weekly report lists, under Since last audit:

• host names that appear in the logs for the first time (new subdomains),
• host names that no longer resolve (vanished subdomains, candidates for record clean-up),
• certificates issued since the previous audit, with their issuer and the names they cover,
• renewals of existing certificates, which are normal and listed briefly.

A new certificate for a name you do not recognise, from an authority you do not use, is the single most actionable line a report can contain, and it is why Perimetry treats new certificates as part of the changes rather than burying them in a list.

Doing it by hand

Two public services index the logs and can be searched without an account:

• crt.sh, run by Sectigo, accepts a domain and returns every matching entry, with a search by %.yourdomain.com for all subdomains.
• Cert Spotter, by SSLMate, offers a JSON API and a paid alerting service.

Both are the sources Perimetry queries. Searching by hand works for a one-off inventory; the weekly diff is where a service earns its place.

What to do with what you find

• Forgotten host still resolving: decide whether it should exist. If not, remove its DNS record and shut down whatever answers.
• Forgotten host no longer resolving: nothing to do today; check that no dangling CNAME or NS record is left behind (the takeover check covers this).
• Unexpected issuer: find out who requested it. If nobody did, treat it as an incident: check the DNS records of the name on the certificate, check your registrar account, and ask the authority to revoke the certificate; CAs must respond to revocation requests from the domain owner.
• Expiry within 30 days: check that automatic renewal is working. A certificate that has not been renewed with 30 days left usually means the renewal job is broken.

What the report looks like

Certificate expires in 9 days: shop.yourdomain.com — high Issued by Let’s Encrypt on 3 August, valid until 12 November. Let’s Encrypt certificates normally renew 30 days before expiry; the renewal job appears to have stopped.

New certificate from an issuer not in your CAA record — medium A certificate for files.yourdomain.com was logged on 29 October, issued by an authority your CAA record (issue "letsencrypt.org") does not permit. Either the record is incomplete or the certificate was not requested by you.

Certificate Transparency was built to keep certificate authorities honest. Read every week for one domain, it also keeps a company honest about what it still runs.