How to Implement Certificate Transparency Monitoring to Catch Rogue Certificates Before Attackers Use Them
Proactive Security for the AI Era
NodeZero continuously and autonomously pentests infrastructure, identity, cloud, and now web applications, chaining weaknesses across every domain the way real attackers do. Every finding ships with replayable proof showing exploitable business impact, not theoretical risk.
Every publicly trusted certificate authority is required to publish every certificate it issues to public, append-only Certificate Transparency logs, which means a certificate issued for your domain by a CA you never contacted, or for a lookalike domain built to impersonate your brand, shows up in a public dataset before it's ever deployed on a server. That is a real detection opportunity most organizations leave unused. A phishing operator who registers paypal-security-alert.com and requests a certificate for it has to go through a CA that logs the issuance publicly; the certificate becomes visible in CT logs at the moment of issuance, typically minutes before the phishing site actually goes live. This guide covers setting up that monitoring in practice: querying crt.sh directly, wiring up free alerting through Cert Spotter, and using CAA records to restrict which CAs can even issue for your domains in the first place, so mis-issuance either can't happen or gets caught immediately when it does.
The problem: mis-issuance and lookalike domains are invisible until someone looks
Two distinct threats live in this space, and a monitoring setup needs to cover both. The first is genuine mis-issuance: a certificate authority, through a process failure or a domain validation bypass, issues a certificate for your actual domain to someone who isn't you. This is rare but has happened industry-wide, and it defeats the entire trust model TLS is built on if it goes undetected. The second, far more common threat is lookalike-domain issuance: an attacker registers a domain designed to be confused with yours (a typo variant, a punycode homograph, an added or substituted word) and gets a perfectly legitimate certificate issued for that domain, because CAs validate that the requester controls the domain they're requesting for, not that the domain is unrelated to your brand. Neither case is visible from your own infrastructure, because in both cases the certificate is issued and served from infrastructure you don't control and can't see. CT logs are the one dataset where both cases surface publicly, which is why they're the right place to build a detection process rather than waiting for a customer to report a phishing site.
Prerequisites
Before setting up monitoring, gather the following:
A complete inventory of owned domains and subdomains
You need every domain you actually own as a monitoring baseline, not just your primary marketing domain. Include acquired brands, regional TLD variants, and any domain your organization has ever used, since a stale or forgotten domain is exactly the kind of asset an attacker can quietly re-register or where an old CA relationship goes unnoticed.
A list of plausible lookalike patterns for your brand
Build a short list of the typo variants, hyphenation and word-order variants, common TLD swaps, and punycode homographs most likely to be used against your specific brand name. This list becomes a second, parallel set of monitors alongside your real domains.
Access to DNS for your domains
CAA record changes require the ability to publish DNS records for each domain you want to restrict. Confirm you (or the team that owns DNS) can make this change before starting, since CAA enforcement is worthless if you can't actually publish the record.
A destination for alerts
Decide where CT alerts should land: a shared security mailbox, a Slack or Teams channel, or a ticketing queue. An alert nobody reads is not a detection control. If this feed is meant to reach a broader security tooling stack rather than a single inbox, review our guides on enterprise PKI certificate management (/blog/enterprise-pki-certificate-management-tls-lifecycle-automation) and certificate lifecycle management (/blog/certificate-lifecycle-management-enterprise) for how CT alerts fit into a broader lifecycle process rather than sitting as an isolated feed.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Procedure: setting up CT log monitoring
1. Build baseline crt.sh queries for every owned domain
crt.sh (run by Sectigo) exposes a free web and API interface over the public CT log data. Query the pattern https://crt.sh/?q=%.yourdomain.com (the %25-encoded wildcard captures all subdomains) for every domain in your inventory, and save the current result set as your baseline of known-good, already-issued certificates.
2. Build a second set of queries for lookalike domain patterns
Run the same crt.sh query pattern against each lookalike variant identified in your prerequisites. Most of these queries will return nothing today; the value is in having them ready to re-run on a schedule so a future issuance against one of them gets caught immediately rather than months later.
3. Set up Cert Spotter for automated alerting
Manually re-running crt.sh queries does not scale as a detection process. SSLMate's Cert Spotter is a dedicated, free CT log monitor: register each domain you want watched, and it emails you when a new certificate is issued that matches. Configure it for both your real domains and your lookalike pattern list.
Procedure (continued): alert triage and issuance restriction
4. Configure a tight check frequency where the platform allows it
CT logs typically reflect a new issuance within minutes of the certificate being issued. A monitoring cadence of around 15 minutes is meaningfully better than an hourly check, because it can catch a new certificate before the phishing infrastructure behind it becomes fully operational. Free tiers on most monitoring services default to hourly checks; evaluate whether a paid tier's faster interval is worth it against your brand's actual phishing exposure.
5. Route alerts to a real destination and define a triage process
Wire Cert Spotter (or whichever monitor you use) to deliver alerts into a channel your security team actually watches, ideally with a webhook into existing SOC tooling rather than a personal inbox that gets ignored during on-call rotations. Define, in advance, who owns triage and what the escalation path is when an alert fires.
6. Restrict issuance authority with CAA DNS records
A CAA (Certification Authority Authorization) record published in your domain's DNS tells compliant CAs which authorities are permitted to issue certificates for that domain; any compliant CA not listed is required to refuse issuance. Publish a CAA record naming only the CA (or CAs) your organization actually uses, for every domain in your inventory. This does not replace CT monitoring (a misconfigured or non-compliant CA can still issue against the rules), but it meaningfully narrows the pool of CAs an attacker could successfully abuse.
7. Document the six rogue-issuance patterns your triage process should flag
Train whoever triages alerts to look for: certificates for unrecognized subdomains (which can also surface forgotten shadow-IT assets), issuance from a CA outside your CAA allowlist, unexpected wildcard certificates, punycode or other IDN homograph domains, a burst of issuances clustered around a lookalike pattern, and anomalous Subject Alternative Names bundling your domain with unrelated ones.
Validation
Confirm CAA enforcement with a real test
After publishing a CAA record, attempt (or have a colleague attempt, from a CA not on your allowlist, using a test subdomain you control) to request a certificate for that subdomain. A compliant CA should refuse the request; if it doesn't, the CAA record isn't propagating or was published incorrectly, and you should check DNS propagation before assuming the control is active.
Trigger a test alert
Where feasible, issue a real certificate for a test subdomain you own and confirm the resulting CT log entry generates an alert through your configured monitor within the expected check interval. This validates the full path from issuance to a notification landing where your team will actually see it.
Re-run baseline queries periodically and diff the results
Even with automated alerting in place, periodically re-run your crt.sh baseline queries and diff against the last known-good set, as a check against silent alerting failures (a bounced webhook, an expired API key, a monitoring service outage that fails silently rather than loudly).
Failure cases to watch for
Monitoring only your exact domain, not subdomains or lookalikes
A wildcard-scoped query on your exact domain misses both a forgotten subdomain issued under a different validation path and any lookalike domain entirely, since a lookalike is by definition a different registered domain than the one you're querying.
CAA records published but with a typo or wrong CA identifier
A CAA record naming the wrong CA identifier, or published with a syntax error, is silently ignored by compliant CAs rather than causing an obvious failure, which is exactly why the validation step of attempting a real test issuance matters instead of trusting the record was written correctly.
Alert fatigue from an unfiltered feed
A monitor with no triage rubric floods a channel with legitimate renewal notifications alongside genuine mis-issuance, and a team that gets used to ignoring the noise will also ignore the one alert that mattered. Filter and prioritize using the six-pattern rubric from the procedure above rather than routing every raw CT event to a human.
Treating CT monitoring as a replacement for takedown capability
Detecting a rogue or lookalike certificate is not the same as getting the resulting phishing site taken down. Have a defined escalation path (registrar abuse contact, hosting provider abuse contact, or a takedown service) ready before you need it, so a detected alert doesn't sit unresolved while the phishing site stays live.
Security tradeoffs
CT monitoring is detective, not preventive: it tells you a certificate was issued, generally within minutes, but it cannot stop the issuance itself except indirectly through CAA restriction, and CAA restriction only binds CAs that honor the CAA standard correctly. Building your own lookalike-pattern list is manual work that has to be maintained as your brand evolves (a new product line or acquired brand needs its own lookalike variants added), and a broader, more exhaustive pattern list generates more noise for your triage process to filter. Free tooling like crt.sh and Cert Spotter's free tier is a legitimate starting point and, for many organizations, may be sufficient on its own, but a faster check interval and richer alert correlation typically sit behind paid tiers of commercial CT monitoring products; whether that tradeoff is worth it depends on how attractive your brand actually is as a phishing target, which is a judgment call your security team has to make with real data rather than by default.
The bottom line
Certificate Transparency logs give you a public, real-time view into every certificate issued for your domains, including the ones you never requested. Build baseline crt.sh queries for both your real domains and plausible lookalikes, automate alerting through a free monitor like Cert Spotter, restrict issuance authority with CAA DNS records, and validate every part of that chain with a real test rather than assuming the configuration works as written. None of it replaces a takedown process for what you find, but it turns rogue issuance from something a customer reports after the fact into something your team catches before the phishing site goes live.
Frequently asked questions
What is certificate transparency monitoring?
Certificate transparency monitoring is the practice of continuously querying the public, append-only CT logs that publicly trusted certificate authorities must publish every issued certificate to, in order to detect certificates issued for your domains, or for lookalike domains impersonating your brand, that you did not request.
How do you query crt.sh for a specific domain?
Use the query pattern https://crt.sh/?q=%.yourdomain.com, where the %25-encoded wildcard captures all subdomains, and save the result set as a baseline; re-run the same pattern periodically, or against lookalike domain variants, to catch new issuances that weren't present before.
What does Cert Spotter do and how much does it cost?
SSLMate's Cert Spotter is a dedicated CT log monitor with a free tier: register a domain and it emails an alert when a new certificate is issued that matches it, removing the need to manually re-run crt.sh queries on a schedule.
How do CAA records help prevent rogue certificate issuance?
A CAA DNS record names which certificate authorities are permitted to issue for a domain, and a compliant CA that isn't listed is required to refuse an issuance request for that domain, narrowing the pool of CAs an attacker could successfully abuse, though it does not stop a non-compliant or misconfigured CA from ignoring the record.
What patterns indicate a rogue or mis-issued certificate in CT log results?
Watch for certificates on unrecognized subdomains, issuance from a CA outside your CAA allowlist, unexpected wildcard certificates, punycode or IDN homograph domains, a burst of issuances clustered around a lookalike pattern, and anomalous Subject Alternative Names bundling your domain with unrelated ones.
Does certificate transparency monitoring stop phishing sites from launching?
No, CT monitoring is detective rather than preventive; it typically surfaces a new certificate within minutes of issuance, before the phishing infrastructure behind it is fully operational, but taking the resulting site down still requires a separate escalation process through the registrar's or host's abuse contact.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.