Subdomain Finder — Subdomain Enumeration via Certificate Transparency (crt.sh) (No API / No login)

Discover certificate-published hostnames for a domain through public Certificate Transparency (CT) data — primarily crt.sh, with keyless Cert Spotter fallback when crt.sh is unavailable. This passive subdomain enumeration never touches the target's infrastructure. Depending on CT coverage, one root domain can return hundreds to thousands of unique hostnames, each as a clean row with the subdomain, root domain, ready-to-use url, a wildcard flag and certificate firstSeen / lastSeen dates. Pure HTTP, no browser, no API key, no login.

🏆 Why this subdomain finder?

8 fields per hostname · passive HTTP + JSON over public CT services (no browser, no scanning) · direct-first with optional proxy fallback · export to JSON / CSV / Excel. A structured CT-enumeration tool for security recon, bug bounty, OSINT and asset inventory. Results reflect names visible to the upstream CT indexes, not DNS brute-force or a guarantee of every existing subdomain.

---

✨ What this Actor does / Key features

• 🛰️ Passive subdomain enumeration — pulls hostnames from Certificate Transparency logs; it never scans, probes or brute-forces the target, so there is zero direct contact with the target's infrastructure.
• 📈 High volume — depending on certificate coverage, a root domain can yield hundreds to thousands of unique hostnames in one run, including forgotten shadow, staging and dev hosts.
• 🗂️ Bulk multi-domain — pass a whole list of root domains in domains and enumerate them all in a single run, one clean row per unique subdomain.
• 🔀 Multi-source CT coverage — for each root domain the Actor merges %.<domain> and <domain> crt.sh queries; when they return no usable entries it falls back to Cert Spotter's active certificate issuances.
• 🌿 Wildcard handling — the leading *. on wildcard certs is always stripped and deduped; optionally keep wildcard-only names with includeWildcards, flagged as isWildcard: true.
• ✅ Optional live filter — enable onlyResolvable to run a DNS-over-HTTPS A-record lookup on every subdomain and keep only the ones that currently resolve.
• 🗓️ First / last seen dates — certificate validity dates (not_before / not_after) come through as firstSeen and lastSeen, perfect for spotting fresh or stale assets.
• 🧹 Clean de-dup — every hostname is lowercased, wildcard-stripped and merged into a set, keeping the earliest firstSeen and latest lastSeen per name.
• 🛡️ Explicit upstream health handling — bounded direct/proxy retries and a second CT provider distinguish a legitimate empty result from rate limits or outages. If every CT source fails, the run fails clearly instead of claiming a successful zero-row enumeration.
• 🔓 No API key, no browser — crt.sh is an open endpoint; pure HTTP means fast, low-cost runs with export to JSON, CSV or Excel or via the Apify API.

🚀 Quick start (3 steps)

1. Configure — enter one or more Root Domains (e.g. apify.com) with no http:// and no paths. Optionally toggle wildcard/resolvable filters or cap results per domain.
2. Run — click Start. The Actor queries public CT sources, parses and deduplicates the certificate hostnames they return, and streams rows into your dataset.
3. Get your data — open the Output tab and export to JSON, CSV, Excel or XML, or pull it via the Apify API.

📥 Input

domains is optional. Empty input enumerates the well-known default apify.com; provide your own root domains for real workloads.

Example — enumerate a single domain (defaults)

{
  "domains": ["apify.com"],
  "includeWildcards": false,
  "onlyResolvable": false,
  "maxResults": 0,
  "proxyConfiguration": { "useApifyProxy": false }
}

Example — bulk recon across several targets

{
  "domains": ["apify.com", "google.com", "cloudflare.com"],
  "includeWildcards": true,
  "maxResults": 5000,
  "proxyConfiguration": { "useApifyProxy": false }
}

Example — only currently-live subdomains

{
  "domains": ["example.com"],
  "onlyResolvable": true,
  "proxyConfiguration": { "useApifyProxy": false }
}

Field	Type	Description
domains	array	Optional root domains to enumerate (e.g. apify.com, google.com). Empty = apify.com. Do not include http:// or paths.
includeWildcards	boolean	Keep names that only ever appeared as a wildcard cert (*.x), flagged isWildcard: true. The leading *. is stripped regardless. Default false.
onlyResolvable	boolean	If true, each subdomain is checked with a DNS-over-HTTPS A-record lookup and only currently-live hosts are kept. Much slower — off by default.
maxResults	integer	Maximum unique subdomains to return per root domain. 0 = no limit.
proxyConfiguration	object	Optional fallback proxy for crt.sh retries. Direct is the default because shared proxy pools are often rate-limited by crt.sh.

