See every TLS certificate ever issued for your domain. Discover hidden subdomains, spot rogue certificates, and audit your CAs.
Certificate Transparency is a Google-led initiative that requires every TLS certificate issued by a public CA to be logged in a public, append-only log. The intent is to detect rogue certificates — but the side effect is that anyone can see every subdomain you've ever requested a certificate for. Attackers use CT logs as the #1 source for subdomain enumeration during recon. This checker shows you exactly what they see.
## Why CT log enumeration is a security issue
Most companies have forgotten dev, staging, demo, or admin subdomains lying around — `staging.example.com`, `admin-old.example.com`, `backup.example.com`. These were once protected by basic auth or IP allowlists, but configs drift and protections lapse. Attackers running CT-log enumeration find these in seconds, then probe each one for weak auth, old software, or exposed APIs. "We didn't think anyone knew about that subdomain" is the post-mortem on countless breaches.
## Rogue certificate detection
If an attacker compromises a CA (it has happened — DigiNotar in 2011, Symantec deprecation in 2017) or socially engineers one into issuing a cert for your domain, they can mount man-in-the-middle attacks on your users. CT logs make this detectable: any cert issued for your domain shows up in the log, and you'll see it via this check (or via dedicated monitoring like Cert Spotter). The "new since last check" metric is your rogue-cert alert.
## Wildcard certificates — pros and cons
A wildcard cert (`*.example.com`) covers any subdomain without revealing each subdomain's name in CT logs. For dev/staging environments this is a privacy win. The tradeoff: if the wildcard cert's private key is ever stolen, the attacker can impersonate ANY subdomain. Use wildcards for low-value subdomains; use named certs (and accept the CT log exposure) for high-value production hosts.
## CAA records — restricting who can issue certs
DNS CAA records let you declare which Certificate Authorities are allowed to issue certs for your domain. Setting `example.com. CAA 0 issue "letsencrypt.org"` means no other CA will issue you a cert (compliant CAs check CAA before issuance). This is one of the highest-ROI security configs: 5 minutes of work, eliminates an entire attack class.
## Why we use crt.sh
crt.sh is the gold-standard public interface to CT logs, run by Sectigo and used by basically every security tool. We query it for `%.example.com` (all subdomains) and `example.com` (base domain), deduplicate by serial number, and present the results. Their data is comprehensive and free.
Certificate Transparency logs are public — meaning attackers can see every subdomain you've ever requested a cert for. Forgotten staging or dev subdomains exposed in CT logs are a top recon source for breaches. This check shows you what's publicly known about your domain.
We extract the base domain from your input (`www.example.com` → `example.com`), then query crt.sh for both `%.example.com` (wildcard match for all subdomains) and `example.com` (base domain). The response is a JSON array of every certificate logged for those names — typically dozens to hundreds, sometimes thousands for large sites. We deduplicate by serial number, extract unique subdomains from the `name_value` field, count wildcards and expired certs, and identify the issuing CAs from the certificate Subject. The "new since last check" delta lets authenticated LemWatch users get alerted to certs issued they didn't request — the cleanest rogue-cert signal available.
CT logs are append-only and immutable — every cert ever issued stays in the log forever. Expired certs are listed so you can confirm they're no longer in use, and identify subdomains attackers may still try.
You can't — CT logging is mandatory for publicly-trusted certs. The workaround is to use a wildcard certificate (*.example.com), which covers any subdomain without naming it. For maximum privacy use a private CA for internal services, but you lose the trust chain.
Investigate immediately. It could be a misconfigured deployment, a forgotten dev environment, or a malicious cert. Contact the issuing CA to revoke if it's rogue.
Yes — it's a 5-minute change that prevents most categories of rogue-cert issuance. Set `example.com. CAA 0 issue "letsencrypt.org"` (or your CA of choice).
The base domain you submit. Subdomains pointing to third parties (e.g. a Vercel deployment) will only show certs issued for your domain, not the third party's.