Certificate Transparency Logs for Subdomain Discovery
What is certificate transparency?
Certificate transparency (CT) is a framework that requires Certificate Authorities to publish every certificate they issue to public, append-only logs. It was developed by Google and standardised in RFC 6962 to address a fundamental problem: CAs could issue certificates for any domain, and domain owners had no way to know about or challenge mis-issued certificates.
The security benefit is auditability. Domain owners can monitor CT logs for unexpected certificates issued for their domains - a signal of CA compromise or fraudulent issuance.
The side benefit - and the one relevant to attack surface management - is that CT logs create a comprehensive, searchable record of every domain and subdomain that has ever had a public certificate.
How do you query CT logs for subdomains?
crt.sh
The most accessible interface to CT logs is crt.sh, a free web service maintained by Sectigo. Search for %.example.com to find all certificates issued for any subdomain of example.com.
The results include:
- The certificate’s Subject Alternative Names (SANs) - every domain the certificate covers
- The issuing CA
- The issuance date and expiry
- The certificate serial number
A single wildcard query against crt.sh often reveals hundreds of subdomains that don’t appear in any other public source.
Certstream
Certstream provides a real-time feed of newly issued certificates across all CT logs. Security teams can monitor this feed for certificates matching their domains, getting notified within seconds of a new certificate being issued.
This is useful for detecting:
- Shadow IT creating new services with public certificates
- Phishing attempts using similar-looking domain names
- Unexpected wildcard certificates
CT log APIs
For programmatic access, you can query CT logs directly:
- Google’s Argon and Xenon logs
- Cloudflare’s Nimbus log
- Let’s Encrypt’s Oak log
Most subdomain enumeration tools (Subfinder, Amass) include CT log querying as one of their passive sources.
What do CT logs reveal about your attack surface?
CT log queries surface subdomains that other techniques miss:
Internal services with public certificates. Many organisations use public CAs (especially Let’s Encrypt) for internal services - it’s simpler than running a private CA. This means grafana.internal.example.com, jenkins.corp.example.com, and vpn.example.com appear in CT logs even if they resolve only on internal networks.
Historical subdomains. CT logs are append-only. A certificate issued three years ago for old-app.example.com remains in the log permanently. Even if the service was decommissioned and the DNS record removed, the CT log entry persists - and the DNS record might still exist.
Wildcard patterns. Wildcard certificates (*.example.com, *.dev.example.com) reveal naming conventions. Knowing that an organisation uses a *.dev.example.com wildcard tells you that development services exist under that subdomain pattern - even though the wildcard doesn’t list individual services.
Third-party service integrations. When a SaaS platform provisions a custom domain certificate for your subdomain (e.g., help.example.com on Zendesk), that certificate appears in CT logs.
What are the limitations of CT log discovery?
CT logs are powerful but not complete:
No coverage for services without TLS. Services running on plain HTTP or non-web protocols (SSH, databases, SMTP without STARTTLS) don’t have certificates and won’t appear in CT logs.
No private CA coverage. Organisations using internal private CAs for their infrastructure won’t have those certificates in public CT logs. Large enterprises often use private CAs for internal services.
No DNS validation. A certificate in CT logs proves a CA issued a certificate for a domain name - it doesn’t prove the subdomain currently resolves or hosts a live service. You still need DNS resolution to confirm the subdomain is active.
Noise. Large organisations accumulate thousands of CT log entries over years. Not all represent current, active services. Filtering historical entries requires cross-referencing with live DNS resolution.
How SurfaceLoop handles this
SurfaceLoop’s subdomain discovery includes certificate transparency log analysis as one of its enumeration methods. CT findings are automatically cross-referenced with DNS resolution and service detection - so you see only the subdomains that are actually live and reachable, not historical noise.
See Subdomain Enumeration feature →How can CT logs be used as a defensive tool?
Beyond subdomain discovery, CT logs support several defensive use cases:
Phishing detection. Monitor CT logs for certificates issued for domains similar to yours (typosquatting). If someone obtains a certificate for exarnple.com or examp1e.com, CT log monitoring catches it at issuance time.
Unauthorised certificate detection. If a certificate is issued for your domain that you didn’t request, CT logs reveal it. This detects CA compromise, BGP hijacking used to pass domain validation, or insider threats issuing certificates outside normal processes.
Compliance verification. Some security policies require that all certificates for an organisation’s domains are issued by approved CAs. CT log monitoring verifies compliance.
How do you integrate CT logs into a subdomain enumeration workflow?
CT log querying should be one component of a multi-technique enumeration approach:
- Start with CT logs - they’re passive, free, and comprehensive for TLS-protected services
- Add DNS brute-forcing - catches subdomains without certificates
- Include passive DNS databases - reveals historical subdomains from DNS resolution data
- Layer in permutation scanning - discovers variants of subdomains found by other techniques
- Resolve and validate - confirm which discovered subdomains are currently live
- Assess security posture - scan live subdomains for vulnerabilities, exposed panels, and misconfigurations
This layered approach maximises coverage. No single technique finds everything - but together, they provide comprehensive visibility into your subdomain landscape.
Frequently asked questions
- What are certificate transparency logs? +
- Certificate transparency (CT) logs are public, append-only ledgers that record every SSL/TLS certificate issued by participating Certificate Authorities. They were created to detect mis-issued certificates but are also valuable for subdomain discovery.
- How do CT logs help with subdomain enumeration? +
- Every certificate includes the domain names it covers (in the Subject and Subject Alternative Name fields). By querying CT logs for your root domain, you get a list of every subdomain that has ever had a certificate issued for it - including internal services, staging environments, and forgotten assets.
- Are there limitations to using CT logs for discovery? +
- CT logs only reveal subdomains that have certificates. Services running without TLS, services using private CAs, and subdomains that never had a certificate will not appear. CT logs should be one technique among several, not the only enumeration method.
- Can attackers also use CT logs to find my subdomains? +
- Yes. CT logs are public by design, so anyone can query them. Attackers routinely use CT log searches as a passive reconnaissance step to map an organisation's attack surface without sending any traffic to the target.
- How often are certificate transparency logs updated? +
- CT logs are updated in near real-time. When a Certificate Authority issues a new certificate, it is typically logged within seconds. Services like Certstream provide a live feed of newly issued certificates across all monitored logs.
- Do wildcard certificates appear in CT logs? +
- Yes. A wildcard certificate for *.example.com appears in CT logs and reveals that the organisation uses services under that subdomain pattern. However, the wildcard entry does not list individual subdomain names - only the wildcard pattern itself.
Get SurfaceLoop security briefings
No spam, just findings that matter. Fortnightly.