Certificate Transparency Logs Explained: How to Find Unexpected SSL Certificates for Your Domain
Certificate Transparency (CT) logs provide a public record of many TLS certificates issued for domain names. By searching them regularly, domain owners can find legitimate renewals, identify forgotten subdomains, and investigate certificates that do not match their approved certificate inventory. This guide explains a practical certificate lookup workflow, what each result means, how to distinguish an unexpected entry from a confirmed security incident, and when to repeat the check.
Overview
Certificate Transparency is a monitoring and accountability mechanism for the public certificate system. When a certificate authority (CA) issues a publicly trusted TLS certificate, the certificate or a related record is generally submitted to CT logs. Browsers and other systems can use these logs to make certificate issuance more visible, while domain owners can use them for certificate verification and domain monitoring.
A CT result is evidence that a certificate was logged. It is not, by itself, proof that a server is using the certificate, that the requester controlled the domain, or that an attacker compromised your infrastructure. Treat CT monitoring as an early-warning and inventory tool. Confirm the result through your DNS records, cloud or hosting accounts, certificate stores, web servers, and CA account records.
Search tools and log interfaces change over time. A domain search may also return historical, revoked, expired, duplicate, precertificate, wildcard, or subdomain entries. Results can be incomplete when a tool has indexing delays, limited wildcard handling, or a different interpretation of domain-name searches. For important domains, compare more than one reputable CT search interface and preserve the raw certificate details for investigation.
What to track
Build a small certificate inventory before deciding whether a CT entry is suspicious. Record the domains your organization owns, including production, staging, development, regional, customer-facing, and parked domains. Include known third-party services and approved certificate issuers where that information is available.
Field-by-field interpretation
| Field | What it tells you | Questions to ask |
|---|---|---|
| Certificate or entry name | The identifier used by the CT search tool. | Is this a certificate, precertificate, duplicate, or related log entry? |
| Subject Common Name (CN) | A subject name included in the certificate. | Does it match an approved hostname, or is it an old naming convention? |
| Subject Alternative Names (SANs) | The complete list of DNS names covered by the certificate. | Does it include an unexpected subdomain, internal-looking name, or typo? |
| Issuer | The CA that issued or logged the certificate. | Is this issuer approved, familiar, or used by a managed service? |
| Logged and issuance times | When the entry appeared in the log and when the certificate was issued, if shown. | Does the timing match a renewal, migration, acquisition, or change window? |
| Validity period | The certificate's not-before and expiration dates. | Is it active, expired, or overlapping with another approved certificate? |
| Wildcard scope | A name such as *.example.com may cover many first-level subdomains. | Could this wildcard affect an untracked host or delegated environment? |
| Revocation status | Whether the certificate may have been revoked, subject to the checking method. | Does revocation need separate confirmation through OCSP or CRL data? |
For a dependable ownership search, check the registered domain and common variants, then review every SAN. Search both the exact hostname and its parent domain where the tool supports it. A search for example.com may not reliably expose every certificate containing login.example.com, and a search for a wildcard may not show each individual host. Also look for internationalized-domain representations, alternate brand domains, and recently acquired names.
Practical lookup workflow
- Start with an authoritative domain list from your DNS, asset-management, or registrar records.
- Search each parent domain in a current CT log search interface.
- Filter or group results by certificate name, issuer, and date.
- Open each relevant result and inspect the full SAN list rather than relying only on the displayed name.
- Compare the result with your certificate inventory, renewal tickets, hosting providers, CDN configuration, and cloud accounts.
- Save the certificate serial number, fingerprint, issuer, timestamps, and SANs for entries that need review.
- Validate whether the certificate is presented by a live endpoint using an SSL certificate checker or direct TLS inspection.
For broader certificate validation, use the SSL certificate checker guide. CT monitoring answers “what was issued and logged?” A live certificate check answers “what is this service presenting now?” Those are related but different questions.
Cadence and checkpoints
CT monitoring works best as a recurring control rather than a one-time certificate authenticity check. A monthly review is reasonable for smaller domain portfolios when the review is documented. Larger or higher-risk environments may use automated alerts for new certificates and conduct a formal review at least quarterly. Choose a cadence that matches the number of domains, rate of infrastructure change, and consequences of certificate misuse.
Recommended checkpoints
- Monthly: Review new entries, unknown SANs, unfamiliar issuers, and certificates issued outside planned change windows.
- Quarterly: Reconcile CT results with the complete domain and certificate inventory, including dormant and non-production environments.
- Before or after renewals: Confirm that the expected certificate appeared and that old certificates are no longer being served where they should not be.
- After acquisitions or DNS changes: Add newly controlled domains, delegated subdomains, and third-party services to the monitoring scope.
- During suspected abuse: Search immediately, preserve evidence, and coordinate with the relevant CA, hosting provider, DNS administrator, and incident-response team.
Monitoring should record the search date, domains checked, tools used, reviewer, findings, and follow-up owner. Automated alerts are useful, but they need an allowlist or triage process. Otherwise, normal renewals and certificates issued by approved vendors can create alert fatigue.
How to interpret changes
Not every new CT entry is malicious. Common legitimate explanations include a routine renewal, a certificate for a new service, a CDN or hosting provider certificate, a migration between CAs, a wildcard certificate, or a duplicate entry generated during issuance. An expired certificate can remain valuable as historical evidence even though it is no longer valid for a current TLS connection.
Prioritize investigation when several signals appear together: the SAN list contains a hostname your organization does not recognize; the issuer or account is not approved; the timestamp falls outside a change window; the certificate is currently presented by an unknown endpoint; or the domain is associated with a sensitive login, payment, or administrative service.
Use this escalation template to keep the response factual:
Subject: Review requested: unexpected certificate for [domain]
Observed: A CT entry for [CN or SAN] was logged by [issuer] on [date and time]. Certificate fingerprint or serial: [identifier].
Expected explanation checked: [renewal, vendor, migration, wildcard, or none identified].
Validation performed: [DNS, live TLS endpoint, hosting account, CA account, certificate inventory].
Current assessment: [confirmed legitimate, unresolved, or suspected misissuance].
Requested action: [owner to confirm, CA inquiry, revoke and replace, endpoint isolation, or incident response].
If you suspect misissuance, contact the issuing CA through its published reporting channel and provide the certificate details and evidence. Do not assume that deleting a certificate from one server resolves the issue: a certificate may still be deployed elsewhere, and the private key may require replacement. For revocation concepts and validation errors, see how to check certificate revocation status.
When to revisit
Revisit this guide and your monitoring process monthly or quarterly, depending on your risk and operational change rate. Repeat a full CT certificate lookup after a domain acquisition, DNS or hosting migration, certificate renewal program, CA change, major application launch, or suspected domain abuse. Also review the process when your search tool changes its filters, when browser or CA requirements change, or when your organization begins using new wildcard, CDN, or managed-certificate services.
For the next review, take these actions:
- Update the authoritative list of owned domains, subdomains, and delegated services.
- Run searches for each parent domain and inspect SANs, wildcards, issuers, and dates.
- Compare new entries with approved changes and live endpoint results.
- Escalate unresolved certificates using the evidence template.
- Archive the review and assign a date for the next check.
CT logs are one part of certificate verification, not a replacement for certificate-chain checks, endpoint testing, revocation review, or documented ownership controls. Used together, these checks create a clearer view of which certificates were issued, which are active, and which require action.
