Skip to main content
Guides/Website Security

CT Logs: a beginner's guide

Search Certificate Transparency logs

EdgeDNS Team··9 min read

Certificate Transparency: the public log of every SSL certificate

Certificate Transparency (CT) is a system, launched by Google in 2013 and required by Chrome since 2018, that publishes a public, append-only log of every SSL certificate issued by every public certificate authority. The point of CT is to make certificate mis-issuance impossible to hide. Before CT, a CA could be tricked or coerced into issuing a fraudulent certificate for a high-value domain (say, `google.com` or `bankofamerica.com`), and the certificate could be used for an attack without the legitimate domain owner ever knowing. With CT, every issuance is logged publicly within hours. Anyone — including the legitimate domain owner — can monitor the logs and see new certificates as they are issued.

You should care because CT logs are the only way to detect that someone has obtained a fraudulent certificate for your domain before it gets used in an attack. Setting up monitoring is easy: anyone can subscribe to alerts for their domain via free services that watch the logs and email you whenever a new cert appears. For brands, banks, or any organization where impersonation would be a serious incident, this monitoring is one of the cheapest pieces of security infrastructure available. It is also the basis for an entire category of security research — academic papers regularly use CT log data to study CA behavior, detect mis-issuance, and find misconfigured certificates across the public internet.

The five things every CT log check looks at:

  • What certificates have been issued for this domain in the last N days? A baseline answer is the starting point for any audit.

  • Are there any unexpected certificates? Certificates from CAs you don't use, for subdomains you don't own, or with timestamps you can't account for, are red flags.

  • Are there any wildcard certificates you didn't authorize? Wildcards have outsized blast radius and warrant extra scrutiny.

  • Is the issuance velocity normal? A sudden spike in new certificates is suspicious — and can also be a sign of a misconfigured CI/CD pipeline issuing duplicates.

  • Are there any pre-certificates (the staging step) that were never finalized? These can indicate a failed issuance attempt that may be worth investigating.

Three questions a CT log check answers:

  • Has any certificate authority issued a certificate for my domain in the last week?

  • Are any of those certificates from a CA I don't use, or for a subdomain I didn't authorize?

  • Is anyone trying to impersonate my brand by getting a cert for a similar-looking domain?

The cost of skipping CT log monitoring is the small but real risk that a fraudulent certificate gets issued and used against your brand without you ever finding out until after the damage. The fix is to subscribe to a free CT monitoring service (or build your own using public log feeds). The CT specification is in RFC 6962, and the public logs are queryable at crt.sh and other transparency search engines.

The CT Logs endpoint, in plain language

In one sentence: Search Certificate Transparency logs

Searches Certificate Transparency (CT) logs for certificates issued for a domain via the crt.sh aggregator. Supports cursor-style pagination (offset, limit up to 100) and ISO-8601 `since` filtering for polling-style CT monitoring. Default cache TTL (time to live) is 30 minutes so newly-issued certs surface quickly.

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 for CT log entries matching the domain. Returns deduplicated entries with issuer name, log entry timestamp, and crt.sh certificate ID. When `truncated: true`, the `pagination.next_offset` field gives the cursor for the next page. The optional `since` parameter filters to entries logged at or after the supplied timestamp — pair it with a short polling interval to detect unauthorized issuance in near real time.

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 Logs 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 log entries reveal patterns invisible in the active certificate alone: CA changes over time, certificate churn rates, subdomain discovery through historical SANs, and detection of unauthorized issuance. With `since` filtering plus the 30-minute cache, this endpoint becomes a polling-friendly monitor rather than a one-shot historical view.

Picture this in real life. Imagine a security researcher. Here's the situation they're walking into: Discover subdomains from expired and historical certificates that no longer appear in the active certificate or DNS (Domain Name System) records. 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 Logs 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 Logs tool is built for you:

  • Is my website encrypted properly, or are visitors going to see a scary browser warning?

  • Am I missing any of the security headers that modern browsers expect?

  • Could a known weakness on my site quietly be costing me trust, traffic, or compliance?

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. Founders and freelancers running their own sites, agencies handing off projects to clients, security and compliance teams chasing audit findings, and developers hardening login pages. 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 visitors get browser warnings, search engines lose trust in your site, and a single missed setting can become a public security incident. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

Info:

Available on the developer plan. The technical details: `GET /v1/domain/ct-logs`.

When would I actually use this?

If you're still on the fence about whether the CT Logs tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security researcher, a security operations, and a PKI administrator — 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: Historical Subdomain Enumeration

Imagine you're a security researcher. Discover subdomains from expired and historical certificates that no longer appear in the active certificate or DNS (Domain Name System) records.

Why it matters: Find forgotten subdomains and legacy infrastructure not visible through current DNS (Domain Name System) enumeration.

Story 2: Unauthorized Issuance Detection

Imagine you're a security operations. Search CT log history for certificates issued by unauthorized CAs or for unexpected subdomains.

Why it matters: Detect rogue certificate issuance that could indicate domain compromise or CA misbehavior.

Story 3: Certificate Lifecycle Analysis

Imagine you're a PKI administrator. Analyze CA usage patterns over time — certificate rotation frequency, issuer changes, and automation effectiveness.

Why it matters: Optimize certificate management by identifying lifecycle patterns and automation gaps.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the CT Logs 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:

  • After every site redesign or platform migration.

  • Before a penetration test, security review, or vendor questionnaire.

  • When your SSL certificate is about to expire and you want to confirm the renewal worked.

  • On a recurring monthly schedule, so you catch new issues before attackers do.

If you can see yourself in even one of those bullets, the CT Logs 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 Logs 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 Logs 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.

Tip:

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.

bash
# 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-logs?domain=example.com"

What you need to provide

You need to provide 4 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.

FieldTypeRequired?What it meansExample

domain

string

Yes

The domain to search CT logs (Certificate Transparency logs) for

example.com

offset

number

Optional

Cursor — skip the first N entries (use response.pagination.next_offset to advance).

0

limit

number

Optional

Page size, 1–100 (default: 20).

20

since

string

Optional

ISO-8601 timestamp; only return entries logged at or after this time. Use with periodic polling for unauthorized-issuance monitoring.

2026-05-01T00:00:00Z

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.

FieldTypeWhat you'll see in it

domain

string

The queried domain

certificates

array

Certificate entries from CT logs (Certificate Transparency logs) with issuer, timestamp, and id

scts

array

[deprecated] Alias for certificates — will be removed once clients migrate.

hasSCTs

boolean

Whether certificate entries were found in CT logs (Certificate Transparency logs)

count

number

Total certificate entries returned in this page

truncated

boolean

Whether results were truncated — more entries exist beyond the current page. See pagination.next_offset.

source

string

Data source (crt.sh aggregator)

note

string

Additional context about the CT log search

pagination

object

{ offset, limit, next_offset } — next_offset is the cursor to use for the next page when truncated is true.

since

string | null

Echo of the since filter that was applied (null when unset).

embedded_sct

object | null

Phase 2: real embedded SCT count parsed from the cert's 1.3.6.1.4.1.11129.2.4.2 extension. { count, chrome_compliant, note }. Chrome policy requires ≥2 SCTs from distinct operators (≥3 for ≥180-day certs issued after 2022-04-15). Distinct-operator verification is approximated by raw count — full op-distinctness needs the CT log registry (Phase 2 follow-on).

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.

TTL (time to live) — How long, in seconds, a piece of information should be remembered before being looked up again.

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.

Need Programmatic Access?

Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.