Certificate Transparency Logs: The Recon Tool You're Probably Not Using

What Certificate Transparency Logs Are

Certificate Transparency is a framework defined in RFC 6962 that requires Certificate Authorities to publicly log every SSL/TLS certificate they issue. The logs are append-only — certificates can be added but never removed or modified.

The system was created after several high-profile CA compromises. In 2011, a Dutch CA called DigiNotar was breached and attackers issued fraudulent certificates for google.com, *.google.com, and hundreds of other domains. The certificates were valid, trusted by browsers, and completely invisible to the domain owners. CT logs exist to make that kind of attack detectable.

Since 2018, all major browsers require CT compliance for new certificates. If a CA issues a certificate without logging it to at least two CT logs, Chrome and Safari will show a trust warning. This means that in practice, every publicly trusted certificate issued since 2018 is in the CT logs.

The key insight for security practitioners: CT logs are a complete, searchable inventory of every SSL certificate ever issued for any domain. That includes certificates for subdomains that the organization may not want publicly known.

Why CT Logs Matter for Recon

Traditional subdomain enumeration relies on DNS brute-forcing (trying common subdomain names), DNS zone transfers (rarely work), search engine dorking, or passive DNS databases. All of these have gaps.

CT logs fill those gaps because they capture subdomains that:

• Don't resolve in DNS anymore — a staging server that was decommissioned but the certificate is still logged
• Use non-obvious names — jenkins-internal.example.com won't show up in a wordlist brute-force, but it will show up in CT logs if someone requested a certificate for it
• Are behind a WAF or CDN — the certificate reveals the subdomain even if the DNS points to a CDN that blocks direct enumeration
• Were only briefly active — a test environment that existed for two weeks still has its certificate permanently logged

CT log queries are also completely passive. You're reading a public database — there's no interaction with the target's infrastructure, no packets sent to their servers, and no entries in their access logs. It's the quietest recon technique available.

Using crt.sh for Subdomain Discovery

crt.sh is the most widely used CT log aggregator. It's maintained by Sectigo (formerly Comodo) and provides both a web interface and a JSON API.

The simplest query is a domain search. Visit https://crt.sh/?q=example.com in a browser, or use the JSON API for automation:

curl -s "https://crt.sh/?q=example.com&output=json" | jq '.[].common_name' | sort -u

This returns every unique common name (CN) from certificates issued for example.com and its subdomains. A typical result might include:

example.com
www.example.com
mail.example.com
staging.example.com
api.example.com
dev-api.example.com
jenkins.internal.example.com
*.example.com

That last entry — *.example.com — is a wildcard certificate. It means someone requested a certificate that covers every possible subdomain. Wildcard certificates are common, but they're also a signal worth investigating.

For a more detailed query that includes issuer information and expiry dates:

curl -s "https://crt.sh/?q=example.com&output=json" | \
  jq -r '.[] | [.common_name, .issuer_name, .not_after] | @tsv' | \
  sort -u

This gives you the subdomain, who issued the certificate, and when it expires — three data points that each tell a story.

What to Look For in CT Log Results

Raw CT log data is noisy. A large organization might have thousands of certificate entries. Here's what matters:

Wildcard Certificates

A wildcard certificate (*.example.com) covers every subdomain at that level. From a security perspective, wildcards expand the attack surface — if the private key is compromised, every subdomain is affected. They also suggest the organization has many subdomains, which means more potential targets.

Expired Certificates

An expired certificate for staging.example.com tells you two things: that subdomain existed at some point, and the organization may not be actively managing it. Expired certificates on active services cause browser warnings and may indicate neglected infrastructure — exactly the kind of target that's likely to have unpatched vulnerabilities.

Certificates Expiring Soon

Certificates expiring within 30 days that haven't been renewed suggest manual certificate management (no automated renewal via Let's Encrypt or similar). Manual processes are error-prone — these services may have other operational gaps.

Unexpected Certificate Authorities

If an organization primarily uses Let's Encrypt but one subdomain has a certificate from an unfamiliar CA, that's worth investigating. It could be a legitimate exception (a third-party service), or it could indicate unauthorized certificate issuance. The list of well-known trusted CAs includes Let's Encrypt, DigiCert, Sectigo, GlobalSign, GoDaddy, Amazon, Google Trust Services, Cloudflare, and Entrust.

Internal-Looking Subdomains

