Certificate Transparency Monitoring in the Static CT Era

Certificate Transparency (CT) is a public, always-on record of the TLS certificates issued for websites. Watching those public logs, known as Certificate Transparency monitoring, is how security teams spot certificates issued for their domains that they never requested or approved. Two things changed in 2026 that affect how this works. A new browser rule now tightens how and where certificates must be logged, and the logs themselves have been redesigned to be faster and cheaper to run.

Together, these shifts mean the tools and habits many teams built for CT monitoring need a refresh. This blog walks through what changed, why it matters, and how to build a monitoring approach that holds up in 2026 and beyond. We start from the basics, so you do not need to be a CT expert to follow along.

What Certificate Transparency Is and Why It Matters

Certificate Transparency is a public logging system for TLS certificates. Every time a Certificate Authority issues a certificate, it logs that certificate in a public, append-only ledger. Anyone can read these logs, and that openness is what makes it possible to spot certificates that should not exist.

Before CT existed, a compromised or misbehaving CA could quietly issue a certificate for any domain, and no one outside that CA would know. In 2011, attackers compromised the Dutch CA DigiNotar and issued hundreds of fraudulent certificates, including a wildcard certificate for *.google.com. At the time, there was no publicly auditable record of certificate issuance, making it difficult for domain owners and browser vendors to detect unauthorized or mis-issued certificates promptly. CT was designed to close that gap.

For security teams today, CT delivers several practical capabilities. It lets you detect certificates issued for your domains without your knowledge, catch CA mis-issuance before it causes harm, map your organization’s external certificate footprint, including forgotten subdomains, and produce audit evidence for compliance programs that require certificate issuance oversight.

The protocol is standardized in RFC 6962 and its successor RFC 9162, though browsers in practice still implement RFC 6962. Browsers, including Chrome and Safari, require certificates to carry a Signed Certificate Timestamp (SCT), which is the log’s cryptographic proof that the certificate was recorded. A certificate without a valid SCT from a recognized log is rejected.

What Chrome’s June 2026 Mandate Changed

Chrome has enforced CT for extended-validation certificates since 2015 and for most public certificates since 2018. The June 15, 2026 update to the Google Chrome Root Program Policy (version 1.8) strengthens Certificate Transparency and PKI governance requirements across all publicly trusted certificate types.

CA owners must log every TLS server-authentication precertificate to at least one CT log Chrome recognizes as “Usable” or “Qualified” before issuing the certificate. The exact number of required SCTs varies with the certificate’s validity period. Chrome requires two SCTs for certificates valid less than 180 days and three for those valid 180 days or longer. Either way, the underlying requirement stays the same, namely independent verification from more than one log operator.

Chrome evaluates each certificate against a defined set of log states. A log can be in one of four states that matter for compliance.

• Qualified: Newly accepted by Chrome, and its SCTs already count toward CT compliance.
• Usable: Fully recognized and accepting new submissions, so SCTs count whether embedded or delivered via the TLS handshake.
• ReadOnly: It no longer accepts new certificates (its final tree size is published) but remains trusted, so existing SCTs still count.
• Retired: No longer relied on for new SCTs, and only embedded SCTs issued before the retirement timestamp still count.

SCTs from logs that are not in a recognized good state do not count toward compliance. Certificates submitted to logs that subsequently fall out of good standing can therefore lose their CT compliance status even after issuance. Chrome 148, released May 5, 2026, also removed support for SCTs delivered via stapled OCSP responses, meaning SCTs must now be embedded in the certificate itself or delivered via the TLS handshake extension. Any deployment relying on OCSP-stapled SCTs should be reissued.

Certificates that previously relied on legacy Certificate Transparency exceptions or outdated SCT delivery mechanisms should be reviewed to ensure they continue to satisfy Chrome’s current CT policy. The mandate also strengthens the case for continuous CT monitoring, because every mis-issued certificate must now appear in a public log, making those logs a more reliable source of threat intelligence than at any prior point.

Why the Older RFC 6962 Log Design Struggled at Scale

The original CT log design in RFC 6962 works like a classic database-backed API service. When a CA submits a certificate, the log stores it in a database, updates a Merkle hash tree to cryptographically commit to the new entry, and returns an SCT. Monitors and auditors then query the log through REST API endpoints to retrieve entries and verify consistency.

