Certificate Transparency: A Practical Guide for DevOps and Security Engineers

Every certificate issued for your domain by a publicly-trusted certificate authority (CA) gets logged. Certificate transparency (CT) makes that logging cryptographically verifiable and publicly auditable. If you're not monitoring those logs, you're relying on browsers and end users to tell you when something goes wrong. That's not a detection strategy. This guide covers how CT works at the protocol level, how to operationalize monitoring for your infrastructure, and where the gaps are that no amount of log watching will close.

What is certificate transparency?

Certificate transparency is an open protocol that requires CAs to publish every certificate they issue to append-only, cryptographically verifiable logs. It shifts certificate issuance from a trust-me model to a prove-it model, giving domain owners a way to detect misissued certificates after the fact. Industry data indicates over 10 billion certificates have been logged since the CT ecosystem went live, and every major browser—Chrome, Safari, Firefox, and Edge—now enforces CT compliance as a condition of trust.

The problem CT solves

Before CT existed, a certificate authority could issue a certificate for any domain without anyone outside that CA knowing. If the CA was compromised, misconfigured, or careless, the certificate would be trusted by every browser on earth. The only detection mechanism was stumbling across it in the wild. CT closes that gap by making every issuance a public, auditable event.

How CT logs work: SCTs, Merkle trees, and log operators

CT logs use four actors to create a verifiable chain of accountability: the CA, the log operator, the browser, and the monitor. Here's how each step works:

• CA submits certificate: When a CA issues a certificate, it submits that cert (or a precertificate) to one or more CT logs
• Log stores in Merkle tree: Each log is an append-only Merkle tree—a data structure where every entry is cryptographically chained to the previous ones. You can prove a certificate exists without downloading the entire tree, and verify the log hasn't been tampered with by checking the tree's root hash
• Log returns SCT: The log returns a signed certificate timestamp (SCT)—a cryptographic promise that this certificate will appear in the log within the Maximum Merge Delay (typically 24 hours). The CA embeds the SCT in the certificate, or the server delivers it via a TLS extension during the handshake
• Browser verifies SCTs: The browser checks that the certificate comes with valid SCTs from recognized logs. No SCTs, no trust. According to Chrome's CT policy, certificates with validity periods over 180 days require SCTs from at least two independent log operators
• Monitor watches for your domains: The monitor's job is yours—watch the logs for certificates matching your domains

CA issues cert → submits to CT log(s) → log returns SCT
                                           ↓
                 cert embeds SCT ← ── ── ──┘
                                           ↓
         browser verifies SCT on TLS handshake
                                           ↓
         monitors watch log entries for your domains

Why certificate transparency matters for your infrastructure

CT monitoring reduces unauthorized certificate detection time from weeks or never to within hours. Without it, a certificate issued for your domain through a compromised CA or a misconfigured ACME client could sit in the wild unnoticed indefinitely. Google Chrome has enforced CT for all new publicly-trusted certificates since April 2018. Apple followed with mandatory CT enforcement on iOS and macOS in October 2018.

Detecting unauthorized certificate issuance

CT monitoring is the fastest mechanism for detecting misissued certificates for domains you own. CAA records and CT logs serve complementary but distinct roles:

• CAA records tell CAs who should issue certificates for your domain—but a compromised or non-compliant CA can ignore them
• CT logs tell you who did issue certificates—providing after-the-fact visibility that CAA alone cannot

The two work together, but only CT gives you detective capability after issuance has already occurred.

Compliance and browser requirements

Every major browser now mandates CT compliance for publicly-trusted certificates. The specific requirements differ by vendor:

• Google Chrome: Requires embedded SCTs from at least two logs run by different operators. Certificates without valid SCTs trigger a full-page interstitial warning
• Apple Safari (iOS and macOS): Requires SCTs from at least two logs, with at least one from a log that was temporally sharded at the time of issuance
• Android: Inherits Chrome's CT policy

If you're issuing publicly-trusted certificates, CT compliance is not optional.

Real-world incidents CT would have caught sooner

Three major incidents demonstrate why CT monitoring matters:

• CNNIC/MCS Holdings (2015): CNNIC's subordinate CA MCS Holdings issued unauthorized certificates for Google domains. Detection took days and relied on a Google engineer noticing via Chrome's certificate pinning. CT monitoring would have flagged the issuance within hours
• Symantec misissurance (2015–2017): Symantec issued over 30,000 certificates with validation failures. CT log analysis was a primary mechanism for surfacing the scope of the problem
• Let's Encrypt CAA bug (March 2020): Let's Encrypt revoked 3 million certificates due to a CAA checking bug. CT logs were the primary mechanism for identifying affected domains at scale

Detection method	Time to detect unauthorized cert	Covers private CAs	Preventive
CT monitoring	Hours (bounded by 24-hour MMD)	No	No
CAA records	N/A (preventive only)	No	Yes
Manual cert audit	Weeks to never	Yes	No
Certificate pinning	Connection-time	No	No

