Certificate Transparency monitoring, explained
Every TLS certificate issued by a public certificate authority is recorded in public, append-only logs. For defenders, that means an attacker preparing a convincing phishing site usually announces it, in public, the moment they request a certificate. Certificate Transparency monitoring is the practice of watching those logs for names that look like yours.
What are CT logs?
Certificate Transparency (CT) is an open framework, standardized by the IETF, in which certificate authorities submit every certificate they issue to publicly auditable, append-only logs. The logs are cryptographically structured (Merkle trees) so entries cannot be quietly removed or altered, and anyone can read them. CT was created after a series of CA compromises showed that mis-issued certificates could go unnoticed for months.
The key enforcement point: since 2018, Chrome has required that publicly trusted certificates be CT-logged to be accepted, and other major browsers followed. In practice, a public website cannot get a working certificate without leaving a public record. There is no opt-out for an attacker who wants the padlock icon.
Why CT logs are a goldmine for defenders
Modern phishing needs HTTPS. Browsers mark plain HTTP pages as not secure, users have been trained to look for the padlock, and many security products treat certificate-less sites with suspicion. So attackers routinely obtain certificates, often free ones from automated CAs, for their lookalike domains.
That creates a timing gift. The certificate appears in CT logs within moments of issuance, and issuance typically happens while the attacker is still setting up: before content is finished, before mail is configured, and often days before the first phishing email goes out. A defender watching CT logs sees the domain at the preparation stage. Combined with registration monitoring via DNS, it is one of the earliest reliable signals that exists. It also catches things registration monitoring cannot: a certificate for login.acmebank-secure.com reveals a hostile subdomain that no list of registered domains would surface.
How CT log monitoring works
- Stream the logs. Dozens of active CT logs (operated by Google, Cloudflare, Let's Encrypt, DigiCert, and others) publish new entries continuously. A monitor tails all of them in near real time.
- Extract the names. Each entry lists the domains the certificate covers, including subdomains in the SAN list.
- Match against your brand. Every name is compared against the permutation set for your domains: typos, homoglyphs, TLD swaps, combosquats, and brand keywords. This matching step is where quality lives, since exact-string matching misses homoglyph attacks and naive substring matching drowns you in false positives.
- Enrich and alert. A hit gets checked against DNS (is it live, does it have MX records), screenshotted, and scored before a human sees it.
Limitations to be honest about
- No certificate, no entry. A phishing site served over plain HTTP, or a domain used only for email, never appears in CT. This is why CT monitoring complements DNS and registration monitoring rather than replacing them.
- Wildcard certificates hide subdomains. A certificate for
*.attacker-site.comreveals nothing about the brand-themed subdomains created under it later. - Volume is enormous. Hundreds of millions of certificates are issued per year, largely due to free automated CAs and short renewal cycles. Matching quality and risk scoring determine whether you get one good alert or a thousand useless ones.
- It is detection, not prevention. CT tells you the certificate exists; it does not stop issuance. The value is the head start.
DIY lookups vs continuous monitoring
You can query CT history for free at crt.sh, and for a one-time investigation it is excellent. The gap is continuity: an attacker's certificate issued tonight will not be in the search you ran last week.
| Manual crt.sh lookups | Continuous CT monitoring | |
|---|---|---|
| Cost | Free | Subscription |
| Coverage | Exact names you think to search | Full permutation set, including homoglyphs |
| Timing | Whenever you remember to check | Near real time, alert on issuance |
| Context | Raw certificate records | DNS, MX, screenshots, risk scoring attached |
Open source tooling can stream CT yourself if you have the engineering time; our dnstwist comparison covers the build-vs-buy tradeoff. VigilDNS includes live CT log monitoring matched against an 11-technique permutation engine, so a certificate issued for a lookalike of your domain becomes an alert, not a surprise. And if a lookalike does turn up, our guide on what to do about a lookalike domain walks through the response.
Frequently asked questions
Do attackers know their certificates are public?
Sophisticated ones do, and some respond by using wildcard certificates or delaying issuance until launch. Most do not bother, because the majority of targets are not watching. CT monitoring exploits that asymmetry.
Can I see my own organization's certificates in CT logs?
Yes, and you should. CT monitoring of your own domains reveals shadow IT, forgotten subdomains, and any certificate issued for your domain that you did not request, which can indicate compromise or CA error.
Is Certificate Transparency the same as certificate pinning?
No. Pinning hard-codes which certificates or keys a client accepts for a site. CT is a public audit trail of what was issued. Pinning protects a connection; CT gives the whole internet visibility into issuance.
See whether lookalikes of your domain already have certificates and live DNS: try the free typosquat checker.