Certificate Transparency Logs: How to Search and Monitor SSL Certificates

Certificate Transparency is a public audit system for SSL/TLS certificates. The premise is straightforward: every certificate issued by a trusted Certificate Authority must be submitted to at least two independent CT logs before browsers will accept it. Those logs are append-only, cryptographically verifiable, and open for anyone to search. This means there is a public, near-real-time record of every certificate ever issued for your domain, and you can use that record to catch unauthorized issuance, discover forgotten subdomains, and spot phishing infrastructure impersonating your brand.

Before CT existed, a Certificate Authority could issue a certificate for any domain without the domain owner ever knowing. The only way to discover a rogue certificate was to encounter it in the wild, which usually meant a successful man-in-the-middle attack had already happened. CT flipped that dynamic. Now every issuance event is logged publicly, and anyone with a reason to care can watch those logs continuously. The system was designed at Google, standardized as RFC 6962, and is now enforced by every major browser.

This guide covers how CT works at a protocol level, how to search the logs, what security monitoring looks like in practice, and how to pair CT monitoring with CAA records for a defense that is both preventive and detective.

How Certificate Transparency Works

The CT system has three roles: CAs that submit certificates, log servers that store them, and monitors that watch for new entries. The interaction between these roles follows a specific sequence that happens every time a certificate is issued.

1. Pre-certificate submission. Before a CA issues the final certificate, it creates a pre-certificate, a version of the certificate with a special poison extension that prevents it from being used directly. The CA submits this pre-certificate to two or more CT log servers.
2. Signed Certificate Timestamp (SCT). Each log server responds with an SCT, a signed promise that the certificate will be included in the log within a defined time window called the Maximum Merge Delay (typically 24 hours). The SCT is the proof that submission happened.
3. SCT embedding. The CA embeds the SCTs into the final certificate. Alternatively, SCTs can be delivered via a TLS extension during the handshake or through OCSP stapling, but embedding is by far the most common method.
4. Browser enforcement. When a browser connects, it verifies the certificate carries valid SCTs from at least two independent logs. Chrome enforces this strictly: missing or invalid SCTs cause the connection to be downgraded or rejected.

The logs themselves are Merkle tree structures, the same data structure behind blockchain systems and Git commits. Each entry is hashed into a tree, and the root hash provides a compact proof that no entry has been modified or removed after insertion. This is what makes the append-only guarantee verifiable rather than just a policy claim.

CT Log Operators

Not all CT logs are equal, and browsers do not accept SCTs from arbitrary logs. Chrome maintains a list of trusted logs, and a log must meet strict uptime and operational requirements to stay on that list. The major operators today are Google (operating the Argon and Xenon log families), Cloudflare (Nimbus), Let's Encrypt (Oak), and Sectigo. Each operator runs multiple sharded logs to handle the volume, which now exceeds billions of certificates.

The diversity of operators is a deliberate security property. Requiring SCTs from logs run by different organizations means that compromising a single operator is not enough to issue a certificate without leaving a public trace. If Google's logs were the only ones that mattered, a compromise at Google would undermine the entire system. With multiple independent operators, an attacker would need to compromise at least two organizations simultaneously.

Searching CT Logs

The raw CT log API defined in RFC 6962 is designed for machines, not humans. It exposes endpoints like get-entries that return batches of certificates in ASN.1 DER encoding, which is not something you want to parse by hand. Fortunately, several services index these logs and provide search interfaces.

crt.sh is the most widely used CT search engine. Operated by Sectigo, it continuously ingests entries from all trusted CT logs and stores them in a PostgreSQL database that supports both web and SQL query interfaces. You can search by domain name, issuer, serial number, or SHA-256 fingerprint. Wildcard searches work too: searching for %.example.com returns every certificate that covers any subdomain of example.com.

# Search for all certificates covering example.com and its subdomains
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq '.[] | {id, name_value, issuer_name, not_before, not_after}' | \
  head -40

# Example output (abbreviated):
# {
#   "id": 12849374621,
#   "name_value": "mail.example.com",
#   "issuer_name": "C=US, O=Let's Encrypt, CN=R3",
#   "not_before": "2026-09-15T00:00:00",
#   "not_after": "2026-12-14T23:59:59"
# }
# {
#   "id": 12849374598,
#   "name_value": "staging.example.com\nwww.staging.example.com",
#   "issuer_name": "C=US, O=Let's Encrypt, CN=R3",
#   "not_before": "2026-09-01T00:00:00",
#   "not_after": "2026-11-30T23:59:59"
# }

