Why are old/expired certs showing up?

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.

How do I hide subdomains from CT logs?

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.

What if I see a cert I didn't request?

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.

Should I set CAA records?

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).

Does this check certs for my IP, my CNAME target, or what?

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.

Free Tool

Updated 6 June 2026

Certificate Transparency Checker

See every TLS certificate ever issued for your domain. Discover hidden subdomains, spot rogue certificates, and audit your CAs.

By Deepak Shukla — Founder & CEO, Pearl Lemon

Part of SSL certificate monitoring — the full answer, the facts and the alternatives in one place.

Enter your domain

What This Tool Checks

Every TLS certificate ever issued for your domain (and subdomains)
Hidden subdomains exposed via CT logs (shadow IT, dev environments)
Wildcard certificates in use
Expired certificates still on file
Issuing CAs (Let's Encrypt, DigiCert, Google Trust Services, etc.)
New certificates issued since your last check (rogue-cert detection)

Why This Matters

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.

How to Fix Issues

1.Audit subdomains discovered — shut down any that shouldn't exist
2.Use wildcard certificates for ephemeral dev/staging to avoid leaking subdomain names
3.Monitor CT logs for new certs you didn't request (rogue-cert alerting)
4.Revoke and renew certs from any CA you no longer trust
5.Set up CAA records to restrict which CAs can issue for your domain

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.

Methodology

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.

Frequently Asked Questions

Monitor this continuously with LemWatch

A one-off free certificate transparency checker shows you today. LemWatch re-runs the same checks around the clock and alerts you the moment something breaks — free for up to 10 sites, no card needed.