crt.sh Alternative — Free Subdomain Finder with IPs & Ports

What is crt.sh?

crt.sh is a free Certificate Transparency log search service operated by Sectigo (formerly Comodo CA). Certificate Transparency, defined in RFC 6962, requires every publicly trusted Certificate Authority to log every certificate it issues to one or more public append-only logs. The original goal was security accountability — make it impossible for a CA to misissue a cert without leaving a public trace. A side effect, and the reason crt.sh became essential to security practitioners, is that those logs contain the full Subject Alternative Name list for every cert, which often includes internal hostnames, dev subdomains, staging environments, and entire wildcard patterns that organizations never intended to publish.

crt.sh indexes those logs continuously across every major CA — Let’s Encrypt, DigiCert, Sectigo, Google Trust Services, Cloudflare, Amazon, GlobalSign, and many more. The web UI accepts a search query like %.example.com (where % is the SQL wildcard) and returns every certificate whose SAN or CN matches. The same data is available as JSON via a query parameter, and Sectigo also exposes the underlying PostgreSQL database directly to guest users for advanced queries. That direct database access is rare among free security tools and a significant part of why crt.sh is so respected by power users.

The trade-offs are real. crt.sh returns raw certificate data — one row per logged cert, often with duplicates (the same cert appears in multiple logs), wildcard entries that need cleaning (*.example.com should be normalized for subdomain lists), and no resolution data whatsoever. You get the hostname that appeared in the cert, the issuer, validity dates, and a serial number. You do not get the current IP address, you do not know if the host is even alive today, and you certainly do not know what ports are open. The data is also limited to subdomains that received a publicly logged certificate at some point — hosts behind private CAs, self-signed certs, or single wildcard certs that cover the whole zone are invisible to CT logs by definition.

# JSON query — the bug bounty starter recipe
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | sort -u

# Postgres direct query (free public access)
psql -h crt.sh -p 5432 -U guest certwatch -c \
  "SELECT DISTINCT name_value FROM certificate_and_identities \
   WHERE plainto_tsquery('certwatch', 'example.com') @@ identities(certificate) \
   ORDER BY name_value;"

# Wildcard cert hunting — find broad SANs that hint at internal naming
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[] | select(.name_value | contains("*")) | .name_value' \
  | sort -u

That first one-liner — curl, jq, sed, sort — is in virtually every bug bounty recon repository on GitHub. It is the canonical way to extract subdomains from crt.sh, and it works well. It also produces a flat list of hostnames with no enrichment, which is fine if you are about to feed it into httpx or dnsx, but inconvenient if you just want to understand a target.

Feature comparison

Where crt.sh excels

• Authoritative CT-log coverage. crt.sh ingests directly from the public CT logs operated by Google, Cloudflare, Let’s Encrypt, DigiCert, and others. When a new certificate is issued and logged, crt.sh sees it. There is no intermediate vendor and no sampling — for CT-derived data, this is as close to the source as a free tool gets.
• Free PostgreSQL access for power users. The ability to run arbitrary SQL against the full CT database is unusual and powerful. You can write queries that answer questions no UI exposes: certs issued in the last 24 hours for a specific organization, wildcard patterns across a portfolio, mis-issued certs flagged by name mismatch. For researchers and CA auditors this is irreplaceable.
• Internal hostname discovery via accidental certs. Organizations routinely issue publicly trusted certificates for hostnames they never intended to expose externally — dev environments, internal admin panels, staging APIs. Once those names are logged in CT, they are permanently public. crt.sh surfaces them cleanly, and many of the most impactful bug bounty findings start here.
• Open data, no API quota walls. Unlike commercial DNS intel platforms, crt.sh does not throttle or charge for queries. The JSON endpoint and the database are both free, and you can hit them as often as you need within reasonable rate limits.
• Use cases beyond subdomains. crt.sh is the standard tool for CA monitoring, certificate issuance auditing, detecting unauthorized issuance against your organization, and verifying that a CT log presence is consistent with your internal certificate inventory. None of that is a subdomain-finder use case, and SubDomainsFinder does not try to compete on it.

Where SubDomainsFinder has the edge

• Broader coverage than CT alone. Certificate Transparency misses anything that never received a public cert. SubDomainsFinder aggregates CT data with passive DNS, public internet scan data, and other open sources, which fills in subdomains that crt.sh has no way to know about. The CT data is in there — but it is one of many sources, not the only one.
• IPs, ports, ASN, and CDN/WAF detection in one view. crt.sh tells you a hostname appeared in a certificate. SubDomainsFinder tells you where that hostname resolves today, what ports are publicly responding, which ASN owns the IP, and whether the host sits behind a CDN or WAF. That difference compresses what used to be a multi-tool workflow into a single page load.
• Polished UI with sortable, filterable results. The crt.sh interface is functional but unrepentantly raw — a wide table of cert metadata that experienced users navigate fluently but newcomers find disorienting. SubDomainsFinder uses a modern interface designed around the question “what subdomains exist and where are they?” rather than “what certs were issued?”
• Deduplicated and cleaned output. crt.sh returns one row per logged certificate, so the same hostname appears many times across renewals, multiple logs, and wildcard variations. SubDomainsFinder normalizes wildcards, deduplicates names, and presents a clean canonical list. This is the post-processing step that the canonical bug-bounty one-liner exists to perform — and we do it for you.
• More reliable on large domains. crt.sh queries against domains like google.com, microsoft.com, or amazonaws.com can return millions of cert entries and often time out at the gateway. Because SubDomainsFinder pre-processes and caches CT data, high-volume domains return results without the timeout dance.

Which tool is right for you?

Also compare