Google's Transparency Report provides another search interface at transparencyreport.google.com/https/certificates. It is less flexible than crt.sh for bulk analysis but offers a clean view of certificate history for a specific domain.

DomScan's Certificate Transparency API provides a programmatic interface that returns structured results including issuer details, validity windows, SAN lists, and log source information. It is designed for integration into monitoring pipelines where you need machine-readable output without scraping HTML or handling crt.sh rate limits.

# Search certificates for a domain using DomScan
curl -s "https://domscan.net/api/v1/certificates?domain=example.com" \
  -H "X-API-Key: your-api-key" | jq .

# Returns structured data: issuer, SANs, validity, log sources
# Useful for automated pipelines and integration with alerting systems

Security Monitoring with CT Logs

Searching CT logs reactively is useful, but the real power is in continuous monitoring. When you watch CT logs for new entries that match your domains, you gain near-real-time visibility into certificate issuance events. This unlocks four distinct security capabilities.

Detecting Unauthorized Certificates

If a CA issues a certificate for your domain and you did not request it, that is either a CA compromise, a domain validation failure, or someone who gained temporary control of your DNS or email. Any of those scenarios is a serious security incident. CT monitoring lets you detect it within minutes of issuance, rather than discovering it months later when a security researcher notices or an attacker has already used it. The response is to revoke the certificate and investigate how validation was bypassed.

Discovering Subdomains

Every certificate lists the hostnames it covers in the Subject Alternative Name (SAN) extension. That means CT logs are one of the best passive subdomain enumeration sources available. When a developer provisions a certificate for internal-api.staging.example.com, that hostname appears in the public CT logs regardless of whether the subdomain is in public DNS. DomScan's Subdomain Discovery tool uses CT logs as one of its primary data sources for exactly this reason.

Wildcard certificates (those covering *.example.com) also appear in CT logs. While they do not reveal individual subdomain names, they tell you which domains have wildcard coverage, which is valuable information for understanding an organization's certificate management practices.

Catching Phishing Infrastructure

Attackers who set up phishing sites frequently obtain legitimate SSL certificates to make the phishing page appear trustworthy. A certificate for examp1e.com or example-login.com will appear in CT logs as soon as it is issued. By monitoring CT logs for certificates that match patterns similar to your brand, like common typosquats, homograph variations, or keyword combinations, you can identify phishing campaigns during their setup phase, before the first email is sent.

Auditing CA Behavior

CT logs create accountability for Certificate Authorities. If a CA misissues a certificate, whether through a validation bug, a policy violation, or an operational error, the evidence is in the public logs permanently. This is how the industry discovered multiple CA incidents: researchers and automated monitors scanning the logs found certificates that should never have been issued. The Symantec distrust event in 2017, which resulted in Chrome removing trust for all Symantec-issued certificates, was built on evidence gathered from CT logs.

CAA Records: Controlling Who Can Issue

Certificate Transparency is a detective control: it tells you what happened after issuance. CAA (Certificate Authority Authorization) records are a preventive control: they tell CAs what is allowed before issuance. Used together, they form the strongest practical defense against unauthorized certificate issuance.

A CAA record is a DNS record that specifies which Certificate Authorities are authorized to issue certificates for a domain. CAs are required to check CAA records before issuing, and they must refuse to issue if the CAA record lists other CAs or explicitly forbids issuance. The DNS record type is straightforward.

# Allow only Let's Encrypt to issue standard certificates
example.com.  CAA  0 issue "letsencrypt.org"

# Allow only Digicert for wildcard certificates
example.com.  CAA  0 issuewild "digicert.com"

# Send violation reports to a security contact
example.com.  CAA  0 iodef "mailto:[email protected]"

# Deny all issuance (useful for domains that should never have certs)
parked-domain.com.  CAA  0 issue ";"

The iodef tag is particularly useful in combination with CT monitoring. When a CA encounters a CAA record that blocks issuance, the iodef URL is where violation reports are sent. This gives you an additional signal, distinct from CT log monitoring, that someone attempted to obtain a certificate for your domain and was blocked.