Names like jenkins.internal.example.com, grafana.example.com, admin-panel.example.com, or vpn.example.com reveal internal infrastructure. These are high-value targets for further investigation — they often run management interfaces with weaker security controls than public-facing services.

Automated CT Log Monitoring

Manual crt.sh queries work for one-off recon, but continuous monitoring is where CT logs become a defensive tool. SecurityClaw's certificate-transparency-monitor skill (PR #812, merged April 7, 2026) automates this entire workflow.

The skill queries crt.sh for a target domain and produces structured findings across four categories:

The skill also extracts and deduplicates all subdomains, providing a clean subdomain list that feeds into the next phase of recon — DNS resolution, port scanning, and service enumeration.

This maps to OWASP A02 (Cryptographic Failures) — specifically the detection of weak or misconfigured certificate infrastructure. It's tagged as passive recon, meaning it can run without any interaction with the target.

How Attackers Use CT Logs

CT logs are a standard part of the attacker recon playbook. Here's the typical workflow:

Step 1: Subdomain harvesting. Query crt.sh for the target domain. Extract all unique common names. This often reveals 10-100x more subdomains than DNS brute-forcing alone.

Step 2: DNS resolution. Resolve each discovered subdomain to check which ones are still active. Subdomains that resolve to internal IP ranges (10.x.x.x, 172.16.x.x, 192.168.x.x) are particularly interesting — they may be accessible via SSRF or if the attacker gains internal network access.

Step 3: Service fingerprinting. For active subdomains, identify what's running. A subdomain like grafana.example.com tells you exactly what to expect. Port scan and fingerprint the services.

Step 4: Targeted exploitation. Internal tools (Jenkins, Grafana, Kibana, admin panels) often have weaker authentication, default credentials, or known vulnerabilities. The CT log gave the attacker the subdomain; the rest is standard exploitation.

The entire CT log query phase is invisible to the target. No packets, no logs, no alerts. By the time the attacker starts DNS resolution (step 2), they already know exactly which subdomains to target.

Real-world examples of CT log-assisted attacks include the discovery of internal admin panels during bug bounty programs, identification of forgotten staging environments running outdated software, and enumeration of API endpoints that weren't documented in public-facing materials.

Defensive CT Log Monitoring

The same technique that helps attackers find your subdomains can help you find them first. Defensive CT log monitoring serves three purposes:

1. Shadow IT detection. When a developer spins up a service and requests a certificate for my-test-app.yourcompany.com, that certificate appears in CT logs — even if the service was never registered with IT. Monitoring CT logs catches unauthorized services that DNS monitoring might miss.

2. Certificate hygiene. Expired certificates cause service disruptions and erode user trust. Certificates expiring within 30 days need attention. Automated CT monitoring catches these before they become incidents.

3. Unauthorized certificate issuance. If someone obtains a certificate for your domain from a CA you don't use, that's a red flag. It could indicate a domain validation bypass, a compromised CA, or a phishing campaign using a lookalike domain. CT monitoring detects this.

For organizations running bug bounty programs, proactive CT log monitoring is especially important. Every subdomain in your CT logs is a subdomain that bug bounty hunters will find. Better to find and secure them yourself first.

Tools and Resources

CT log querying is well-supported across the security tooling ecosystem:

• crt.sh — Free web interface and JSON API. The standard starting point for CT log queries.
• Facebook CT Monitor — Facebook's certificate transparency monitoring tool. Useful for monitoring specific domains over time.
• Censys — Internet-wide scanning platform that includes CT log data alongside port scan and service fingerprint data.
• subfinder — Passive subdomain enumeration tool that includes crt.sh as one of its data sources.
• SecurityClaw certificate-transparency-monitor — Automated skill that queries crt.sh and produces structured findings (wildcard certs, expiring certs, unexpected CAs). Integrates with SecurityClaw's campaign runner for continuous monitoring.

For practitioners building their own CT monitoring pipeline, the crt.sh JSON API is the simplest integration point. A basic monitoring script that runs daily, compares results against a known subdomain baseline, and alerts on new discoveries takes about 50 lines of Python.

For deeper reading on certificate security and cryptographic failures:

• The Web Application Hacker's Handbook — covers certificate validation and TLS security in the context of web application testing
• Black Hat Python — includes practical examples of SSL/TLS interception and certificate manipulation

CT logs are one of the few recon techniques that's simultaneously useful for attackers and defenders, completely passive, completely legal, and completely free. If you're not using them, you're leaving information on the table that your adversaries are already collecting.