---
title: "Certificate Transparency Checker — Free CT Log Lookup"
description: "Free certificate transparency checker. Lists every SSL/TLS certificate ever issued for your domain via crt.sh, plus subdomains and CA breakdown."
canonical: "https://lemwatch.com/tools/certificate-transparency-checker"
source: "https://lemwatch.com"
---

# Certificate Transparency Checker

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

## 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 it 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 what it finds

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

## 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

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


## Related

- [All free tools](https://lemwatch.com/tools)
- [SSL Checker](https://lemwatch.com/tools/ssl-checker)
- [Exposed Services Checker](https://lemwatch.com/tools/exposed-services-checker)
- [Mozilla Observatory Scan](https://lemwatch.com/tools/mozilla-observatory-checker)
- [URL to Markdown Converter](https://lemwatch.com/tools/url-to-markdown)
- [HTML Validator](https://lemwatch.com/tools/html-validator)
- [Lemwatch pricing](https://lemwatch.com/pricing)
- [All monitoring checks](https://lemwatch.com/features)