How to monitor certificate transparency logs

CT log monitoring means watching for any certificate issued for domains you control. For a handful of domains, free tools like crt.sh and Certspotter work well. After monitoring certificates across hundreds of environments, we've found clear scaling thresholds: past 50 domains, you need automation; past 200, you need filtering and deduplication or your on-call team will mute the alerts within a week. We've written a deeper walkthrough of CT log monitoring that covers specific tooling choices.

Using crt.sh and public CT search tools

crt.sh is the standard starting point for CT log searches. It's a free, Postgres-backed search engine maintained by Sectigo that indexes major CT logs. Key details:

• Search URL: Query https://crt.sh/?q=%.example.com to see every certificate ever logged for your domain and subdomains
• Scale: crt.sh processes over 500 million log entries and handles thousands of queries per hour
• JSON API: Available at crt.sh/?q=example.com&output=json for scripting, though rate limits apply
• Google's CT search: Available at transparencyreport.google.com/https/certificates as an alternative view
• Certspotter: SSLMate's Certspotter offers free CT monitoring for up to 5 domains with email alerts

Building automated CT monitoring with APIs

For production monitoring, you need a pipeline, not a browser tab. The architecture has four stages:

• Ingest: Subscribe to CT log streams via the get-entries API endpoint, or poll crt.sh's JSON API on a schedule
• Filter: Match entries against your domain inventory, drop irrelevant certificates
• Deduplicate: Handle precertificate/certificate pairs (the same cert appears twice in logs)
• Alert: Route to Slack, PagerDuty, or your incident management system

Performance benchmarks based on real-world deployments:

Approach	Latency	Best for	Infrastructure overhead
crt.sh polling (every 5–10 min)	15–30 minutes	Teams with under 100 domains	Minimal
RFC 6962 API streaming	Sub-hour detection	Teams with 100+ domains	Significant

Filtering noise: wildcards, precertificates, and deduplication

Every certificate submitted to a CT log appears at least twice: once as a precertificate (submitted before final issuance) and once as the final certificate. Naive monitoring scripts that don't deduplicate will double-alert on every issuance. Best practice: filter on the precertificate only, since it appears first and contains the same data.

Wildcard certificates create a different noise problem. A single *.example.com cert covers every subdomain, so your monitoring needs to recognize wildcards as covering your known subdomain inventory. Otherwise, you'll either miss wildcard-based coverage or generate false positives for subdomains already covered.

Certificate transparency at scale: managing 50–2,000+ certificates

CT logs at mid-market scale serve as a discovery tool, not just a monitoring feed. After running CT-based discovery scans across hundreds of enterprise environments, we consistently find that 10–15% of active certificates weren't in any inventory before the first scan. CT log search is the only mechanism that works across every CA, every cloud provider, and every environment simultaneously.

Inventory discovery via CT logs

Querying crt.sh for %.yourcompany.com returns every publicly-trusted certificate ever issued for your domains. This is your ground truth for certificate inventory. Cross-reference it against your certificate inventory across cloud accounts to find common gaps:

• Certificates issued by teams you didn't know had AWS accounts
• Staging environments running production domain certificates
• Vendors who issued certificates on your behalf without notifying you

Catching shadow IT and rogue certificates

Two scenarios we see regularly across enterprise CT monitoring deployments:

Unauthorized wildcard issuance: A platform team discovers via CT monitoring that someone on the frontend team requested a wildcard cert for *.staging.example.com through a personal Let's Encrypt account. The cert is valid and working, but nobody told platform engineering. Without CT monitoring, this cert would have existed invisibly until it expired and broke something.

Orphaned subdomain certificates: CT alerts reveal certificates for subdomains that were decommissioned months ago but still resolve in DNS. The subdomain is serving an expired certificate because nobody cleaned up the DNS record and the old cert wasn't in any renewal pipeline.

Integrating CT monitoring into your certificate lifecycle

CT monitoring fits into the broader certificate lifecycle as a verification layer. Your renewal automation handles expected certificates. CT monitoring catches everything else. The decision matrix by scale:

Certificate count	Recommended CT monitoring approach
Under 50	crt.sh or Certspotter alongside renewal tooling
50–500	Automated CT monitoring with filtering, plus a maintained inventory
500+	Certificate lifecycle management platform incorporating CT as one input alongside direct integrations with AWS ACM, Azure Key Vault, GCP Certificate Manager, and internal CAs

CertPulse pulls CT log data as part of its discovery pipeline, cross-referencing log entries against cloud provider inventories to flag certificates that exist in logs but aren't tracked in your system.

CT log architecture and ecosystem in 2026

