Subdomain Finder

Discover names recorded in public certificates

This subdomain finder searches certificate transparency data through crt.sh. It is a passive discovery aid: instead of guessing names or connecting to each host, it asks a public database which DNS names have appeared in logged TLS certificates for the domain. That makes it useful for maintaining an asset inventory, reviewing certificate issuance, finding forgotten staging names, and investigating why a hostname appears in public records.

It is not a DNS brute forcer, web crawler, zone transfer client, or proof that every listed name is currently active. Certificate logs preserve historical evidence. A certificate may have expired, its service may have been retired, or a DNS record may never have existed publicly even though the name was included in a certificate.

From domain entry to sorted list

Enter a registrable domain such as example.com. The component lowercases the input, removes one leading http:// or https://, and discards everything from the first slash onward. Therefore https://example.com/account becomes example.com. It does not use a Public Suffix List to determine the organizational domain, so choose the intended base yourself.

After 400 ms without another edit, the page sends this style of browser request:

https://crt.sh/?q=%25.example.com&output=json

%25 represents the wildcard query %.example.com. crt.sh returns matching certificate records as JSON. For every name_value, the component splits newline-separated names, converts them to lowercase, and keeps values equal to the entered domain or ending in . plus that domain. A JavaScript Set removes duplicate strings, then the tool sorts the final list alphabetically.

Select Search to run the same request immediately. Copy all writes the visible list to the clipboard with one name per line. The count describes unique strings after local filtering, not unique certificates, servers, IP addresses, or live applications.

Read the output as leads, not findings

Imagine a search for example.com returns:

api.example.com
example.com
old-admin.example.com
*.example.com
www.example.com

api.example.com means that exact DNS identifier appeared in at least one matching certificate record. It does not establish whether it currently resolves, which port it uses, or whether it is owned by the same team today. old-admin.example.com may be especially valuable for an internal inventory review, but the name alone is not evidence of a vulnerability.

The literal *.example.com is a wildcard certificate name. It represents a certificate valid for one label below example.com, subject to TLS matching rules; it does not enumerate all possible hosts. The component retains wildcard strings as returned. A wildcard does not cover example.com itself or a deeper name such as a.b.example.com unless other Subject Alternative Names are present.

The apex example.com can appear because the local filter explicitly accepts the base domain as well as descendants. The crt.sh query can return certificates containing both wildcard and base names, and name_value fields can aggregate multiple SAN entries.

A defensive certificate review workflow

Start by exporting the list with Copy all into an approved inventory worksheet. Mark known production, staging, vendor, and retired names. Compare the remainder against authoritative DNS, cloud accounts, load balancers, certificate-manager records, and configuration repositories. Ownership should be established through internal records, not inferred solely from naming.

For a name you administer, perform a DNS lookup for A, AAAA, and CNAME. A current answer indicates publication but not necessarily a live service. Review CAA records at relevant labels to understand which certificate authorities are authorized to issue. Check certificate-monitoring alerts for unexpected issuers and issuance times.

If legacy-vpn.example.com is unfamiliar, do not immediately browse it from an unmanaged device. Ask the domain or security owner, inspect approved DNS and certificate records, and follow incident procedures if issuance appears unauthorized. A safe response may include revoking a certificate, correcting ACME account controls, removing stale DNS, and documenting the asset.

Repeat searches periodically because certificate transparency is append-only and new issuance changes the observable inventory. For robust monitoring, use a dedicated CT feed or provider with alerting, timestamps, issuer metadata, and domain-validation controls; this UI intentionally returns names only.

What certificate transparency contributes

Publicly trusted certificate authorities generally submit certificates or precertificates to append-only Certificate Transparency logs. Signed Certificate Timestamps let clients and auditors verify inclusion. The ecosystem makes misissuance and unexpected certificates more visible, but logs are not designed as a canonical subdomain directory.

A certificate’s Subject Alternative Name extension can contain DNS names needed by a service. Those values become observable through CT. Internal hostnames should not be placed in publicly trusted certificates if their disclosure is unacceptable. Private certificate authorities and certificates not submitted to public logs will not appear, so absence from this subdomain lookup says nothing about a private PKI estate.

