how do i search certificate transparency logs for my domain

Use crt.sh: https://crt.sh/?q=example.com lists certificates naming example.com, and https://crt.sh/?q=%25.example.com lists every subdomain, with &output=json for a script. Other monitors listed by the Certificate Transparency project include Censys, Cloudflare, Merklemap and SSLMate.

can certificate transparency logs detect phishing domains

They can surface a lookalike domain early, often before it serves a page, because automated certificate issuance happens as soon as a name resolves. They cannot tell you what the name is for. A certificate is evidence of control of a name, and it becomes a finding only when joined to registration date, DNS and observation.

why does a phishing domain have a valid certificate

Because certificates are issued automatically to anyone who can prove control of a name, and control is proved by answering a DNS or HTTP challenge, not by being trustworthy. A padlock says the connection is encrypted to whoever holds the name. It says nothing about who that is.

how quickly does a certificate appear in the logs

Usually within minutes of issuance, because the certificate authority submits it, often as a precertificate, before handing over the final certificate. Search services then index the logs on their own schedule. The real example in this guide reached its first log ten minutes after its not-before time.

what is the difference between a precertificate and a certificate in crt.sh

A precertificate is what the certificate authority submits to the logs before issuing the final certificate, so most certificates appear twice. The deduplicate=Y option on crt.sh collapses the pair into one row. For hunting, the pair is one event, not two.

how do i get alerted when a certificate is issued for a lookalike of my domain

Run a monitor with a watch list: a hosted service such as Cert Spotter, the open source certspotter, or a script that polls the crt.sh JSON output for your strings and alerts on ids it has not seen. Alert on new names only and join each to registration and DNS before it reaches a person.

TECHNICAL

Certificate Transparency Logs: Catch Lookalike Domains Early

The earliest public trace of a lookalike domain is frequently not a page. It is a certificate.

by Typosquatting.ai Research16 September 2026updated 23 September 202610 min read

Certificate transparency is a system of public, append-only logs recording certificates as they are issued, so that any certificate for any name can be discovered by anyone.

This guide covers why the logs exist, why an entry often appears before a website does, what a real log entry looks like, the exact crt.sh query forms for searching for a brand, how to set up an alert, the noise to expect, and how certificate evidence combines with registration and DNS.

Why the logs exist

Certificate transparency was built to solve a trust problem: a certificate authority could issue a certificate for any name, and the owner of that name had no reliable way to find out. RFC 6962 describes the answer as publicly auditable, append-only logs of all issued certificates, and its successor RFC 9162 keeps the same design.

Browsers made this effective by requiring evidence of logging before they will trust a certificate. Chrome's policy states that in CT-enforcing versions all publicly trusted TLS certificates must be CT compliant to validate. The consequence is that essentially every publicly trusted certificate is now in the logs, and anyone can search them.

The system was designed for misissuance detection. Its use for finding lookalike domains is a side effect, and an unusually good one, because the log does not care who requested the certificate or why.

Why a certificate appears before a website does

The order of operations when somebody prepares a site is usually: register the name, point it somewhere, obtain a certificate, then deploy. Automated issuance has made the certificate step early and cheap, and it happens as soon as the name resolves.

The logs record issuance, not use. RFC 6962 also allows a certificate authority to submit a precertificate before the final certificate exists, so the log frequently holds a name before the certificate is even installed. A name can therefore appear in the logs while it still serves nothing, and often does so days before a page exists. For anybody watching a brand, that gap is the most valuable window available: the name is identifiable before it is used.

What a real log entry looks like

An entry records the certificate: the names it covers, the issuer, its validity period, and the time each log accepted it. The names are the useful part, and there are usually several, because a single certificate can cover a list of names. Below is a real entry for example.com as crt.sh shows it, placed next to the registration date from the registry, which is the comparison that matters.

Names: example.com and *.example.com, the second being a wildcard covering every direct subdomain.
Issuer: C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
Not before and not after: 2026-07-29T22:10:08 to 2026-10-27T22:17:21, a 90-day certificate.
Logged at: 2026-07-29 22:20:19 UTC in Google's argon2026h2 log, ten minutes after not-before, with further entries in other logs over the following two days.
Registered: 1995-08-14 according to the .com registry's RDAP record. Thirty-one years between registration and this certificate is the shape of routine renewal. Thirty-one hours would be the shape of preparation.
What is absent: Who requested it, what the name serves, and whether the certificate was ever installed. A certificate is evidence that somebody controlled the name well enough to pass a validation check at that moment. That is a meaningful fact and a narrow one.

Searching crt.sh for your brand

crt.sh is the search interface most people start with. It indexes the public logs into a database and answers an identity search, meaning a match against the names in a certificate. The forms below were checked against the service itself; crt.sh is a volunteer-run service under heavy load and will sometimes answer with a gateway error, so retry rather than conclude.

https://crt.sh/?q=example.com: Every certificate whose names include example.com exactly. The results page reports the match type as ILIKE, which is a case-insensitive match.
https://crt.sh/?q=%25.example.com: The percent sign is the wildcard, encoded as %25 in a URL. This form matches any name ending in .example.com, which is how you list subdomains, and it also catches lookalikes registered as subdomains of another name.
https://crt.sh/?q=example.com&output=json: The same results as an array of JSON objects, one per certificate, with issuer_name, common_name, name_value (one name per line), not_before, not_after, serial_number and the crt.sh id. This is the form to poll from a script.
https://crt.sh/?q=example.com&exclude=expired&deduplicate=Y: Drops certificates past their not-after date and collapses the precertificate and final certificate into one row, which turned 77 rows for example.com into 9.
https://crt.sh/?id=28361996564: One certificate by its crt.sh id, with the full name list and a table of every log that accepted it and when.

