Certificate Transparency Lookup
Search public CT logs for certificates issued to a domain.
Certificate Transparency Lookup
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The Certificate Transparency Lookup searches Certificate Transparency (CT) logs — public, append-only, cryptographically verifiable records of every certificate a participating Certificate Authority has issued — for certificates associated with a given domain. CT exists specifically to make certificate mis-issuance detectable: before CT, a compromised or careless CA could issue a fraudulent certificate for any domain, and the domain's actual owner would have no reliable way to find out.
- The system was created in direct response to real incidents, most notably the 2011 DigiNotar compromise, where a CA was breached and used to issue fraudulent certificates for major domains that went undetected for weeks. CT logs mean any certificate issued for your domain — legitimate or not — becomes part of a public record you (or an automated monitoring tool) can search, turning an invisible risk into a detectable one.
- Since around 2018, major browsers require publicly-trusted certificates to be accompanied by Signed Certificate Timestamps (SCTs) — proof the certificate was actually submitted to CT logs — as a condition of being trusted at all, making CT participation effectively mandatory for the public web rather than an optional best practice.
How It Works
- You provide a domain name to search.
- The tool queries Certificate Transparency log records for certificates issued for that domain by any participating CA.
- Results show the issuing CA, when the certificate was logged, and its validity period — letting you see the actual issuance history for a domain across every CA that logged a certificate for it.
- Because CT logs are append-only and cryptographically verifiable (built on Merkle tree structures), entries can't be quietly removed or altered after the fact — a certificate once logged remains part of the searchable historical record.
Usage
- Enter the domain name you want to search.
- Run the search against Certificate Transparency logs.
- Review the results: issuing CA, logged date, and validity period for each certificate found.
- Investigate any certificate you don't recognize as one your organization actually requested.
Examples
- Searching your own company's primary domain periodically to confirm no unexpected certificates have been issued by an unfamiliar CA.
- Investigating a domain before an acquisition or partnership to understand its certificate issuance history and which CAs it currently relies on.
- Confirming a certificate issued through a new CA or ACME provider actually appears in CT logs shortly after issuance, as expected for browser trust.
- Researching how frequently a domain rotates certificates, which can indicate whether it uses short-lived, automated issuance (common with modern ACME-based workflows) or long-lived, manually-managed certificates.
Real-World Use Cases
- Monitoring your own domain for certificates you didn't request — the primary defensive use case CT was designed to enable, catching mis-issuance or compromise early.
- Investigating exactly how many certificates have been issued for a domain across its history, including by CAs you may not have directly used yourself.
- Confirming a newly-issued certificate actually appears in CT logs, which is required for major browsers to trust it at all.
- Researching a domain's certificate issuance pattern before an infrastructure migration, to understand which CAs and certificate types have been in use.
Best Practices
- Set up ongoing, automated CT log monitoring for domains your organization controls, rather than only checking manually and occasionally — mis-issuance detection is only useful if it happens quickly.
- Treat an unexpected certificate found in CT logs as a real incident to investigate immediately, not something to dismiss without confirming it wasn't actually authorized internally first.
- Understand that CT logs certificates issued, not necessarily certificates actively deployed — a logged certificate that was never installed anywhere is a different (and usually lower) concern than one actively serving traffic.
- Use CT log history as one input when auditing a domain's security posture, alongside DNS records and actual server-side TLS configuration, not as a complete picture on its own.
Common Mistakes
- Assuming CT logs are private or require special access — they're deliberately public and queryable by anyone, which is exactly what makes the monitoring use case possible.
- Treating an unfamiliar CA in the logs as automatically fraudulent without checking whether a different team or a CDN/hosting provider requested it legitimately on the organization's behalf.
- Not monitoring CT logs at all and relying solely on internal records of requested certificates — internal records can't reveal a certificate issued through a compromised or social-engineered CA account.
- Confusing CT log presence with active deployment — a certificate can be logged and never actually installed anywhere, which is a different situation from one actively serving production traffic.
Limitations
- This tool searches Certificate Transparency log data for a domain you specify; it does not itself issue certificates or verify whether a found certificate is currently deployed on any server.
- CT log coverage depends on which CAs and logs are queried — while all major public CAs participate as required for browser trust, coverage of every possible log operator may not be exhaustive.
- This tool reports what's in CT logs; it does not perform live DNS or TLS checks against the domain itself — pair it with the SSL Expiration Checker or SSL Certificate Chain Validator for that.
Technical Reference Guide
- Certificate Transparency (version 1) is defined by RFC 6962, specifying the log format, Merkle tree structure, and Signed Certificate Timestamp mechanism.
- A newer version, Certificate Transparency Version 2.0, is defined by RFC 9162, which obsoletes RFC 6962 and refines the log and SCT mechanisms based on operational experience.
- Major browsers' requirement that publicly-trusted certificates include valid SCTs is enforced through each browser vendor's own CT policy rather than a single universal specification, though it builds directly on the RFC 6962/9162 log mechanism.
FAQ
What was the incident that led to Certificate Transparency being created?
The 2011 compromise of the DigiNotar Certificate Authority, where attackers issued fraudulent certificates for major domains that went undetected for weeks. CT was designed specifically so a similar mis-issuance would be publicly visible and detectable quickly, rather than invisible until real damage occurred.
Are Certificate Transparency logs private?
No — they're deliberately public and append-only, so anyone (not just the domain owner) can search them. This openness is exactly what allows independent monitoring for unauthorized certificates.
What is a Signed Certificate Timestamp (SCT)?
It's cryptographic proof that a certificate was submitted to a CT log, issued by the log operator at submission time. Major browsers require valid SCTs before trusting a publicly-issued certificate at all.
If I find a certificate for my domain that I don't recognize, what should I do?
Investigate immediately — check whether another team, a CDN, or a hosting provider requested it legitimately on your organization's behalf before treating it as a security incident, but don't dismiss it without confirming that.
Does every certificate ever issued show up in CT logs?
Certificates from CAs that participate in CT (which is effectively all publicly-trusted CAs today, since it's required for browser trust) do. Internal, non-publicly-trusted certificates issued by a private organizational CA typically aren't logged to public CT logs.
Can a certificate be removed from CT logs once submitted?
No — CT logs are append-only by design, built on a Merkle tree structure specifically so entries can't be quietly altered or removed after the fact. A logged certificate remains part of the permanent historical record.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.
View all Certificate & PKI Lab tools