Certificate Transparency Lookup

Search Certificate Transparency logs for every certificate issued to a domain

Type a domain and this tool pulls the public Certificate Transparency record for it: every certificate a publicly trusted CA has logged for that name and its subdomains, active and expired, going back as far as the logs do. You get the certificate list, a deduplicated list of every subdomain that appeared in a SAN field, a breakdown of which CAs issued what, and a flag on anything that looks out of place.

Two questions bring people here. The first is defensive: has anyone obtained a certificate for my domain that I did not ask for? The second is reconnaissance: what hostnames does this organisation actually run? CT answers both, because it is the same data either way.

What Certificate Transparency is, and why it exists

Before CT, a certificate authority could issue a certificate for any domain in the world and nobody outside that CA would necessarily ever know. Browsers trusted a few hundred root CAs; any one of them could mint a valid certificate for your bank, and the only way you would find out is if someone happened to catch it in the act. That is not hypothetical — the DigiNotar breach produced fraudulent certificates for major domains that were used against real users, and the CA was removed from browser trust stores as a result.

Certificate Transparency, specified in RFC 6962, fixes the visibility half of that problem. CAs submit every certificate they issue to a set of append-only, publicly auditable logs. The log returns a Signed Certificate Timestamp (SCT), which is a promise that the certificate has been published. Browsers require those SCTs: Chrome and Safari will not trust a publicly issued certificate that is not accompanied by proof of CT logging. The practical consequence is that a mis-issued certificate can no longer be kept secret. It can still be issued — CT does not prevent anything — but it becomes visible to anyone who looks, including you.

That is the mental model to hold: CT is a detection control, not a prevention control. The logs tell you what happened. Acting on it is still your job.

Where this tool's data comes from

The lookup runs through a server-side proxy on this site rather than querying a log aggregator from your browser directly, because a browser-to-crt.sh request fails on CORS. The proxy queries crt.sh with a wildcard search (%.yourdomain.com), which is what makes subdomain discovery work — you get certificates issued for the domain itself and for anything beneath it in one pass.

crt.sh is a search front end over the CT logs themselves, and it is chronically busy. The proxy gives it a short timeout and, if it does not answer, falls back to SSLMate's Cert Spotter API, and after that to a hostname-search source. crt.sh stays the preferred source because it returns richer records — serial numbers, per-certificate deep links, and a native filter for excluding expired certificates. When a fallback source is used, some per-certificate fields are thinner. The tool tells you which source produced the result at the bottom of the report.

Two queries run in parallel for every lookup: one for all certificates and one restricted to non-expired certificates. Large domains can return truncated results, and running the active-only query separately means a current certificate does not get lost behind thousands of historical ones.

What each entry actually tells you

Precertificates versus leaf certificates

Nearly every domain's CT record contains what look like duplicates — two entries, same names, same CA, timestamps moments apart. They are not duplicates and nothing is wrong.

The SCT has to be embedded inside the final certificate, but you cannot embed a signature over a certificate into that same certificate. CAs solve the chicken-and-egg problem by logging a precertificate first: a near-identical structure carrying a special "poison" extension that makes it invalid for actual use. The log signs it and returns an SCT, the CA then issues the real leaf certificate with that SCT embedded, and the leaf is usually logged too. Both are public, so both show up in a search.

This tool flags an entry as a precertificate using a timing heuristic — a meaningful gap between the log entry timestamp and the certificate's Not Before date. It is an inference from the data crt.sh returns, not a read of the poison extension itself, so treat the flag as a strong hint rather than a determination. When you are counting certificates, the safe rule is: count distinct serial numbers, not rows.

Using CT as a subdomain discovery channel

This is the part that surprises people the first time. Every hostname that has ever been given a publicly trusted certificate is in the logs, permanently, in plain text. There is no way to un-publish it. So if your organisation issued a certificate for vpn-old.example.com, jenkins.internal.example.com, or staging-payments.example.com, that name is public knowledge whether or not the host is still reachable and whether or not it was ever meant to be found.

The tool builds this list for you: it walks every SAN on every certificate returned, keeps the ones that are the domain or end in .yourdomain.com, deduplicates, sorts, and gives you a count plus a plain-text export. It is one of the cleanest subdomain enumeration sources that exists, because it requires no scanning, no brute-forcing of wordlists, and no traffic to the target at all.

Which is exactly why attackers use it. CT enumeration is a standard first move in reconnaissance, precisely because it is silent and high-yield. The defensive response is not to try to hide — you cannot — but to run the same query yourself and treat the output as an inventory:

