Every publicly trusted SSL/TLS certificate must be logged in public Certificate Transparency logs before browsers will accept it. This creates a permanent, searchable record of 2.5+ billion certificates containing every domain and subdomain they cover. OSINT investigators query these logs through aggregators like crt.sh and Censys to discover subdomains, internal hostnames, staging servers, and phishing infrastructure — all without sending a single packet to the target. Research shows CT honeypot domains receive scanning traffic within 73 seconds of certificate issuance.
What Is Certificate Transparency?
Certificate Transparency is an open framework, standardized in RFC 6962, that requires Certificate Authorities (CAs) to publish every SSL/TLS certificate they issue to publicly accessible, append-only, cryptographically verified logs. The system was created in response to the 2011 DigiNotar compromise, where attackers issued fraudulent certificates for Google, Yahoo, and other major domains without detection. Google engineers Ben Laurie, Adam Langley, and Emilia Kasper designed CT to ensure that no certificate could be issued in secret.
The system works through Signed Certificate Timestamps (SCTs): when a CA submits a certificate to a log, the log returns a cryptographic promise (the SCT) to include it within a Maximum Merge Delay of 24 hours. Browsers then verify that certificates carry valid SCTs before establishing a TLS connection. As of 2025, all three major browser engines enforce CT: Chrome has required it since April 2018, Apple platforms enforce it system-wide across all TLS connections, and Firefox began enforcing it in version 135 (February 2025).
The logs themselves are structured as Merkle trees — binary hash trees where each leaf is a certificate and each parent node is the hash of its children. This structure allows anyone to verify that a certificate exists in the log without downloading the entire dataset, and to prove that the log has not been tampered with. Logs are operated by five trusted organizations: Google (Argon and Xenon series), Cloudflare (Nimbus and Azul series), Sectigo (Mammoth and Sabre), Let’s Encrypt (Oak), and DigiCert (Nessie and Yeti).
Why CT Logs Are an OSINT Goldmine
Every certificate contains two critical fields for OSINT investigators. The Common Name (CN) lists the primary domain, and the Subject Alternative Name (SAN) extension lists every additional hostname the certificate covers. A single certificate might list dozens of subdomains in its SAN field — including development servers, staging environments, internal tools, API endpoints, and customer-specific hostnames that the organization may not have intended to make public.
Unlike DNS enumeration or brute-forcing, querying CT logs is entirely passive: you never contact the target organization. The data is public by design and freely searchable. And because CT logs are append-only and permanent, certificates for subdomains that have since been decommissioned remain discoverable indefinitely, providing historical infrastructure intelligence that no other passive source offers.
What CT Logs Reveal
Research from the ACM Internet Measurement Conference (IMC 2018) demonstrated that CT logs reveal far more than just subdomains. Investigators can extract: internal hostnames (e.g., dev-database.internal.company.com), project codenames (e.g., project-phoenix.staging.company.com), customer-specific infrastructure (e.g., acme-corp.clients.company.com), employee usernames embedded in domain names, development and staging environments, VPN and remote access portals, and API endpoints. The same research introduced a CT honeypot showing that newly issued certificates receive automated scanning traffic within 73 seconds to 3 minutes, confirming that threat actors actively monitor CT logs in real time.
How to Query CT Logs: Practical Methods
Method 1: crt.sh Web Interface
The most widely used CT search tool is crt.sh, a free aggregator maintained by Sectigo. It indexes certificates from all major CT logs and provides both a web interface and API access. To search, enter %.example.com in the search box to find all certificates with subdomains of example.com. The % character acts as a wildcard.
Method 2: crt.sh JSON API
For scripting and automation, crt.sh provides a JSON endpoint:
This returns a deduplicated list of every subdomain that has ever appeared in a certificate for example.com.
Method 3: Direct PostgreSQL Access
For high-volume queries, crt.sh exposes its PostgreSQL database directly:
This bypasses rate limits on the web API and returns results faster for large domains with thousands of certificates.
Method 4: Real-Time Monitoring with Certstream
For ongoing monitoring, Certstream provides a real-time firehose of all certificates as they are logged. This is primarily used for phishing detection — monitoring for typosquatted or brand-impersonating domains as their certificates are issued.
CT Log Aggregators Compared
| Platform | Data Source | API Access | Cost | Best For |
|---|---|---|---|---|
| crt.sh | All major CT logs | JSON API + PostgreSQL | Free | General subdomain enumeration |
| Censys | CT logs + internet-wide scans | REST API + Python SDK | Free tier / paid | Correlating certs with live hosts |
| SSLMate Cert Spotter | 40+ CT logs (4B+ entries) | Certificate Search API | Free basic / $29+/mo | Reliable monitoring + alerts |
| Certstream | Real-time CT log stream | WebSocket firehose | Free / self-host | Phishing detection |
| Merklemap | Full CT history (~100B rows) | Search API | Paid | Historical deep research |
| Facebook CT Monitoring | Major CT logs | Email alerts | Free | Domain owner monitoring |
OSINT Investigation Workflows
Workflow 1: Full Subdomain Discovery
Start with a crt.sh query for %.target.com. Extract all unique subdomains from the CN and SAN fields. Cross-reference results with DNS resolution to identify which subdomains are still live. Feed live results into further reconnaissance: HTTP header analysis, technology fingerprinting, and content discovery. This workflow consistently discovers subdomains that brute-forcing misses — research shows CT log enumeration finds 17.7 million previously unknown fully qualified domain names that do not appear in other passive DNS datasets like Project Sonar.
Workflow 2: Organizational Infrastructure Mapping
Search CT logs by the Organization (O) field in certificates rather than by domain name. This reveals all domains and subdomains belonging to a specific organization, even across different TLDs. This technique is especially valuable for mapping acquisitions, subsidiaries, and shadow IT that may not share the parent company’s primary domain.
Workflow 3: Phishing Campaign Detection
Monitor CT logs for certificates containing your brand name in the domain. Phishing indicators include: typosquatted domains with DV certificates, certificates obtained within hours of domain registration, short validity periods, brand names in subdomains of unknown domains (e.g., paypal-login.malicious.com), and the use of free CAs like Let’s Encrypt (over 90% of phishing sites now use HTTPS). Research from RAID 2022 found that CT-based phishing detection can classify domains with 95%+ accuracy using certificate metadata alone.
Workflow 4: Historical Infrastructure Analysis
Because CT logs are append-only, expired and revoked certificates remain searchable. This means you can discover infrastructure that no longer exists — decommissioned staging servers, abandoned API endpoints, and previous hosting providers. Combined with the Wayback Machine and historical WHOIS data, CT history creates a comprehensive timeline of an organization’s digital footprint evolution.
CT Log Operators and Architecture
| Operator | Log Series | Sharding | Region | Status |
|---|---|---|---|---|
| Argon, Xenon, Solera | Half-year | US (Argon), EU (Xenon/Solera) | Trusted by Chrome + Apple | |
| Cloudflare | Nimbus, Azul | Annual / half-year | Global edge network | Trusted by Chrome + Apple |
| Sectigo | Mammoth, Sabre | Half-year | N/A | Trusted by Chrome + Apple |
| Let’s Encrypt | Oak | Half-year | US | Trusted by Chrome + Apple |
| DigiCert | Nessie, Yeti | Annual | N/A | Trusted by Chrome + Apple |
All logs use temporal sharding — each shard only accepts certificates expiring within a specific time window (typically six months or one year). This prevents any single log from growing unbounded. Cloudflare pioneered this approach with the Nimbus series. In 2025, Chrome began accepting a new static CT API log format alongside the original RFC 6962 format, with plans to complete migration by end of 2025. Cloudflare’s Azul logs are the first to use this new architecture, running on Workers across their global network.
The Privacy Double Edge
CT’s transparency is simultaneously its greatest strength and its most significant risk. The same properties that let investigators discover phishing domains also let attackers enumerate an organization’s internal infrastructure. Academic research from WPES 2019 documented how CT logs leak employee usernames, internal project codenames, customer names, and organizational structure through subdomain naming conventions.
Organizations can mitigate this exposure through several strategies. The most effective is using wildcard certificates (*.example.com), which are logged once under the wildcard name without exposing specific subdomains. Other approaches include: avoiding descriptive subdomain names for internal services, using separate internal CAs (not publicly trusted) for internal-only infrastructure, and actively monitoring CT logs for unauthorized certificate issuance via tools like Facebook CT Monitoring or SSLMate Cert Spotter.
2025–2026 Developments
Several significant changes are reshaping the CT ecosystem. Firefox CT enforcement (February 2025) means all three major browser engines now require CT, making it truly universal. Let’s Encrypt six-day certificates (first issued February 2025) dramatically reduce the compromise window but will significantly increase CT log volume — potentially 16–20x more entries. The static CT API introduced by Cloudflare’s Azul logs replaces the original RFC 6962 Merkle tree structure with a tile-based design that is faster, easier to operate, and supports much smaller merge delays. And post-quantum certificates on the horizon will increase per-entry storage by roughly 4x, as ML-DSA44 signatures are significantly larger than current ECDSA signatures.
Key Terminology
- Signed Certificate Timestamp (SCT)
- A cryptographic proof from a CT log operator promising that a submitted certificate will be incorporated into the log within the Maximum Merge Delay (typically 24 hours). Browsers verify SCTs before trusting certificates.
- Maximum Merge Delay (MMD)
- The maximum time a log operator has to incorporate a submitted certificate into the log after issuing an SCT. Currently set at 24 hours for most logs.
- Temporal Sharding
- Splitting a CT log into multiple shards, each accepting only certificates with expiry dates in a specific time window. Prevents unbounded log growth.
- Precertificate
- A version of a certificate submitted to CT logs before the final certificate is issued. Contains a special poison extension that prevents it from being used for TLS, allowing the CA to obtain SCTs before issuing the real certificate.
- Subject Alternative Name (SAN)
- An X.509 certificate extension listing additional hostnames the certificate covers beyond the Common Name. A single certificate can list dozens of SANs, making this field the primary source of subdomain intelligence from CT logs.
- Wildcard Certificate
- A certificate covering all subdomains of a domain (e.g., *.example.com). Logged once in CT without exposing specific subdomain names. The primary defense against CT-based infrastructure enumeration.
- Static CT API
- A next-generation CT log format based on tile-structured Merkle trees. Faster and easier to operate than the original RFC 6962 design. Cloudflare’s Azul logs are the first production implementation.
Sources
certificate.transparency.dev — Official CT project site (2.5B+ certificates logged since 2013). Scheitle et al., "The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem," ACM IMC 2018 — CT honeypot showing scanning within 73 seconds. Fasllija et al., "When Certificate Transparency Is Too Transparent," ACM WPES 2019 — Privacy implications of CT exposure. Let’s Encrypt 10-Year Anniversary (Dec 2025) — 10M certificates/day issuance rate. Cloudflare Azul CT Log (Jul 2025) — Static CT API implementation. MDN Web Docs — Firefox CT enforcement from version 135. Let’s Encrypt Short-Lived Certificates (Feb 2025) — Six-day certificate lifetimes. SSLMate — 40+ logs, 4B+ entries monitored. Al-Sabah et al., "Content-Agnostic Detection of Phishing Domains using Certificate Transparency and Passive DNS," RAID 2022 — 95%+ phishing detection accuracy from CT metadata. SSL Insights 2025 — 86.9% HTTPS adoption.
Frequently Asked Questions
What is Certificate Transparency and why does it matter for OSINT?
Certificate Transparency (CT) is an open framework requiring CAs to log every SSL/TLS certificate to public logs. Over 2.5 billion certificates have been logged since 2013. For OSINT investigators, CT logs are a goldmine: every certificate contains the domain names it covers (in the CN and SAN fields), revealing subdomains, internal hostnames, staging environments, and infrastructure that organizations may not realize is publicly visible — all without sending a single packet to the target.
How do I search Certificate Transparency logs for a domain?
The most common method is querying crt.sh, a free CT log aggregator. Search for %.example.com to find all certificates with subdomains. The JSON API endpoint (crt.sh/?q=%25.example.com&output=json) returns structured data for scripting. For real-time monitoring, use Certstream. For programmatic access at scale, crt.sh also exposes a PostgreSQL database on port 5432 (user: guest, database: certwatch).
Can Certificate Transparency logs detect phishing campaigns?
Yes. ML models achieve 95%+ accuracy classifying phishing from CT metadata alone. Phishing indicators include: typosquatted domains with DV certificates, certificates obtained within hours of domain registration, short validity periods, and brand names in subdomains of unknown domains. Real-time CT monitoring via Certstream can flag suspicious certificates within minutes of issuance.
What are the privacy implications of Certificate Transparency?
CT logs permanently expose every hostname for which a certificate is issued. Research from IMC 2018 showed CT honeypot domains received scanning within 73 seconds. This reveals internal infrastructure, project codenames, and employee usernames. The primary mitigation is using wildcard certificates (*.example.com) to avoid exposing specific subdomain names.