crt.sh indexes certificate data and provides the JSON endpoint used here. It is an external service with its own availability and rate behavior, not a DevsTool database. Results can be delayed, duplicated at the certificate-record level, or too large for broad domains. The component does not paginate or expose certificate IDs, issuers, validity dates, serial numbers, fingerprints, log names, or SAN-to-certificate relationships.

Scope and authorization boundaries

Reading public CT data is passive compared with actively scanning hosts, but responsible use still matters. Search domains you own, administer, are contracted to assess, or have a legitimate defensive reason to review. Do not turn discovered names into targets for login attempts, vulnerability probes, port scans, or data access without explicit authorization.

A bug-bounty program may define exact in-scope domains and permitted testing methods. A name ending in an in-scope suffix can still belong to a third-party tenant, vendor, or excluded environment. Read program rules and resolve ownership before testing. Public availability of a hostname or certificate does not grant consent.

When documenting an unexpected name, minimize exposure. Share it through the owner’s approved security channel rather than a public post, and avoid claiming compromise based only on CT history. Certificate issuance can predate an acquisition, migration, or decommissioning event.

Network and privacy facts

The search is not local-only. Your browser sends the entered domain to crt.sh over HTTPS. crt.sh can observe the query, your public IP address, timing, and ordinary request metadata. DevsTool does not proxy the call. Search terms and result strings are held in page state; Copy all invokes the browser Clipboard API.

Because the request is cross-origin, browser CORS policy must permit the response. Extensions, DNS filters, enterprise policy, Content Security Policy, network interception, rate limits, or crt.sh availability can block it. HTTPS protects the query in transit, but it is not confidential from the destination service.

The tool does not contact discovered subdomains. It performs one database query per settled input, not one request per result. DNS operators and listed hosts should not see traffic from this page merely because their name appeared in the list.

Why searches fail or appear incomplete

Certificate log query failed (429) typically indicates HTTP rate limiting. Pause before retrying rather than repeatedly pressing Search. A 5xx response points to a service-side issue. A generic inability to query can reflect CORS, connectivity, filtering, malformed JSON, or browser restrictions.

An empty result can be legitimate when no matching certificate is indexed. It can also occur because the entered label is too narrow, certificates use different names, services rely on a wildcard higher in the hierarchy, or private PKI is involved. Search the correct organizational domain and compare with your certificate manager.

Large organizations can produce huge JSON responses. The UI has no pagination, cancellation controller, result limit, or date filter. A broad search may be slow or fail due to service and browser resource constraints. Use crt.sh’s full interface or a purpose-built CT client for extensive analysis.

Internationalized domain names deserve care. The component lowercases input but does not explicitly convert Unicode labels to Punycode. Use the canonical ASCII xn-- form when necessary and validate the domain before interpreting absence.

Names in the output can include wildcard prefixes, and the tool does not validate every returned line as a syntactically valid hostname. Treat copied data as untrusted text when importing it into scripts. Do not feed the entire list automatically into active tools without sanitization, ownership verification, and permission.

Questions unique to CT-based subdomain search

Does a result mean the certificate is still valid?

No. The interface omits not-before, not-after, revocation, and issuance data. CT history commonly includes expired and replaced certificates.

Why are there no IP addresses?

Certificates bind identities to public keys; CT records are not DNS responses. Resolve an authorized name separately to learn its current address.

Can this find subdomains that never used TLS?

Usually not. A name must have appeared in logged certificate material. DNS-only, HTTP-only, private-CA, and undisclosed internal names can be absent.

Does the wildcard result expand automatically?

No. *.example.com remains one literal entry. CT cannot derive all labels covered by a wildcard certificate.

Why does the same domain appear only once despite many certificates?

The local Set intentionally deduplicates identical name strings. This page is a name finder, not a certificate-counting report.

Is this a complete asset inventory?

No. Combine CT with authoritative DNS data, cloud inventories, registrars, certificate managers, source configuration, and approved network discovery. Each source sees a different portion of the estate.