CT Monitor: a beginner's guide
Search CT logs for unauthorized cert issuance signals
Threat intelligence — your early-warning radar for the bad guys
Threat intelligence answers questions like, "is this Internet Protocol address (IP) trying to abuse my service?" and "is this domain a known scam?" The endpoints in this category give you that signal as a structured score so you can plug it into automated workflows — fraud checks at signup, alert enrichment for security teams, and so on.
The CT Monitor endpoint, in plain language
In one sentence: Search CT logs (Certificate Transparency logs) for unauthorized cert issuance signals
Searches Certificate Transparency logs (the official internet standard/9162) via crt.sh for recent TLS (Transport Layer Security) certificates issued for a domain or wildcard. Surfaces unauthorized-issuance signals (issuer outside CAA-authorized set, sudden cert surge, unexpected wildcard) and provides recommendations to harden cert issuance hygiene.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Queries crt.sh JSON (JavaScript Object Notation) endpoint (free, no key) for cert history within a configurable window. Optional `include_subdomains=true` switches to wildcard-prefix search to surface certs issued for any subdomain. Returns full per-cert details (issuer, validity, SANs), aggregate stats (unique issuers, recent 30-day count, earliest/latest dates), an `alerts` array (severity-tagged signals), and remediation recommendations. Foundation for future webhook notifications.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the CT Monitor tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
CT logs (Certificate Transparency logs) are the canonical record of "every cert ever issued for my domain" and the leading early-warning signal for DNS (Domain Name System) hijacking, phishing infra staging, and shadow-IT issuance. This endpoint productizes the manual crt.sh workflow with alert thresholds and remediation guidance, eliminating the need for security teams to build their own CT-monitoring tooling.
Picture this in real life. Imagine a security engineer. Here's the situation they're walking into: Run a daily CT scan on all owned domains and alert when a cert appears from a CA outside your CAA-approved list — the canonical signal that an attacker has gained cert-issuance capability. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the CT Monitor tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the CT Monitor tool is built for you:
Is this domain or IP address known for fraud, phishing, or abuse?
Should my signup form, payment flow, or comment system trust this visitor?
Is someone out there registering lookalike domains targeting my brand?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Trust and safety teams, fraud analysts, brand-protection managers, security operations engineers, and product teams running open signup flows. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and you find out a domain or IP was malicious only after it has already cost you money or trust. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the pro plan. The technical details: `GET /v1/domain/ct-monitor`.
When would I actually use this?
If you're still on the fence about whether the CT Monitor tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security engineer, a brand protection / SOC, and a cloud architect — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: Unauthorized Issuance Detection
Imagine you're a security engineer. Run a daily CT scan on all owned domains and alert when a cert appears from a CA outside your CAA-approved list — the canonical signal that an attacker has gained cert-issuance capability.
Why it matters: Detect CA-based attacks (DNS (Domain Name System) hijacks, BGP MITM, internal credential abuse) within hours of issuance, before traffic interception begins.
Story 2: Phishing-Infra Early Warning
Imagine you're a brand protection / SOC. Monitor CT logs (Certificate Transparency logs) for typosquat variants of your brand — squatters frequently obtain Let's Encrypt certs days before launching campaigns.
Why it matters: File takedown requests during the prep window, denying the attacker the activation moment.
Story 3: CAA Hygiene Audit
Imagine you're a cloud architect. Compare actual CT issuers vs your published CAA records — a mismatch indicates either a CAA misconfiguration or an unauthorized issuance pathway.
Why it matters: Close the gap between policy (CAA) and reality (CT logs (Certificate Transparency logs)).
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the CT Monitor tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
Inside a signup form, payment flow, or comment system, to score risk in real time.
When investigating a customer complaint about a suspicious link or message.
On a recurring schedule, to monitor lookalike domains targeting your brand.
During incident response, to enrich an alert with reputation context.
If you can see yourself in even one of those bullets, the CT Monitor tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the CT Monitor tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the CT Monitor tool to check example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/domain/ct-monitor?domain=example.com"What you need to provide
You need to provide 3 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to monitor | example.com |
include_subdomains | string | Optional | When `true` (default), query CT for `%.<domain>` (wildcard subdomain match). Set to `false` to query the bare apex only. | true |
limit | string | Optional | Max certs to return (1-200, default 50) | 50 |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The queried domain |
scope | string | "apex" or "apex_and_subdomains" |
total_certs | number | Number of certs returned |
certs | array | Per-cert details: issuer, issuer_org, not_before, not_after, sans[], id |
unique_issuers | array | Distinct issuer organization names across results |
most_recent | string | ISO timestamp of most-recently-issued cert |
earliest | string | ISO timestamp of earliest cert in the window |
recent_30d_count | number | Cert-issuance count in the last 30 days |
alerts | array | Severity-tagged alerts (cert_surge, wildcard_present, unexpected_issuer, issuer_sprawl) |
recommendations | array | Remediation steps for the surfaced alerts |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.
TLS (Transport Layer Security) — The encryption that puts the 'S' in HTTPS. It scrambles data so nobody between you and a website can read it.
CT logs (Certificate Transparency logs) — Public, append-only ledgers that record every HTTPS certificate ever issued. Useful for finding all the subdomains of a website, even ones the owner forgot about.
JSON (JavaScript Object Notation) — A lightweight format for sending data between programs. Looks like { "name": "example", "age": 5 }. Used by basically every modern web API.
RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.