• Names you do not recognise. Shadow IT, an old vendor pilot, a marketing agency that stood something up under your domain.
• Names that reveal internal structure. Ticket system, build server, and environment names in a hostname tell an attacker what to target and what software to research.
• Hosts that should have been decommissioned. A name in CT plus a live A record plus an unpatched service is the classic forgotten-host breach.
• Wildcards. A *.example.com certificate hides subdomains from CT entirely — useful if you want less exposure, dangerous because one compromised private key covers everything.

If a name in that list makes you uneasy, the answer is to decommission the host and revoke the certificate. Removing the DNS record alone does nothing to the log entry.

Spotting a certificate you did not authorise

The report includes a CA breakdown — each issuing organisation, how many certificates it accounts for, its share of the total, and whether it is one of the widely deployed public CAs the tool recognises. Most organisations have a very short list here, usually one or two CAs. An unfamiliar issuer appearing once is the signal worth chasing. Sort by CA and look at the tail, not the head.

Alongside that, the tool applies a set of heuristics and surfaces anything they catch, with a reason attached and an overall risk score. What it looks for:

• Historically compromised CAs. Certificates issued by CAs that were removed from browser trust — DigiNotar, WoSign, StartCom, CNNIC. Old entries from these are usually archaeology and are scored down accordingly; a recent one would be extraordinary.
• Very short validity from an unrecognised issuer. Certificates valid for under a week are ordinary from a modern automated CA, so this only fires when the issuer is neither a recognised public CA nor plausibly the domain owner.
• Look-alike names. An edit distance check on the domain label catches certificates for names one or two characters away from yours on a different registrable domain — the shape of a typosquat or phishing setup.
• Unrecognised issuers on recent certificates. Weighted higher than the same finding on something years old.

Scores decay with certificate age deliberately, because a raw CT dump for an established domain is mostly history and an undamped scorer would drown you in findings from a decade ago. Read the reasons, not just the number.

If you find a genuinely unauthorised certificate: capture the serial number and issuer from this report, contact that CA's problem-reporting address with them, and request revocation. Then check whether the affected hostname resolves anywhere you do not control.

Filtering, sorting and exporting

A busy domain can return thousands of rows, so results render 20 at a time with a control to load more. The filters are: include or exclude expired certificates, include or exclude wildcards, a free-text search across the results, and sort by issue date, expiry date, or CA. Every filter reapplies from the full result set, so narrowing and widening is lossless.

Three exports are available. JSON gives you the complete result object including the analysis. CSV gives one row per certificate with common name, SANs, issuer, CA, both validity dates in ISO form, status, wildcard flag and serial — the right format for reconciling against a certificate inventory in a spreadsheet. Subdomains gives a plain newline-delimited list, ready to pipe into whatever resolves or scans next.

Each certificate also links back to its record on crt.sh if you need the raw parsed certificate, the chain, or the specific logs that carry it.

Caching, and why a result can look stale

Two layers of caching sit in front of a lookup. The proxy response is cacheable at the edge for an hour, and the finished result is stored in your browser's local storage for 24 hours under a per-domain key. A repeat search inside that window returns instantly and is labelled as a cached result.

This matters if you just issued a certificate and are checking whether it landed. A brand-new certificate can take a short while to become searchable anyway — the CA submits it, the log incorporates it, the aggregator indexes it — and on top of that you may be reading your own cached copy. If a certificate you know exists is missing, that is the usual explanation, not an issuance failure.

What this tool does not do

It reads the public log record. It does not connect to your server, so it cannot tell you which certificate a host is actually presenting, whether the chain is complete, or whether the private key matches. A certificate can be present in CT and not deployed anywhere; it can be deployed and misconfigured in ways CT has no view of. It also does not check revocation status — a revoked certificate stays in the log forever, because the log is append-only by design.

The domain you search is sent to this site's proxy and on to the public CT search source, which is inherent to querying a remote log; the analysis, filtering and exports all run in your browser.

Common questions

• Why does my internal certificate not appear? Certificates from a private or internal CA are never submitted to CT. Only publicly trusted issuance is logged.
• Can I get an entry removed? No. CT logs are append-only and cryptographically verifiable precisely so that entries cannot be deleted. Plan hostnames on the assumption they are permanent and public.
• Someone got a certificate for a subdomain of mine. Do they control it? They controlled it, or something the CA accepted as proof of control, at issuance time. That is worth investigating on its own — especially for subdomains pointing at services you no longer own.
• Why do the counts differ from another CT search tool? Different aggregators cover different sets of logs and truncate large result sets differently, and precertificate handling varies. Compare serial numbers, not totals.
• Is there a monitoring version? This is an on-demand search. For continuous alerting on new issuance you want a CT monitoring service that watches the logs and emails you — but running this search periodically against your own domains catches most of what matters.