A bug bounty researcher targets a fintech company. Before touching a single port, they run a query on crt.sh. The result: 47 subdomains, including staging environments, internal APIs, and an abandoned admin portal. The staging server still has default credentials. The entire discovery took 4 minutes and left no trace in the target's logs.
Every TLS certificate your organization issues enters a permanent, searchable public ledger the moment it is registered. Attackers read your infrastructure map from CT feeds before DNS even propagates. This is not a vulnerability you can fix: it is the architecture of the system that keeps the web secure. Knowing what is visible is the prerequisite for defending what is exposed.
CT Logs Are Not Optional: Chrome Has Required Them Since April 2018
Certificate Transparency is not a security recommendation. RFC 6962, published in 2013, created the cryptographically verifiable, append-only log infrastructure that all public CAs are required to use. RFC 9162, the current specification, maintains the central principle: every certificate issued must be submitted to a log before any browser will trust it.
Chrome began rejecting certificates without valid Signed Certificate Timestamps (SCTs) in April 2018. An SCT is cryptographic proof that the certificate was submitted to an approved log. A cert issued by any public CA without that record produces a browser certificate error, regardless of the issuer. Safari followed the same path. There is no exception for staging environments, certs issued by public CAs for internal use, or any other special category.
The current volume is 13.75 billion certificates logged through Q2 2026, growing at 33% year over year. The Google CT dashboard tracks certificate volume in real time — the cumulative total exceeded 13.75 billion certificates by Q2 2026. Let's Encrypt is migrating to 45-day certificates by February 2028, which will roughly double the annual issuance volume. Any infrastructure team that creates a subdomain for a pilot project, a QA environment, or a temporary microservice is publishing that hostname to the ledger. Your organization's complete historical inventory becomes more accessible and more searchable every week.
What a Single crt.sh Query Reveals in 4 Minutes
crt.sh is maintained by Sectigo and indexes all approved CT logs. It requires no authentication. The query https://crt.sh/?q=%.example.com&output=json returns all certificates containing that domain in the SAN (Subject Alternative Name) fields, along with issuance dates, revocation status, and issuer data.
This pattern appears across dozens of public HackerOne and Bugcrowd disclosures — researchers query crt.sh before any scan and routinely find 30 to 80 subdomains the target did not know were visible. Zero requests reach the target's infrastructure, and zero entries appear in access logs. CT enumeration is consistently the first reconnaissance phase in black-box engagements.
SAN fields in multi-domain certificates expose entire hostname families in a single record. A cert issued for app.company.com, api.company.com, admin.company.com reveals the complete naming architecture in one entry. Expired and revoked certificates remain permanently in CT logs: decommissioned infrastructure stays discoverable indefinitely. Issuance dates reveal deployment timelines and corporate acquisition histories with day-level precision.
Internal naming patterns like vpn., jenkins., gitlab., and staging. appear regularly in CT queries across published pentest reports. These prefixes are invisible to external DNS scans, but they are all in the ledger. The difference between a forgotten asset and a documented critical finding is a 4-minute query with zero requests to the target.
Certstream: The Real-Time Feed Attackers Watch While You Sleep
Certstream is an open-source WebSocket server that aggregates all major CT logs into a single real-time feed. It processes approximately 27 domains per second globally. Anyone can subscribe to the feed using Python, Go, or JavaScript libraries in under 50 lines of code, with no credentials required.
Let's Encrypt certificates appear in CT logs within seconds of issuance, typically before the associated DNS record has fully propagated to global resolvers. The documented phishing pipeline works like this: the attacker monitors Certstream for new cert events from target brands, automatically registers a typosquat like paypa1-secure.com or yourbank-login.net, obtains a Let's Encrypt certificate, and deploys a phishing page. The full pipeline runs in under 10 minutes.
Facebook uses the same feed defensively. Facebook's CT monitor scans the feed and alerts registered domain owners about new issuances, including records with homographs (Unicode characters that look visually similar to Latin letters) and typosquats. Updates are hourly. Same data, same feed: the difference is who got there first and what they did with the information.
DigiNotar and Symantec: When CT Logs Redefined Who Controls the Infrastructure Narrative
DigiNotar was a Dutch CA compromised in 2011. The attacker issued a wildcard certificate for *.google.com and over 500 fraudulent certs. Those certs were used in MITM attacks against 300,000 or more Iranian Gmail users, intercepting traffic for weeks before discovery. DigiNotar was removed from all major browsers within days and declared bankruptcy within weeks. RFC 6962 was architected as a direct response: to make it impossible for a CA to issue certs without leaving a publicly auditable trail.
Symantec operated a sub-CA that issued an unauthorized Extended Validation certificate for google.com between 2015 and 2017. The discovery was made by Google's CT monitoring, not by Symantec's internal audit. The investigation through CT logs identified 30,000 improperly issued certs across 76 or more domains. Google required CT for all Symantec certs and then implemented graduated distrust. Symantec sold its PKI business to DigiCert for $950M in 2017. Without CT logs, Symantec would have controlled the investigation narrative.
The phishing pipeline via Certstream has been active through 2024-2026 and is documented by security researchers and threat intel teams. The difference from earlier eras is response time: the attacker operates in minutes while the typical SOC alert takes hours. A cert appears in the log, the typosquat is live, and the campaign begins before any blocklist is updated.
Monitoring Your Own Issuances Costs Zero
Your organization's inventory in CT logs already exists. The only remaining variable is whether you reviewed it before the attacker did, and whether you will know when the next entry is added. Teams that adopted CT monitoring report finding certs issued by shadow IT or misconfiguration before any internal scanner detected them.
crt.sh is free, requires no authentication, and supports wildcard queries with JSON output for automation. SSLMate CertSpotter is open-source and self-hostable: it monitors all approved CT logs and alerts on new certs for configured domains via email or webhook. Certstream libraries in Python or Go allow subscribing to the real-time feed and filtering by domain pattern in under 50 lines.
Wildcard certificates (*.example.com) prevent hostname enumeration at that subdomain level from CT logs. This is a real mitigation, not a solution: specific certs issued before the migration to wildcard remain in the logs permanently, and second-level wildcards do not exist in TLS.
intel.mago.team (MAGO team tool) monitors certificate issuances for configured domains and alerts on new records in CT logs. Practical audit: run a crt.sh query for your primary domains every quarter and cross-reference against the known asset inventory. Every unknown hostname is a finding.
CT infrastructure was built to constrain CA power, not to protect your organization's naming conventions from enumeration. Every staging hostname, internal API pattern, and acquired company subdomain you ever secured with a publicly trusted cert is in a permanent, searchable ledger. Attackers already have your inventory. The question is whether you reviewed the same ledger.
Top comments (0)