Certificate transparency and CAA: see who issues certificates for your domain
What certificate transparency logs show, how to spot an unexpected issuer or wildcard, and how to write a CAA record that names only your CAs.
Every publicly trusted TLS certificate is written to open, append-only logs (certificate transparency, RFC 9162). Anyone can search them, so you can see every certificate any CA has issued for your domain, including the ones you did not ask for.
What the logs show
For each certificate the logs show the names it covers, the CA that issued it and the dates it is valid. Searching your domain and its subdomains gives your whole certificate history, and it also exposes subdomains you may have forgotten: a name on a certificate is public, so do not put secrets into host names.
What to look for
An issuer you never use. If all your certificates come from one or two CAs and a third appears, someone asked for a certificate for your name: a colleague with a new tool, or someone else.
A wildcard certificate (*.example.com). It is valid for every subdomain, so it is worth more to an attacker than a single-name one. Wildcards are normal on some platforms; the point is that you know about each one.
A certificate from a CA that your CAA record does not list. Either the record was different when the certificate was issued, or the CA made a mistake. The first calls for a look at who can change your DNS; the second is a report to the CA.
Not every new issuer is a change. Some hosting platforms rotate between several CAs, so a new issuer from such a platform is expected.
What to do about one you did not expect
Find out who asked for it: a colleague, a vendor, a tool. If nobody did, ask the CA to revoke it and tell them the request was not authorized, then tighten your CAA record so that CA can no longer issue for you.
Writing a CAA record
A CAA record lists the CAs that may issue for a domain. Without one, every CA may. Each CA publishes its own identifier, such as letsencrypt.org or digicert.com.
example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 issuewild ";" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
issue names the CAs allowed to issue normal certificates. issuewild controls wildcards separately, and a semicolon as its value forbids them. iodef gives CAs an address to tell you about refused requests. A CAA record applies to the name and to its subdomains unless a subdomain has its own.
Before you publish, list the CAs your certificates really came from in the last year, including the ones your hosting, CDN and email providers use for you; leave one out and its next renewal fails. ProbeKit’s monitor proposes a CAA record from the CAs that actually issue for you, after a fresh check of what is live. Start with a short TTL and watch the next renewal.
Common questions
- Do certificate transparency logs expose private data?
- They list names and issuers, not keys or traffic. Host names on certificates are public, so avoid putting sensitive information in them.
- Does a CAA record stop attackers?
- It stops honest CAs from issuing to anyone else for your name. It does not stop an attacker who controls your DNS, or a CA that ignores the rule. The logs are how you notice.
- Do I need a CAA record?
- It is optional and cheap protection. Publish it once you know which CAs you use.
- How soon does a new certificate show up in the logs?
- Usually within a day. ProbeKit reads the logs once a day and lists certificates that already existed once, without alerting.
Try it on your own setup:
Look up your CAA record