This design worked well when certificate volumes were manageable. The Web PKI has grown far beyond that point. Individual CT logs now hold billions of entries per temporal shard (a time-sliced segment of a log that only holds certificates expiring within a fixed window), and the database behind each log became a bottleneck. When monitors tried to read large volumes of entries quickly, they frequently overloaded the read path. Log operators responded with rate limits, which slowed monitoring and undermined CT’s value as a near-real-time detection mechanism.

The 24-hour Maximum Merge Delay guarantee was also repeatedly at risk. Under RFC 6962, a log can return an SCT immediately and then has up to 24 hours to actually include the certificate in its Merkle tree. During high-load periods, logs came close to missing that window, creating situations where the SCT promise could not be reliably honored. These challenges made it clear that the architecture needed to change.

How the Static CT API and Sunlight Work

The Static CT API takes a fundamentally different approach. Instead of answering queries from a live database, a Static CT log publishes all its data as a hierarchy of static files called tiles. These tiles are served from object storage such as S3 or from a CDN. No server-side computation is needed for the read path, which is the source of its efficiency gains.

The Sunlight implementation, developed by Filippo Valsorda in collaboration with Let’s Encrypt, is the most widely deployed realization of this specification. Because the read path is just static files, it can be served entirely from a CDN, so monitors fetch cacheable tiles instead of repeatedly querying a live database. That removes the read-path bottleneck that throttled monitoring under RFC 6962 and sharply reduces the bandwidth and compute a log operator must provision.

The write path also improved. Sunlight batches submissions and integrates them into the Merkle tree before returning an SCT. This eliminates the Maximum Merge Delay entirely. An SCT is not issued until the certificate is committed to the tree, so the promise the SCT makes is always already fulfilled.

The log is structured as tiles of 256 entries each. Each tile is a static file written to object storage or a local filesystem. The log is temporally sharded, so each shard accepts only certificates whose NotAfter date falls within a specific window, typically six months. This bounds shard size and keeps storage manageable.

Let’s Encrypt transitioned its RFC 6962 logs to read-only on November 30, 2025 and shut them down entirely on February 28, 2026. Their production CT logs now run on Sunlight, with Sycamore and Willow as the primary production logs. Google’s TrustFabric team released TesseraCT, a Static CT API implementation that offers an alternative to the Trillian-based CTFE powering many older logs. The ecosystem has moved decisively to this architecture.

How CT Monitoring Works Now

How you collect entries depends on the log type. The two subsections below cover monitoring against legacy RFC 6962 logs and against the newer Static CT logs.

Monitoring Against RFC 6962 Logs

With an RFC 6962 log, a monitor calls the get-entries endpoint with a start and end index, retrieves batches of certificates, and advances its position as new entries arrive. The log serves entries from a database and returns the full certificate chain with each entry, making CA attribution straightforward.

Monitoring Against Static CT Logs

With a Static CT log, a monitor downloads data tiles directly. Each tile contains 256 entries. The monitor fetches each tile it has not yet seen, processes the entries, and uses the log’s signed checkpoint file to track the current tree size. Tiles are static and served from object storage, so monitors can fetch them in parallel without hitting rate limits.

One practical difference is chain handling. RFC 6962 logs returned a full certificate chain per entry. Static CT logs do not attach a chain to each entry. Instead the log publishes an issuer’s bundle containing the intermediate certificates it has accepted. Monitors that need to reconstruct a full chain for CA attribution must build it from this bundle. This adds complexity to the monitor but is a deliberate trade-off that keeps per-entry data compact and the bandwidth reduction significant.

From a monitoring strategy perspective, the categories worth tracking remain consistent regardless of log type.

• New certificates issued for domains you own, including wildcard matches.
• Certificates from CAs your organization has not authorized.
• Certificates with validity periods outside your policy.
• Certificates revealing subdomains you do not recognize.

These four categories produce the majority of most actionable events.

Tools Available for CT Monitoring

Monitoring CT logs is only half the job; the payoff comes from acting on what you find. That is where Encryption Consulting’s CertSecure Manager comes in. It is a platform that combines CT log monitoring with full certificate lifecycle management (CLM). It continuously scans CT logs for certificates issued against your domains and checks each one against your inventory of approved certificates. So, your team can investigate and remediate findings from a single console instead of piecing together separate search and alerting tools.

Certstream provides a real-time WebSocket feed of CT log entries across all active logs. Security teams use it to build filtering and alerting pipelines that notify teams shortly after a matching certificate appears in Certificate Transparency logs.