How to enter a domain: use the bare registrable domain only — apify.com, not https://apify.com/ or www.apify.com/blog. Sub-subdomains found under it (e.g. dev.api.apify.com) are still returned automatically.

Additional input fields

These optional fields are also available in the input form and API:

Field	Type	Default	Description
sortBy	string	"name"	How to order the discovered subdomains.

📤 Output

One row per unique subdomain — 8 fields, exportable to JSON, CSV, Excel or XML. Here is a sample record:

{
  "subdomain": "affiliate.apify.com",
  "domain": "apify.com",
  "url": "https://affiliate.apify.com",
  "isWildcard": false,
  "resolvable": null,
  "firstSeen": "2025-06-03T07:47:43",
  "lastSeen": "2026-09-07T01:14:59",
  "discoveredAt": "2026-07-06T12:00:00.000Z"
}

💡 Use cases

• Security recon & penetration testing — map the certificate-published portion of an organization's external attack surface before an authorized test, without probing the target.
• Bug bounty & OSINT — enumerate in-scope assets for a target using passive reconnaissance with zero direct contact, then feed the list into your fuzzing pipeline.
• Attack-surface management — discover forgotten, shadow, staging or dev subdomains your team may have lost track of.
• Asset discovery & inventory — build and enrich a CT-derived subdomain inventory for any domain you own or monitor.
• SEO & site migration — find certificate-published subdomains that may host indexable content before or after a redesign or migration.
• Brand & threat monitoring — track which subdomains appear over time via firstSeen and catch new or unexpected hostnames.

👥 Who uses it

Penetration testers & red teams · bug bounty hunters & OSINT researchers · attack-surface & security operations teams · SRE / infrastructure inventory owners · SEO specialists & site-migration engineers · brand-protection & threat-intel analysts.

💰 Pricing

This Actor runs on a simple pay-per-result model — you pay for the subdomains you extract, with no separate Apify platform fees to calculate. Try it on the free tier first, then scale up. See the Pricing tab on this page for the current rate.

❓ Frequently Asked Questions

Is it legal to enumerate subdomains via Certificate Transparency? The Actor only reads hostnames that organizations already published to public Certificate Transparency logs — no target infrastructure is contacted. You are responsible for using the data in compliance with crt.sh's terms and applicable laws, and for only enumerating domains you own or are authorized to assess.

Does crt.sh have a public API? Is this a CT-log / crt.sh API alternative? crt.sh exposes a lightweight JSON endpoint but no stability guarantee and can rate-limit or time out under load. This Actor wraps it with bounded retries, parsing and de-duplication, then uses Cert Spotter active issuances as a keyless fallback when crt.sh yields no usable entries. If all CT services fail, the run fails explicitly; it does not disguise an outage as zero discovered names.

Can I find subdomains without an API key or login? Yes. crt.sh is an open Certificate Transparency endpoint, so this Actor needs no API key, no login and no third-party credentials — only an Apify account. It pulls publicly published hostnames over direct HTTP.

How do I export subdomains to CSV or JSON? Every result is one row in an Apify dataset, so you can export the discovered hostname list to CSV, JSON, Excel or XML from the Apify console or via the Apify API — ready to drop into a spreadsheet or recon pipeline.

How much data can I get? It depends on the target and upstream CT coverage. Small sites may return a handful of names; large organizations can return hundreds or thousands. maxResults controls the per-domain row cap, while the Actor's safety window and provider availability bound very large runs.

How is this different from a DNS brute-force tool?

A brute-force tool guesses subdomain names against a wordlist and actively queries the target's DNS. This Actor is passive: it reads hostnames organizations already published to public CT logs, so it never touches the target's infrastructure — and it often surfaces names no wordlist would guess. For complete coverage, pair passive CT enumeration with an active tool.

Does it find sub-subdomains and wildcard domains?

Yes. Any depth of hostname that appears in a certificate (e.g. dev.api.example.com) is returned. Wildcard certs (*.example.com) always have the leading *. stripped; enable Include Wildcard Entries (includeWildcards) to also keep names that only ever appeared as a wildcard, flagged with isWildcard: true.

Why are some subdomains not live?

CT logs are historical — a certificate may have been issued for a host that no longer resolves. Enable Only Resolvable (onlyResolvable) to run a DNS-over-HTTPS A-record check and keep only subdomains that currently resolve, reported in the resolvable field.

How do I enumerate subdomains for a bug bounty target?