As of early 2026, the CT ecosystem runs on approximately 30 active log shards operated by a small number of organizations. Chrome maintains the authoritative list of trusted logs, and certificates must include SCTs from logs on that list to be considered CT-compliant.

Active CT logs and operators

Operator	Log family	Shard period	Notes
Google	Argon, Xenon	Annual	Largest operator, runs approximately 50% of active shards
Cloudflare	Nimbus	Annual	Second largest, high availability
Let's Encrypt	Oak	Annual	Focused on their own issuance volume
Trust Asia	—	Annual	Regional operator
DigiCert	Yeti, Nessie	Annual	Also operates Symantec legacy logs

Chrome's CT policy and log sharding

Temporal sharding means each CT log only accepts certificates expiring within a specific time window. This design decision keeps individual log sizes manageable and allows operators to retire old shards. Key policy details:

• Chrome requires SCTs from logs that are "qualified" at the time of certificate issuance
• Logs can transition to "retired" or "read-only" status without invalidating existing SCTs
• Each shard covers a one-year window of certificate expiry dates

What's changing: Sunlight, Static CT, and RFC 6962-bis

Google's Sunlight project (also called Static CT) represents the most significant architectural change to CT since its inception. It replaces the dynamic Merkle tree API with static tile-based serving:

• Current model: Monitors query a live API for tree heads and proofs, requiring expensive always-on infrastructure
• Sunlight model: Monitors fetch pre-computed tiles from a CDN, reducing log operating costs significantly
• RFC 6962-bis: This draft specification formalizes several years of operational learnings—including precertificate handling and temporal sharding—into an updated standard

Both Sunlight and RFC 6962-bis are in active development, not speculative.

Common pitfalls and operational gotchas

CT monitoring has real limitations that the protocol's advocates tend to understate. Based on conversations with operations teams across the industry, roughly 40% of organizations had at least one blind spot in their CT monitoring setup when they first audited it. Understanding these pitfalls prevents false confidence.

CT is not real-time

The Maximum Merge Delay (MMD) gives a CT log up to 24 hours to incorporate a submitted certificate. In practice, most logs merge within 1–2 hours, but your monitoring architecture must account for the worst case. If your threat model requires real-time detection of unauthorized issuance, CT alone won't satisfy it. Pair it with:

• CAA records: Preventive control that tells CAs not to issue
• Certificate pinning or endpoint monitoring: Detective control at connection time

Precertificate vs. certificate confusion

A precertificate is a special certificate submitted to CT logs before the final cert is issued. It contains the same information as the final certificate but includes a poison extension (OID 1.3.6.1.4.1.11129.2.4.3) that prevents it from being used for TLS. Monitoring scripts that don't understand this distinction will either:

• Double-count every issuance event
• Miss certificates by deduplicating incorrectly and dropping the wrong entry

When CT monitoring creates false confidence

The biggest blind spot in CT monitoring: CT logs only cover publicly-trusted CAs. The following certificate types are completely invisible to CT monitoring:

• Certificates from internal PKI or private CAs
• Self-signed certificates used for service-to-service mTLS
• Certificates issued by CAs not in browser trust stores

A compromised internal CA issuing rogue certificates will never appear in any CT log. CT monitoring is necessary but not sufficient—it's one layer in a defense-in-depth approach to certificate management, and treating it as the whole picture is how things get missed.

Frequently asked questions

What is a signed certificate timestamp (SCT) and why does it matter? A signed certificate timestamp (SCT) is a cryptographic receipt from a CT log proving that a certificate has been submitted for logging. Browsers require valid SCTs before trusting a certificate. Without SCTs, Chrome displays a full-page warning and the TLS connection fails.

Can CT logs detect certificates issued by private CAs? No. CT logs only contain certificates from publicly-trusted CAs that participate in the CT ecosystem. Certificates from private CAs, internal PKI systems, or self-signed certificates are invisible to CT monitoring. You need separate tooling for internal certificate visibility.

How quickly will a new certificate appear in CT log search results? Most certificates appear in CT log search tools like crt.sh within 1–3 hours of issuance. The CT protocol allows up to 24 hours (the maximum merge delay), but in practice, major logs merge much faster. Indexing by search tools like crt.sh adds additional lag of minutes to an hour.

Is CT monitoring a replacement for CAA records? No. CAA records and CT monitoring are complementary controls. CAA records are preventive—they tell CAs not to issue for your domain. CT monitoring is detective—it tells you when issuance happened. A compliant CA respects CAA, but a compromised or misconfigured CA might not. You need both for effective certificate security.

How do I check if unauthorized certificates exist for my domain? Query crt.sh/?q=%.yourdomain.com to see every publicly-logged certificate for your domain and subdomains. Compare the results against your known certificate inventory. Any certificate you don't recognize warrants investigation. For ongoing monitoring, set up automated alerts using SSLMate's Certspotter or build a CT monitoring pipeline using the RFC 6962 API.