Google maintains a current list of recognized CT monitoring services at certificate.transparency.dev. For teams building custom monitors, the C2SP static-ct-api specification is the complete technical reference for tile format and checkpoint structure.

Whichever tool your team uses, the output is a stream of certificate events that need to be sorted and reviewed. Alert design and integration with your incident response process matter as much as the ingestion pipeline itself. These tools handle ingestion; correlating events against your inventory of authorized certificates and acting on them is where a CLM platform comes in.

Threat Patterns Worth Monitoring

Raw CT data is not useful on its own. Effective monitoring means knowing which patterns indicate a real problem.

Unauthorized Certificate Issuance: A certificate is issued for your domain by a CA you have no relationship with. This can indicate a domain validation bypass, a compromised CA, or an attacker with sufficient DNS control to pass automated domain validation. Detecting this quickly was the original purpose CT was designed for.

Shadow Certificates: Certificates issued for infrastructure your organization operates but does not manage centrally. Development teams using personal CA accounts and certificates issued for unmanaged public-facing subdomains or infrastructure outside approved PKI processes are the most common examples. Shadow certificates create both a security gap and a compliance exposure.

Subdomain Exposure: Every subdomain in a certificate is publicly searchable the moment the certificate is logged. Staging environments, internal tools, and pre-launch products become discoverable as soon as they receive a certificate. Monitoring your own domains in CT gives you visibility into this exposure before an attacker has it.

Mis-issuance Indicators: Certificates with unexpected Subject Alternative Names (SANs), unexpected issuers, unusual Extended Key Usage (EKU) values, or anomalous certificate fields can indicate a CA policy error or deliberate manipulation. Automated field parsing at scale makes it feasible to flag these reliably.

Phishing and Typo Squatting Infrastructure: Attackers regularly obtain certificates for domains that visually resemble a target organization’s name. Monitoring CT for close matches and common substitution patterns gives early warning of phishing infrastructure being assembled.

Spotting these patterns in raw CT data is one thing. Acting on them quickly, across every domain you own, is another. Closing that gap is the job of a CLM platform, which turns a stream of CT alerts into prioritized work your team can track and resolve.

How Encryption Consulting Can Help

Certificate Transparency monitoring is most valuable when it connects to a CLM Platform that can act on what the logs surface. Seeing an unauthorized certificate in a CT log is only useful if your team knows which CA issued it, whether it was requested through an approved process, and how quickly it can be revoked and replaced. Without a CLM platform providing that context, CT alerts produce noise rather than action.

Encryption Consulting’s CertSecure Manager is a vendor-neutral CLM platform designed to give security and PKI teams complete visibility and control over their certificate environment. It automatically discovers and inventories certificates across cloud, on-premises, and hybrid environments, so your team always knows what exists and where. When a CT alert fires for a certificate already in the inventory, it can be correlated and acknowledged automatically. When it fires for something unknown, CertSecure Manager surfaces it as an immediate investigation item with full issuer and deployment context.

Beyond discovery, CertSecure Manager automates the full certificate lifecycle from enrollment and issuance to renewal and revocation. It enforces policy-based issuance across both public and private CAs, integrates with DevOps workflows and protocols like ACME and SCEP, and provides the audit logging that compliance frameworks including PCI DSS, ISO 27001, and NIST guidance require. For organizations responding to the Chrome June 2026 mandate, this means you can identify exactly which certificates need to be reissued, route them through the correct CA, and confirm CT compliance without manual tracking.

Encryption Consulting also offers PKI-as-a-Service for organizations that need a fully managed private CA, and PQC advisory services. The same crypto-agility that shorter certificate lifetimes and CT automation now demand is what organizations will lean on for the move to NIST’s post-quantum standards (FIPS 203, 204, and 205, finalized in August 2024). As certificate lifetimes continue to shorten and automation becomes the norm, having both the tooling and the expertise in place is what separates teams that stay in control from those left scrambling to react.

Conclusion

Certificate Transparency turns every publicly trusted certificate into a public record, and watching that record is one of the simplest ways to catch certificates issued for your domains without your approval. It only works, though, if someone is actually monitoring the logs and acting on what shows up.

Two things changed in 2026. Chrome now requires almost every certificate to be logged, and the logs themselves moved to the faster, cheaper Static CT API design. Together they make CT data more complete and easier to work with, but they also mean monitoring built for the old model needs a refresh. The teams that get the most from it treat CT monitoring not as a standalone alert feed, but as part of a wider CLM platform that can investigate and act on what it finds.