Certificate Transparency Search
Every publicly trusted certificate ever issued for a domain is written into public logs — this search reads them back for you. Enter a domain and see what crt.sh has recorded for it and its subdomains: who issued each certificate, which names it covers, and when it was valid. It is the audit that finds the certificates you forgot — and the ones you never asked for.
Want this watched continuously? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.
What the search measures
Certificate Transparency turns certificate issuance from a private transaction into a public record. When a certificate authority issues a certificate for a public name, it submits the certificate to several CT logs, and browsers refuse certificates that are not logged. The side effect is a gift to defenders: the complete issuance history of every domain is sitting in public, waiting to be read. The page calls GET /api/check/cert-search on sysosx's server, which makes a single request to crt.sh — the public index of those logs — for the domain and everything under it, normalises the answer, sorts it newest first, and caches it for an hour. Up to 200 entries are shown; a domain with more gets a truncation notice and the true total, never a silent cut.
Read the result as an inventory, not a verdict. The productive question for each entry is "which of our systems asked for this?" Modern estates issue certificates from more places than their owners realise: the web host, the CDN, the mail provider, the marketing team's site builder, a Kubernetes ingress on a cluster someone stood up last year. Most of those are legitimate and several will be news to you anyway — which is itself useful, because a certificate inventory you have never seen cannot be part of anyone's renewal or revocation plan. The entries that matter most are the ones nobody can match to a system: an unknown issuer, an unknown subdomain, an issue date with no deployment near it. Those are rare, and they are exactly what CT was designed to surface.
Three tools, three questions
This search answers "what has ever been issued?". The SSL checker answers "what does the server present right now?" with a live handshake — the only way to know what visitors actually get. The SSL grader answers "how well is that server's TLS configured?" — protocol versions, forward secrecy, HSTS, with a letter grade. And the browser-side SSL certificate parser reads a certificate file you already hold. A renewal that exists in the logs but was never deployed shows up here and not in the checker; a server presenting an old certificate shows up in the checker and not here. When they disagree, each is telling its own truth — use the one that matches your question.
Frequently asked questions
What is Certificate Transparency, in one paragraph?
Since 2018, browsers require publicly trusted certificates to be published in Certificate Transparency (CT) logs — public, append-only lists of every certificate a CA issues. The logs exist so that mis-issuance cannot hide: if a certificate for your domain appears that you never requested, it is visible to anyone who looks, including you. This tool looks on your behalf, through crt.sh, the best-known public index of those logs.
How is this different from the SSL checker and the SSL grader?
Three different questions. The SSL checker asks what certificate a server presents right now, in a live handshake. The SSL grader audits how that server's TLS is configured — protocols, ciphers, HSTS — and grades it. This search asks what has ever been issued for the domain, according to the public logs. It can surface certificates the live tools cannot: forgotten staging certificates, certificates from CAs your organisation no longer uses, and — the case CT was built for — certificates nobody on your team requested at all.
Why does this run from the server instead of in my browser?
The browser-side certificate parser on this site offers a crt.sh lookup too, and says plainly that whether it works depends on crt.sh's cross-origin headers — a browser can only read what a third-party service permits it to read. A server-side request has no cross-origin policy to satisfy, so the search here works the same way every time. The trade is the usual one: the domain you enter is sent to crt.sh from sysosx's server (and, for an hour, the answer is cached), which the page states rather than hides.
I see certificates I do not recognise. Should I panic?
Not yet. Most unfamiliar entries are mundane: a hosting provider or CDN issuing on your behalf (Cloudflare, a load balancer, a website builder), a certificate authority your organisation switched away from, or an automated renewal system someone set up and forgot. Work through the list by issuer and date and match each entry to a system you run or a provider you pay. Panic — well, urgent investigation — is for the remainder: a certificate from a CA nobody uses, covering names nobody runs, issued at a time nobody deployed anything. That is either a forgotten corner of your own estate worth documenting, or the mis-issuance CT exists to catch, and it should be chased until it is explained.
Why is the result cached for an hour, and why might the search fail?
Because crt.sh is a free public service, famously slow under load, and certificate history changes over days rather than minutes — an hour of caching costs nothing in freshness and keeps this tool from adding to crt.sh's burden: one upstream query per domain per hour at most. When crt.sh is down or too slow, the search says so with an explicit error rather than returning an empty list, because "no certificates found" and "the log search failed" are opposite conclusions and only one of them is true.