What is crt.sh and how do I use it?

crt.sh is a free search interface over Certificate Transparency logs, operated by the certificate authority Sectigo. You type a domain and it lists every logged certificate that names it, with issuer, dates and all the hostnames on the certificate. The percent sign is a wildcard: %.example.com returns every subdomain that ever had a public certificate, and %example% returns anything containing the brand — useful for spotting lookalike domains. Adding &output=json to the URL returns machine-readable results for scripts. It is a courtesy service that can be slow or return errors under load, so automated use should include retries and a fallback such as Cert Spotter's API.

Can I remove my subdomains from Certificate Transparency logs?

No. CT logs are append-only by design and browsers require certificates to be logged, so there is no removal mechanism, and a certificate that isn't logged won't be trusted. What you can control is what gets logged in future: serve internal or sensitive hostnames under a wildcard certificate (the log then shows only *.example.com), use an internal certificate authority for hosts that are never public, or put internal services under a separate domain. Bear in mind that history remains — names logged in the past stay searchable — so the practical response is to treat CT as a public inventory and make sure every name in it is either intentionally public or retired.

How do attackers use Certificate Transparency logs?

As the first step of reconnaissance. A single CT query returns every hostname that ever had HTTPS under a target domain, which is a near-complete map of the organisation's web properties including staging, development and administrative hosts that were never meant to be found. Attackers also watch CT feeds in real time: a newly issued certificate for a hostname often appears minutes before the service behind it is fully configured, a window in which default credentials or unfinished setups are common. Defenders use exactly the same data in reverse — to inventory their own surface, to spot certificates issued for lookalike domains before phishing begins, and to detect mis-issued certificates for their own names.

Certificate Transparency Logs — What They Reveal, How to Search (crt.sh)

Certificate Transparency (CT) logs are public, append-only records of every TLS certificate issued by a publicly trusted certificate authority. Browsers require certificates to be logged before they will trust them, so the logs are close to complete — which makes them the best free source for finding a domain's subdomains, catching lookalike certificates, and, from the other side, a way your own internal hostnames leak.

What is Certificate Transparency and why does it exist?

CT was created after certificate authorities were caught issuing certificates they shouldn't have. The idea: if every certificate must be published to tamper-evident public logs, mis-issuance can be detected by anyone, including the domain owner. Chrome began requiring CT for all new certificates in 2018 and Safari followed; today a certificate that isn't logged simply doesn't work in mainstream browsers (how CT works, standardised in RFC 6962). Logs are run by Google, Cloudflare, DigiCert, Sectigo and others; monitors and search services index them.

How do you search CT logs?

crt.sh (Sectigo) — the standard web interface. % is the wildcard: %.example.com for subdomains, %example% for anything containing the brand. Has a JSON output and a PostgreSQL interface for heavy use; it is a free service that 5xx-es under load, so script with retries.
Cert Spotter (SSLMate) — a JSON API with an issuance feed; good fallback and good for monitoring new issuances.
Censys certificates search, Google's transparencyreport.google.com/https/certificates — alternative indexes with different freshness and query features.
Facebook's CT monitoring and similar free monitors — subscribe to a domain and get emailed on new certificates.

# Every name that ever had a public certificate under the domain
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | tr 'A-Z' 'a-z' | sed 's/\*\.//' | sort -u

# Certificates issued in the last 24h that mention the brand (lookalike watch)
curl -s "https://crt.sh/?q=%25example%25&output=json" \
  | jq -r '.[] | select(.entry_timestamp > (now - 86400 | todate)) | "\(.entry_timestamp) \(.name_value) \(.issuer_name)"'

# Cert Spotter: current issuances including subdomains
curl -s "https://api.certspotter.com/v1/issuances?domain=example.com&include_subdomains=true&expand=dns_names" | jq -r '.[].dns_names[]' | sort -u

What do CT logs reveal about your organisation?

Every hostname that had HTTPS — staging, dev, vpn, jira, grafana, the 2019 microsite. This is why CT is the first stop of subdomain enumeration.
Timelines — when a host appeared and when its certificates stopped being renewed, i.e. when it was probably retired (or forgotten but left running).
Infrastructure hints — the issuing CA and certificate style often reveal the hosting platform (Let's Encrypt via a CDN, Amazon-issued, a corporate CA for SaaS custom domains).
Lookalikes — certificates issued for examp1e-login.com show up in the same public feed, days before the phishing site is used. That is the signal the Domain Monitor sweeps for daily.

Common gotcha: CT is not a leak you can plug — the logging is mandatory — but you control what goes in. If internal hostnames (jenkins-prod-2.corp.example.com) shouldn't be public, put them under a wildcard certificate, an internal CA, or a separate internal domain. A wildcard hides the names from CT at the cost of making your passive inventory harder — use your zone export for that instead.

For the site owner and for the developer

For the site owner (plain English)

Every website address your company has ever secured with HTTPS is listed in a public directory, and anyone can read it — that is by design and applies to everyone. Two consequences for you: it is the easiest way to see what web properties your business has accumulated, and it is the earliest public warning when someone sets up a fake site with a name like yours. Use the first once a quarter; automate the second.

See what CT logs say about your domain — every name in certificate history, classified as live, third-party, dangling or gone.

Search CT for your domain →

For the developer / IT

Script the crt.sh query with retries and a fallback to Cert Spotter; cache results (crt.sh is a courtesy service).
Diff the name list monthly; new names are new assets, disappearing renewals are candidates for retirement.
Alert on new certificates for names containing your brand (the lookalike feed); whitelist your own CAs and platforms to cut noise.
Verify your own issuances too — an unexpected certificate for your domain from a CA you don't use is the mis-issuance CT was invented to catch. Consider a CAA record (example.com. CAA 0 issue "letsencrypt.org") to restrict which CAs may issue for you.

Certificate Transparency Logs: What They Reveal and How to Search Them (crt.sh and Beyond)