Certificate Transparency Search

Search Certificate Transparency logs for a domain

About Certificate Transparency

Certificate Transparency (CT) is a public logging system that records all TLS certificates issued by participating Certificate Authorities. By searching CT logs, you can discover every certificate that has been issued for your domain, monitor for unauthorized issuance, and maintain visibility into your certificate ecosystem. Our CT Search tool queries multiple CT log servers to provide a comprehensive view of a domain's certificate activity.

How to Use

Enter the domain name you want to search for in CT logs.
Click Check to query Certificate Transparency log servers.
Browse the results to see all certificates issued for the domain, including issuer details and validity periods.
Use the information to identify unexpected or potentially unauthorized certificate issuances.

Use Cases

Certificate Monitoring: Track all certificates issued for your domains to detect rogue or unauthorized certificates.
Security Incident Response: Investigate potential man-in-the-middle attacks by searching for suspicious certificates.
Inventory Management: Build a complete inventory of all certificates associated with your organization's domains.
Compliance Reporting: Verify that all certificates for your domains are properly logged in CT as required by browser policies.

Frequently Asked Questions

Certificate Transparency is an open framework for monitoring and auditing TLS certificates. All publicly trusted CAs must log every certificate they issue to CT logs, creating a public record that anyone can search and verify.

Searching CT logs helps you detect unauthorized certificate issuance, maintain an accurate certificate inventory, and ensure compliance with industry standards. If a certificate appears in CT logs that you didn't request, it could indicate a security breach.

Since April 2018, all publicly trusted TLS certificates must be logged in CT logs to be trusted by modern browsers. However, internally issued certificates from private CAs may not appear in public CT logs.

Three things in practice. Certificates issued for your domain by an authority you did not choose, which is either a mistake or something you should be able to explain. Certificates for hostnames containing your domain issued to an unrelated organisation, which is how typosquatting gets caught. And a certificate issued months earlier for a hostname you no longer control, which tells you a former subdomain still exists in someone else's hands. None of that is visible from a DNS lookup or from the certificate the site is currently serving.

No, and this is the most important thing to understand about transparency logs. Logging happens at issuance, before anybody looks at the certificate, and it says nothing about whether the issuer was entitled to issue it or whether the certificate is still trusted now. A certificate can be logged and then revoked, or logged and then distrusted when an authority misbehaves. CT tells you what exists; whether it is good requires checking revocation and the issuer's current standing.

Because one certificate can be logged more than once. A certificate may be submitted to several logs deliberately, because the CA Browser Forum requires multiple independent logging; a submission that did not make it into its final SCT set may be logged again; and an aggregator may index the same certificate from more than one source. Duplicate rows are normal and are not evidence of anything by themselves. Look at the serial number: identical serials are the same certificate seen twice, different serials are genuinely different certificates.

When a certificate authority issues, it normally first creates a precertificate — a provisional object with the poison extension that guarantees it cannot be used — so it can be submitted to logs before the real certificate exists. The final certificate is logged separately, and the two appear in CT with different identifiers but the same subject. That is why a single issuance can show two rows with matching names and different serial numbers. Neither row is a duplicate in the sense of being wrong.

Periodically rather than constantly, because the useful signal is a change you did not make. Once you know which authorities you use, a search is mostly a check that nothing else has been issued. It becomes urgent after events that do not require your involvement: an authority breach, a registrar compromise, or a domain transfer that you did not initiate. For continuous monitoring, watch the logs directly rather than polling this page, and alert on an issuer that is new or unexpected.

What the Search Covers

Certificate Transparency is the public record of what has been issued, and it exists so that misissuance is discoverable by anyone rather than only by the authority that made the mistake.

1The domain is queried against an aggregated index of CT logs rather than a single log, so the results are as complete as the index is current.
2Each entry is returned with its issuer, validity window, common name, every name in the subject alternative list, its serial number and the time it was logged.
3Results are sorted newest first, so the current certificate is at the top and the history reads backwards in time.

A search matches any certificate naming the domain, including certificates for hostnames that merely contain it. Read the name list rather than assuming every result is for the exact host you typed.

Tips & Best Practices

•Search for wildcard certificates (*.yourdomain.com) to find subdomain certificates
•Set up CT monitoring alerts for continuous protection instead of manual searches
•Use date filters to focus on recent certificates during incident response
•Combine CT search with DNS enumeration for complete domain discovery

Technical Details

Logs: All public CT logs including Google Argon, Cloudflare Nimbus, DigiCert Yeti
Data: Certificate details including issuer, validity, SAN entries, CT timestamps
Speed: Parallel queries across multiple CT logs
History: Data going back to CT log inception in 2013