Enter the in-scope root domain and the Actor pulls certificate-published hostnames from public CT indexes, giving you a passive asset list without touching the target. Then feed the url column into a status checker or tech-stack detector to prioritize live hosts.

🔗 More security & recon scrapers by logiover

Building a full recon and attack-surface pipeline? Pair Subdomain Finder with the rest of the logiover security & website-intelligence suite:

Tool	What it does
Certificate Transparency Monitor	Track newly issued TLS certificates for a domain over time
Bulk DNS Records Lookup	Resolve A, AAAA, MX, TXT, NS and more for any list of domains
Bulk WHOIS / RDAP Lookup	Pull WHOIS/RDAP registration data for domains in bulk
Bulk SSL Certificate Checker	Inspect SSL/TLS certs, issuers and expiry for many hosts
Bulk HTTP Security Headers	Audit HSTS, CSP and other security headers across URLs
Bulk URL Status Checker	Check HTTP status codes and redirects for any list of URLs
Website Tech Stack Detector	Detect frameworks, CMS, analytics and servers a site runs on
Broken Link Checker	Crawl a site and flag every dead internal and external link
Website Link Graph Crawler	Map the internal link graph and structure of a website
Sitemap to URL Crawler	Expand sitemaps into a full, deduplicated list of page URLs
Wayback Machine URL Extractor	Pull historical URLs for a domain from the Internet Archive
Website SEO Audit Crawler	Crawl a site and surface on-page SEO and technical issues

👉 Browse all logiover scrapers on Apify Store — 180+ actors across real estate, jobs, crypto, social media & B2B data.

⏰ Scheduling & integration

Schedule this Actor on Apify to re-enumerate your domains daily or weekly and catch new subdomains as certificates are issued. Export results to JSON, CSV or Excel, sync to Google Sheets, or push to your database, BI tools and webhooks through the Apify API. Connect it to Make, n8n or Zapier to feed fresh subdomain inventories straight into your recon or asset-management workflows.

⭐ Support & feedback

Found a bug or need an extra field? Open an issue on the Issues tab — response is usually fast. If this Actor saves you time, a ★★★★★ review on the Store page genuinely helps and is hugely appreciated. 🙏

⚖️ Legal

This Actor extracts only publicly available Certificate Transparency data and is intended for legitimate security research, asset inventory and authorized reconnaissance. You are responsible for complying with crt.sh's terms of service, applicable local laws, and for only enumerating domains you own or are authorized to assess.

---

This Actor is an independent tool. It is not affiliated with, endorsed by, or sponsored by Subdomain; Subdomain and all other trademarks mentioned here are the property of their respective owners.

Subdomain scraping — frequently asked questions

Do I need a Subdomain API key, account or login?

No. This Actor reads publicly available pages and feeds, so there is nothing to register for and no credentials to manage.

How do I export Subdomain data to CSV, Excel, JSON or Google Sheets?

Open the Storage tab after a run and pick the format you want — CSV, Excel, JSON, XML or an HTML table. For Google Sheets, Airtable or a database, use the dataset URL or the Apify API so the sheet refreshes itself on every run.

Can I schedule this Subdomain scraper to run daily or hourly?

Yes. Use the Schedules tab and pick a cadence. Daily is enough for most tracking work; pick hourly only if the rows you care about really do change that fast.

How many rows can I get, and what does it cost?

See the volume section above for a measured figure. Billing is per result, so you pay for the rows you actually receive and a run that finds nothing costs nothing.

Is scraping Subdomain legal?

This Actor collects only information that Subdomain publishes publicly. It does not log in, does not defeat access controls and does not touch private data. You remain responsible for how you use the output, including under GDPR and similar rules where personal data is involved.

What happens if Subdomain blocks the run or changes its layout?

A refused exit IP is swapped for a fresh one within a quarter of a second and retried, and rate limiting is waited out rather than fought. If nothing gets through, the run fails with the reason instead of reporting success with zero rows — so an empty result always means "no matches", never "the source would not answer".

Can I use this with an AI agent, LangChain or an MCP client?

Yes. The Actor is callable over the Apify API and through Apify's MCP server, so an agent can run it and read the dataset back as a tool call.

📝 Changelog

2026-11-01

• Monthly health check (2026-11-01): a live run on the current build completed successfully and returned data. Input options, output fields and pricing are unchanged.
• README refreshed: independence disclaimer added; documented 1 additional input field.

2026-10-15

