What is certificate transparency?

What is Certificate Transparency?#

Certificate Transparency (CT) is a set of standards and infrastructure that make certificate issuance publicly auditable. When a publicly trusted Certificate Authority (CA) issues a certificate, it must be logged to one or more CT logs, which are append-only, Merkle-tree based structures that anyone can read. Browsers can then verify that a certificate was logged before trusting it.

CT applies to the Web PKI (the public key infrastructure behind browser-trusted certificates), the system of publicly trusted certificates used for HTTPS and other TLS services. Private or enterprise CAs that are not in browser trust stores do not log to CT, and their certificates will not appear in public CT logs.

Origins in the rogue certificate problem#

Certificate Transparency was not designed to be a threat intelligence tool. Its original purpose was much narrower, focused on detecting rogue or mis-issued certificates.

The motivation came from a series of CA compromises in 2011. In March of that year, attackers compromised Comodo's registration authority and obtained fraudulent certificates for domains including google.com, yahoo.com, and skype.com. Months later, the Dutch certificate authority DigiNotar suffered a far worse breach. Attackers gained control of all eight of DigiNotar's certificate-issuing servers and issued at least 531 rogue certificates, including a wildcard certificate for *.google.com that was used to intercept Gmail traffic in Iran. DigiNotar went bankrupt within weeks. When browsers revoked DigiNotar's root certificates, they inadvertently broke Dutch government services that depended on the same CA for their public key infrastructure.

These incidents demonstrated a fundamental weakness in the CA system. There was no reliable way to know when a CA had issued a certificate it should not have. Google began work on Certificate Transparency in late 2011 to address this gap. The resulting protocol, published in June 2013, established a system of public logs where certificates are recorded so that domain owners, browsers, and researchers can detect mis-issuance.

From audit tool to intelligence source#

While CT was built to catch CA misbehavior, its value quickly extended beyond that original scope. Because every publicly trusted certificate is logged with its full subject name (including domain names and subdomains), CT logs became one of the largest continuously updated records of domain activity on the internet.

Security researchers and organizations began mining CT logs not for evidence of rogue CAs, but for intelligence about newly registered domains and subdomains. A certificate logged for paypa1-secure-login.com is not a CA trust failure; it is a legitimately issued certificate for a lookalike domain. But the CT log entry still reveals that someone registered that domain and is preparing to serve HTTPS traffic from it, often shortly before launching a phishing campaign.

This made CT logs an important early-warning signal for brand abuse. Platforms like Have I Been Squatted monitor CT logs to detect certificates issued for domains that match typosquatting permutations, providing visibility into attacks at the infrastructure stage rather than after victims are targeted. CT is particularly valuable for detecting adversary-in-the-middle phishing infrastructure, because adversary-in-the-middle (AiTM) frameworks like Evilginx automatically provision certificates for attacker-controlled domains, leaving a trail in CT logs before the first phishing email is sent.

CT logs also became a tool for subdomain discovery. Organizations that issue individual certificates for internal services (staging environments, development servers, internal APIs) inadvertently expose those hostnames in public CT logs. Penetration testers and attackers alike use CT log data to map infrastructure that was never intended to be publicly known.

The wildcard visibility gap#

There is a significant limitation to CT-based subdomain enumeration. Wildcard certificates create a blind spot. A certificate issued for *.example.com appears in CT logs as a single entry. It does not reveal which specific subdomains exist beneath example.com. An organization using a wildcard certificate for staging.example.com, internal-api.example.com, and dev.example.com exposes none of those hostnames through CT.

In TLS, wildcard subject names match only one label directly under the parent name. A certificate for *.example.com can cover staging.example.com, but it cannot cover a deeper name such as internal.api.example.com. That hostname requires its own certificate, or a separate wildcard scoped to the next level (for example *.api.example.com), subject to CA policy.

This means that organizations relying heavily on wildcard certificates produce a much smaller CT footprint, and monitors have no visibility into the subdomains being served. From a defensive standpoint, wildcard certificates offer a degree of infrastructure privacy. From an intelligence standpoint, they represent a blind spot. Any monitoring strategy that depends on CT for subdomain awareness should account for this gap.

Let's Encrypt and the certificate explosion#