A brand string that is a common word returns unrelated organisations in volume, and crt.sh searches names rather than doing spelling variation. It finds names that contain your brand, not names that resemble it, so pair it with a permutation list for the misspellings.

Other ways to search and watch the logs

crt.sh is not the only monitor. The Certificate Transparency project's own list of monitors names Censys, Cloudflare, crt.sh, DigiCert, Hardenize, Merklemap, Report URI and SSLMate among others, and describes what they share: they watch for suspicious certificates in the logs. RFC 9162 puts it the same way, a monitor may be configured to report on all certificates that apply to a specific domain name.

SSLMate's Cert Spotter is the one most often named for alerting. The hosted service monitors the logs and alerts when a certificate is issued for one of your domains, and the same company publishes certspotter as an open source monitor that watches the logs for a list of domains and emails or runs a script on each match. Either handles the polling for you.

The noise you must expect

Four things make a brand search noisier than it first appears.

Duplication is normal. A precertificate and the final certificate are both logged, entries appear in several logs, and renewals add more. example.com alone has 77 rows on crt.sh that deduplicate to 9. One name can produce many entries and none of them is new information.
Wildcards cover names that do not exist yet, so a wildcard entry tells you about a zone rather than a host.
Your own infrastructure dominates the results. Every subdomain your organisation issues certificates for appears, which is useful for inventory and noise for hunting.
A brand string that is a common word returns unrelated organisations in volume, and filtering that sensibly is most of the engineering.

How to set up an alert

Searching once tells you what exists today. The value is in the next entry, so the useful setup is a standing watch that runs without you.

Choose the strings. Your registrable domain, your brand as a bare word if it is distinctive, and the handful of misspellings you most fear. Fewer, sharper strings beat a long list.
Pick a monitor. A hosted one such as Cert Spotter, the open source certspotter with a watch list, or a script that fetches https://crt.sh/?q=<string>&output=json on a schedule and remembers the ids it has seen.
Alert on new ids only, and carry the name list, issuer and not-before into the alert. A renewal for a name you already know is not an event.
Join each new name to the rest of the record before anyone reads it: does it resolve, when was it registered, does it publish mail routing. A certificate alone is a lead; the join makes it a finding.
Keep the first-seen time. The gap between registration, first certificate and first page is the timeline you will later want, and it cannot be reconstructed.

Domains on the Pro plan of this site's checker have certificate logs searched every 30 minutes, and a name seen for the first time queues a re-check, so it reaches the report within the hour rather than at the next daily run.

Combining certificate evidence with the rest

A certificate entry on its own is a lead. It becomes a finding when it is joined to the other records: does the name resolve, how old is the registration, does it accept mail, has any scanner observed it before.

The combination that should move fastest is a recent registration, a certificate issued within days of it, and mail records configured. Each of those alone is ordinary. Together they describe preparation.

The combination that usually turns out to be benign is a certificate on a name that has existed for years under your own registrar and nameservers, which is your own estate.

Limits worth stating

The logs cover publicly trusted certificates. A site served over plain HTTP, or with a certificate from a private authority, leaves no entry, so absence from the logs is not evidence that a name is unused.

Logging is also not instantaneous or uniform, and search services index the logs on their own schedules, so a very recent issuance may not be findable yet. The example above reached its first log ten minutes after issuance and its last two days later.

And as with every other source here, a certificate says nothing about intent. It says a name existed and somebody proved control of it. What that is for remains a judgement made from the whole picture, and a certificate on a similar name is a reason to review, never a finding of phishing.

Common questions

how do i search certificate transparency logs for my domain: Use crt.sh: https://crt.sh/?q=example.com lists certificates naming example.com, and https://crt.sh/?q=%25.example.com lists every subdomain, with &output=json for a script. Other monitors listed by the Certificate Transparency project include Censys, Cloudflare, Merklemap and SSLMate.
can certificate transparency logs detect phishing domains: They can surface a lookalike domain early, often before it serves a page, because automated certificate issuance happens as soon as a name resolves. They cannot tell you what the name is for. A certificate is evidence of control of a name, and it becomes a finding only when joined to registration date, DNS and observation.
why does a phishing domain have a valid certificate: Because certificates are issued automatically to anyone who can prove control of a name, and control is proved by answering a DNS or HTTP challenge, not by being trustworthy. A padlock says the connection is encrypted to whoever holds the name. It says nothing about who that is.
how quickly does a certificate appear in the logs: Usually within minutes of issuance, because the certificate authority submits it, often as a precertificate, before handing over the final certificate. Search services then index the logs on their own schedule. The real example in this guide reached its first log ten minutes after its not-before time.
what is the difference between a precertificate and a certificate in crt.sh: A precertificate is what the certificate authority submits to the logs before issuing the final certificate, so most certificates appear twice. The deduplicate=Y option on crt.sh collapses the pair into one row. For hunting, the pair is one event, not two.
how do i get alerted when a certificate is issued for a lookalike of my domain: Run a monitor with a watch list: a hosted service such as Cert Spotter, the open source certspotter, or a script that polls the crt.sh JSON output for your strings and alerts on ids it has not seen. Alert on new names only and join each to registration and DNS before it reaches a person.