• Every request now has a hard time limit, so a proxy connection that stalls can no longer hold up the run or push it past its timeout.
• A run that reaches its maximum cost per run now stops cleanly with its results saved and a status message, instead of ending as aborted.
• A proxy group your account cannot use no longer stops the run at start-up; it falls back to the default Apify Proxy.
• Runs with a short timeout (API and AI-agent calls) now finish inside it with what they collected, instead of being cut off.
• Memory is managed within the run's own limit, which removes a rare out-of-memory crash on large pages.

2026-09-23

• Fleet-wide quality audit. Verified end to end against live data and re-checked the input schema, the output columns and the run configuration.
• Output verified on a live run: 8 columns returned, 87.5% of cells populated.
• Run reliability reviewed: 100.0% of public runs succeeded in the last 30 days.
• Input schema, output schema and pricing configuration reviewed.
• Noted that 1 column(s) came back empty in this sample (resolvable); these are under review.

2026-09-01

• Fleet-wide health check. Verified against this Actor's real run history: 30-day success rate, output row counts, per-field fill rates, and peak memory against the configured memory limit.
• Reviewed for the failure patterns that have cost this fleet runs — unguarded proxy setup, retry loops that can outlast the run's own time budget, and full-page HTML parsing that can exhaust a small container.
• No change to input, output fields or scraping logic.

2026-08-11

• Maintenance release: refreshed the build and dependencies.
• Re-verified live execution, non-empty structured output and dataset field/type integrity.
• Reviewed reliability (retries, pagination) and output quality as part of a full-fleet QA pass.

2026-08-01

• Completed the August 2026 full health check: verified empty/programmatic default, Console UI default, and two source-informed alternative inputs on Apify.
• Confirmed successful live execution, non-empty structured output, dataset-field/type integrity, and logical sample quality within the 5-minute quality window.
• Fixed the run Output link from {{links.apiDefaultDatasetUrl}} to {{links.apiDefaultDatasetUrl}}/items so the results table opens the dataset items endpoint.
• Changed crt.sh access to direct-first bounded retries, made proxy use optional, and added paginated Cert Spotter active-issuance fallback.
• Made all-CT-source failure, invalid domains, and total DNS-over-HTTPS failure explicit instead of returning misleading successful empty data; maxResults now caps final post-DNS-filter rows.
• Corrected absolute coverage/proxy claims while retaining the existing eight-field dataset contract.

2026-08-01 — Health-check remediation

• August 2026 monthly health-check remediation is in progress; this build contains fixes verified from empty/default, Console-default, targeted live probes, or field-level semantic review.
• Fixed the run Output link from {{links.apiDefaultDatasetUrl}} to {{links.apiDefaultDatasetUrl}}/items so the results table opens the dataset items endpoint.
• Changed crt.sh access to direct-first bounded retries, made proxy use optional, and added paginated Cert Spotter active-issuance fallback.
• Made all-CT-source failure, invalid domains, and total DNS-over-HTTPS failure explicit instead of returning misleading successful empty data; maxResults now caps final post-DNS-filter rows.
• Corrected absolute coverage/proxy claims while retaining the existing eight-field dataset contract.
• The final four-input matrix verdict will be appended after post-build cloud revalidation.

2026-08-01

• 🩺 Monthly health check: proved the UI-default empty dataset was a crt.sh 429 exhaustion hidden behind SUCCEEDED; requests are now direct-first, Apify Proxy is optional fallback, and Cert Spotter supplies active CT issuances when crt.sh has no usable response.
• ❌ Runs now fail explicitly when every CT source fails, while genuine upstream-success/zero-match cases remain valid empty results.
• 🎯 Invalid domains and total DNS-over-HTTPS outages now fail clearly instead of silently producing unrelated defaults or empty filtered data.
• 🧮 maxResults is enforced on final rows after the optional DNS filter, not on candidates that are later discarded.
• 📚 Corrected absolute coverage and proxy claims and documented the source/runtime limits.

2026-07-06

• ✨ README overhaul: richer output sample, ready-to-run example scenarios, cross-suite links, and clearer quick-start.

2026-07-01

• Maintenance pass: re-verified end-to-end on live data and confirmed successful runs within the 5-minute quality window on the default input.
• Sharpened Store metadata (SEO title & description) and expanded the FAQ with high-intent, long-tail questions for easier discovery in Google and Apify Store search.
• Added ready-to-run example tasks that cover common real-world use cases.

2026-06-15

• Initial release — subdomain discovery via Certificate Transparency logs, CSV/JSON export, no API key.

---

*Maintained: last verified 2026-11-01 — checked end-to-end against live run history (reliability, output fields and types, and time/memory budgets).