Subdomain finder
Discover a domain's subdomains from public certificate-transparency logs (crt.sh).
Run a full graded audit for the whole site.
Discover a domain's subdomains from public certificate-transparency logs (crt.sh).
A subdomain finder discovers all subdomains registered under a domain by analyzing public Certificate Transparency logs. Enter a domain name and instantly see every subdomain that was issued an SSL/TLS certificate, revealing your organization's full infrastructure footprint without active scanning.
A subdomain is a prefix added to a domain name that functions as a separate address within the same root domain. In the example subdomains.example.com, "subdomains" is the subdomain, "example.com" is the primary domain, and ".com" is the top-level domain (TLD). A domain can have unlimited subdomains, each serving different purposes or hosting different services.
Subdomains are commonly used to organize content, separate services, or isolate environments. A single organization might use www.example.com for the public website, api.example.com for API requests, staging.example.com for testing, and mail.example.com for email services. Each subdomain can have its own DNS records, SSL/TLS certificates, and IP addresses, making them ideal for distributing services across infrastructure.
Because subdomains are created automatically whenever a new SSL/TLS certificate is issued, they leave a public record in Certificate Transparency logs. This is how a subdomain finder discovers them without needing to access private DNS records or attempting active enumeration.
This tool uses a passive discovery method that queries publicly available certificate data. Unlike active scanning tools that probe DNS servers or brute-force common subdomain names, this approach is fast, requires no technical setup, and leaves no trace on target systems.
Certificate Transparency logs are mandatory public records maintained by certificate authorities like Let's Encrypt, DigiCert, and others. Every SSL/TLS certificate issued after 2013 must be submitted to these logs to be trusted by browsers. Because of this requirement, the logs contain a comprehensive historical record of every subdomain that was ever secured with a certificate.
A subdomain enumeration reveals the complete infrastructure landscape of an organization. It uncovers not just the public-facing website, but every system that has been assigned a unique hostname: API endpoints, staging environments, development servers, admin panels, mail systems, content delivery networks, and internal tools.
Each discovered subdomain represents a potential entry point into your infrastructure. Understanding this full surface is essential for organizations that want to maintain complete visibility over their assets and reduce the risk of unpatched or misconfigured systems being exploited.
Subdomain discovery serves multiple legitimate purposes across security, operations, and marketing functions.
Certificate Transparency (CT) is a framework requiring all SSL/TLS certificates to be logged in publicly auditable logs. This requirement was introduced by Google in 2013 to prevent unauthorized certificate issuance and has become a core security standard. Every major certificate authority — including Let's Encrypt, Comodo, DigiCert, Sectigo, and others — publishes certificates to CT logs.
When a certificate authority issues a certificate for example.com or api.example.com, that certificate is logged within hours. The log entry includes the hostname (subject) and all alternative names (SANs) the certificate covers. This means any subdomain that has been issued an HTTPS certificate will appear in these logs indefinitely — even if the subdomain is later taken offline or the certificate expires.
This creates a permanent historical record. A subdomain that was active five years ago and is now abandoned will still be discoverable through CT logs. For organizations, this means the tool can find both active systems and legacy infrastructure that may no longer be monitored but still exists on the network.
Browser vendors including Chrome, Firefox, and Safari now require CT compliance for certificates to be trusted. This nearly universal adoption means CT logs contain certificates from virtually all organizations that use HTTPS — making them an exceptionally complete data source for subdomain discovery.
Certificate Transparency discovery excels in specific scenarios and has predictable limitations.
| Scenario | What You'll Find | What You Won't Find |
|---|---|---|
| Active services with HTTPS | All subdomains issued valid SSL/TLS certificates | Services running only on HTTP (unsecured) |
| Current infrastructure | Subdomains in active use today | Subdomains deprovisioned and removed from DNS |
| API endpoints and services | api, webhook, cdn, mail subdomains | Hardcoded IP addresses used instead of hostnames |
| Multi-region deployment | All geographic subdomains (eu-, us-, sg-) | Internal IP-based deployments with no DNS |
| Acquired companies | Legacy subdomains from merged organizations | Rebranded or consolidated infrastructure |
| Historical assets | Subdomains that existed years ago | Never-named services or undocumented systems |
The tool is most useful for organizations that follow standard practices: assigning hostnames to services, using HTTPS, and maintaining certificates. It works less well against infrastructure that uses IP addresses directly, internal-only services, or systems protected behind corporate VPNs where no public certificate is issued.
Certificate-based discovery is highly accurate for the subdomains it finds. If a subdomain appears in the results, a certificate was genuinely issued for it. However, "complete" coverage depends on how the organization manages its infrastructure.
Potential gaps include: subdomains that never had HTTPS (rare now, since browsers flag HTTP as insecure), services using only internal hostnames with self-signed certificates, infrastructure that existed before 2013 when CT logs weren't mandatory, or systems deployed without assigning them hostnames. Roughly 5-15% of internet subdomains may lack CT records, though for most organizations the figure is closer to 0-5%.
For maximum coverage, many security professionals combine certificate-based discovery with other methods. Reverse DNS lookups can find subdomains without certificates. Subdomain brute-forcing can discover common names that may not be in CT logs. Search engines may have indexed subdomains that are now offline. Using multiple methods together provides comprehensive asset discovery.
The key strength of certificate-based discovery is speed and passivity. A complete subdomain enumeration returns in under a second, requires no special tools or configuration, and leaves no trace on the target network. For the infrastructure segment it covers — anything with an HTTPS certificate — it is both complete and instantaneous.
A domain is the main name (example.com). A subdomain is a prefix that extends it (api.example.com, mail.example.com). A domain can have unlimited subdomains. The key difference is that each subdomain can have its own DNS records, IP address, and SSL certificate, while the primary domain cannot.
It finds all subdomains that have been issued SSL/TLS certificates and logged in Certificate Transparency logs. This covers the vast majority of production infrastructure, particularly anything exposed to the internet or accessed over HTTPS. Subdomains running only on HTTP, internal-only services, or those that predate CT logs (before 2013) may not appear. For complete coverage, combine this with DNS enumeration or brute-force methods.
Yes. Subdomain discovery is a standard reconnaissance phase of authorized security testing. This tool provides a complete, passive enumeration of an organization's internet-facing infrastructure with no active probing. It helps define the scope of what you're authorized to test and identifies systems you may not have been aware of. Always ensure you have explicit authorization before testing any systems.
No. This tool only enumerates subdomains — it lists them. It does not scan them for vulnerabilities, check their status, test for misconfigurations, or attempt to access them. It is purely a discovery tool that tells you what subdomains exist. To assess security, you would use it as the first step in a larger security workflow.
Certificate Transparency logs are updated in real-time as new certificates are issued. When you run a search, the tool queries current CT log data. Historical data — certificates issued in the past — is permanent and searchable. Any subdomain that had a certificate issued remains discoverable indefinitely.
Forgotten or abandoned subdomains are a security risk. They may still have DNS records pointing to inactive services, they may hold outdated or unpatched software, and they may be vulnerable to subdomain takeover attacks where an attacker claims the abandoned service and uses it to impersonate your organization. Regular subdomain discovery helps you identify and remediate these assets.
Yes — the data comes from public Certificate Transparency logs that anyone can query. This is a limitation of the CT system itself, not this tool. However, this transparency is intentional: it prevents certificate authorities from secretly issuing unauthorized certificates for your domain. If you want to keep a subdomain's existence private, you must not issue it an HTTPS certificate.