• CAA without CT monitoring means you have a gate but no alarm. A CA that ignores CAA (through a bug or compromise) will issue the certificate silently, and you will not know.
• CT monitoring without CAA means you have an alarm but no gate. You will see unauthorized certificates appear, but only after they have been issued and potentially used.
• Both together gives you a gate that blocks compliant CAs and an alarm that catches anything that slips through. This is the configuration you want.

You can verify your current CAA configuration alongside other DNS and SSL health indicators using Domain Health, which checks whether CAA records exist and whether they are consistent with the certificates actually in use.

CT Logs for Subdomain Discovery

CT-based subdomain enumeration deserves a deeper look because it has properties that other enumeration methods lack. DNS brute-forcing only finds subdomains that exist in public DNS at the moment you query them. Zone transfer attempts usually fail because most authoritative servers block AXFR. Passive DNS databases depend on resolvers that happened to cache the records. CT logs, by contrast, capture every hostname that was ever included in a publicly trusted certificate, regardless of whether it currently resolves.

This temporal coverage is what makes CT particularly valuable. A subdomain like old-api.example.com might no longer exist in DNS, but if someone issued a certificate for it eighteen months ago, it appears in CT logs forever. That tells you the hostname existed, which tells you to check whether the underlying infrastructure is still running, whether the DNS record was cleanly removed, and whether a dangling CNAME might create a subdomain takeover opportunity.

• Current hostnames that are live and resolving, often revealing services you did not know had certificates.
• Historical hostnames from expired or revoked certificates, pointing to infrastructure that may still be partially deployed.
• Internal-sounding names like staging.example.com, dev-api.example.com, or jenkins.example.com that developers provisioned with public CAs instead of private ones.
• Multi-SAN certificates where a single cert covers dozens of hostnames, revealing relationships between services and the scope of deployment automation.

The practical workflow is to start with a CT search for %.yourdomain.com, deduplicate the hostnames, resolve each one to check if it is live, and flag any that point to services you do not recognize. DomScan's Subdomain Discovery tool automates this entire pipeline, combining CT data with other passive sources and resolving the results.

Setting Up CT Monitoring

The difference between searching CT logs and monitoring them is automation. A search is something you do when you have a reason. Monitoring is a continuous process that alerts you when something happens, whether or not you expected it. For domain security, monitoring is what you actually need.

Effective CT monitoring watches for new certificate log entries matching your domains and evaluates each one against a policy. A new certificate from your authorized CA for a known hostname is expected. A new certificate from an unfamiliar CA, or for a hostname you do not recognize, is an event that needs investigation. The monitoring system should distinguish between these cases and only alert on the latter.

• Define your scope. List every domain and subdomain pattern you want to monitor. Include your primary domains, product domains, brand-adjacent domains, and common misspellings that phishers might target.
• Choose your alert channels. Email works for low-volume monitoring. Webhook integrations with Slack, PagerDuty, or your SIEM are better for teams that need to triage quickly.
• Set your policy. Decide what constitutes a normal issuance versus an anomaly. Certificates from your authorized CAs for known hostnames are routine. Anything else should generate an alert.
• Establish a response playbook. When an alert fires, the team needs to know: verify whether the certificate was legitimately requested, check who controls the domain validation method, and if the certificate is unauthorized, initiate revocation immediately.

DomScan's Domain Monitor includes CT monitoring as part of its broader domain surveillance capability. It watches for new certificate issuance events alongside DNS changes, availability shifts, and SSL configuration changes, giving you a single monitoring surface for all domain-related events.

Practical CT Workflow

Bringing all of this together, a practical Certificate Transparency workflow for an organization looks like this: publish CAA records to restrict which CAs can issue for your domains. Set up continuous CT monitoring to detect any issuance that does occur. Periodically search CT logs for subdomain enumeration and asset discovery. Integrate CT data into your incident response process so that a rogue certificate triggers an immediate investigation.

Start by running your domains through the Certificate Transparency API to see what certificates currently exist. Compare that list against what you expect. If there are certificates from CAs you do not use, or for hostnames you do not recognize, investigate those first. Then check your Domain Health to confirm CAA records are in place. Finally, set up monitoring through Domain Monitor so that future issuance events are automatically flagged.

Independent references: Review the full CT protocol specification in RFC 6962 and explore the CT log data directly at crt.sh, the most comprehensive public CT search engine.