The volume of certificates flowing through CT logs increased dramatically with the rise of Let's Encrypt, the free, automated CA launched in 2015. By removing cost and manual processes from certificate issuance, Let's Encrypt changed the scale of the entire Web PKI.

The growth has been substantial. Let's Encrypt issued its one millionth certificate in March 2016. By September 2018, it was issuing one million certificates per day. By late 2025, that number had reached ten million certificates per day, with over 550 million websites protected. The CA is on track to serve one billion active sites.

This growth has had a dual effect on CT. On one hand, the sheer volume of logged certificates made CT an even richer data source for threat intelligence, because attackers overwhelmingly use free CAs to provision certificates for phishing domains. On the other hand, the flood of certificates created serious operational pressure on the CT log infrastructure itself.

Certificate lifetimes are also shrinking. One reason is that certificate revocation has largely not worked as a dependable, real-time control at web scale. The Online Certificate Status Protocol (OCSP) and certificate revocation lists (CRLs) are easy to skip or soft-fail, and strict hard-fail behavior is risky when revocation infrastructure is slow or unavailable, so the ecosystem cannot assume a revoked certificate stops working immediately everywhere. Shorter maximum lifetimes cap how long a mis-issued or compromised certificate can remain valid without relying on that model.

The CA/Browser Forum voted in 2025 to reduce maximum certificate lifetimes to 47 days by 2029. Let's Encrypt has already begun transitioning from 90-day to 45-day certificates, which will roughly double the volume of renewal-related certificate issuance. As maximum lifetimes move from months toward weeks, and under some policies toward only a few days, manual renewal stops scaling for most operators, so automated issuance and deployment effectively become mandatory.

That shift is largely a security improvement, because credentials go stale quickly. It also means more certificates are issued and logged over any given period, which adds to the volume pressure on CT logs and on anyone running full log monitors.

Scaling problems in CT logs#

The original CT log architecture was designed for a much smaller certificate ecosystem. Each log stores certificates in a relational database, and monitors read those databases continuously to stay current. As issuance grew, this architecture began to strain.

Let's Encrypt's "Oak" CT log, one of the most widely used, grew to hold over 700 million entries per shard, with individual shards reaching 7 to 10 terabytes. Scaling read capacity required increasingly expensive database instances. During testing, Let's Encrypt encountered MySQL's 16 TiB storage limit. Annual cloud costs for operating these logs approached seven figures.

Performance problems followed. When monitors attempted to read all log data (which is the entire point of CT), they could overload log databases, forcing operators to impose rate limits. Multiple logs exceeded their "Maximum Merge Delay", a compliance metric that measures how quickly submitted certificates appear in the log. These failures undermine the timeliness that makes CT monitoring useful.

A new architecture with tiles and the Static CT API#

To address these scaling challenges, Let's Encrypt developed "Sunlight", a new CT log implementation that replaces the database-backed read path with a tile-based architecture. Instead of serving certificate data from database queries, Sunlight publishes logs as a hierarchy of static files (tiles) that can be served from object storage or a content delivery network (CDN) with minimal server-side computation.

The design moves expensive operations from the server to the client. Monitors download tiles and reconstruct the log locally rather than querying a centralized database. This approach eliminates the database bottleneck and makes CT logs far cheaper to operate and more resilient to heavy read traffic.

The tile format was standardized and is now recognized by major browser CT log policies. Let's Encrypt transitioned its older CT logs to read-only on November 30, 2025, and shut them down entirely on February 28, 2026, writing only to Static CT API logs going forward. Other operators, including Cloudflare, have built compatible implementations.

Detection, monitoring, and prevention#

CT monitoring is most effective when combined with other signals. Integrating CT alerts with domain monitoring allows certificate issuance to be correlated with registration and DNS activity. A certificate appearing for a domain that was registered the same day, resolves to a hosting provider commonly used for phishing, and matches a brand permutation pattern is a stronger signal than any of those data points alone.

Organizations should also maintain an internal certificate inventory and, where applicable, CA Authorization (CAA) DNS records to restrict which CAs can issue certificates for their domains. When CT monitoring surfaces confirmed abuse, the response typically involves takedown workflows and coordination with the issuing CA for revocation.