Certificate Transparency Search

Search the public Certificate Transparency logs for every TLS certificate ever issued under a domain. Enter a domain and this tool queries crt.sh on the server, then summarises what it finds: which Certificate Authorities issued certificates, how many, the date range they span, and a table of the most recent certificates with their validity dates and a link to the full record. It is the quickest way to audit a domain's certificate history and spot anything unexpected.

How to use the Certificate Transparency Search

Enter a domain and press Search certificates. The tool reports:

• A summary: how many certificates are logged, how many unique hostnames they cover, and the date range from first issuance to latest expiry.
• The issuing CAs, ranked by how many certificates each one issued, so you can see who your certificates actually come from.
• A table of the most recent certificates — hostname, issuer, valid-from and expiry dates — each linking to its full entry on crt.sh.

Because crt.sh searches a very large public dataset, a query can take a few seconds, and busy domains return a capped sample of recent certificates. If you only want the deduplicated list of hostnames for reconnaissance, the Subdomain Finder runs on the same data and presents it that way.

What Certificate Transparency is and why you can search it

Certificate Transparency (CT) is a public, append-only logging system, defined in RFC 6962, that every publicly-trusted Certificate Authority must submit issued certificates to. Browsers reject certificates that are not present in the logs, so in practice every certificate a real CA issues ends up recorded in CT, permanently, where anyone can search it. crt.sh, operated by Sectigo, is the most widely used front-end for querying those logs, and this tool runs your search through it.

The logs exist for accountability: they make every certificate issuance visible. Before CT, a CA could mis-issue a certificate for your domain — by mistake or compromise — and you might never know. Now, because the issuance is logged publicly, you can watch the record yourself and catch a certificate you did not ask for. That is why CT search is a core part of certificate monitoring and domain-security hygiene, not just reconnaissance.

Each entry records the certificate's subject names (the hostnames it is valid for), the issuing CA, and its validity window (not-before and not-after dates). This tool aggregates all of that for a domain so you can answer questions at a glance:

• Who issues your certificates? If you only use one CA but the logs show certificates from another, that is worth investigating.
• How far back does the record go, and what is still valid? The date range shows the domain's certificate history and which certs are current.
• What was issued most recently? The recent-certificate table surfaces new issuance, which is exactly where an unexpected certificate would appear.

It is honest to note the limits: CT only contains certificates from publicly-trusted CAs, so a certificate from a private internal CA will not appear, and the log is a permanent history that includes long-expired certificates. Read alongside those caveats, though, the CT record is the most complete public view of a domain's certificates that exists.

Common use cases

• Mis-issuance monitoring — watch for certificates issued for your domain that you did not request, the classic early signal of a compromise or a CA error.
• CA audit — confirm that certificates for your domain come only from the Certificate Authorities you actually use, and catch shadow issuance from another CA.
• CAA verification — after setting a CAA record to restrict which CAs may issue, check the logs to confirm only the allowed CA appears going forward.
• Certificate inventory — build a picture of every certificate covering a domain and its subdomains, including ones issued by teams you may not control.
• Incident investigation — during a security review, reconstruct the issuance timeline for a domain from the permanent public record.

Reading the results: issuers, dates and what to act on

The summary is a quick audit; the detail tells you what to do next:

• An unfamiliar issuing CA. If the issuer list shows a CA you do not use, treat it as a finding. It can be legitimate — a CDN or a different team issuing certificates — but it can also be the first sign of mis-issuance. Trace the specific certificate via its crt.sh link and confirm you authorised it.
• A recent certificate you do not recognise. The recent-certificates table is where new issuance shows up first. A cert for a hostname or from a CA you did not expect, dated in the last few days, is the one to investigate immediately.
• Restrict future issuance with CAA. Once you know which CAs should be able to issue for your domain, publish a CAA record to enforce it and re-check the logs later to confirm nothing else appears. The CAA Checker confirms the record is live.
• Check the live certificate, not just the log. The CT record is history; to inspect the certificate a server is actually presenting right now — chain, expiry, key — use the SSL Certificate Checker.

For reconnaissance and asset discovery rather than certificate auditing, the same data is better consumed as a hostname list: the Subdomain Finder deduplicates every subdomain seen across these certificates into a single copyable list.