Certificate Transparency: Monitoring CT Logs in 2026

What Certificate Transparency Is and the Problem It Solves

Certificate Transparency (CT) is an open standard initiated by Google in 2013 and specified in RFC 6962 (RFC Editor). The core idea: every certificate authority (CA) submits every issued certificate to several public, tamper-resistant logs. These logs are visible and searchable by anyone — through public interfaces or through the monitoring of security services. This makes the web PKI trust model, which had been an opaque black box for years, auditable.

The problem CT solves is real and expensive. Before CT, a compromised or sloppy CA could issue certificates for arbitrary domains without the actual domain owner ever finding out. The most famous case: in 2011, the Dutch CA DigiNotar was fully taken over. Attackers controlled all eight certificate-issuing servers and produced at least 531 rogue certificates (Black Tulip report), including a wildcard certificate for *.google.com used in a man-in-the-middle attack against roughly 300,000 users in Iran (Wikipedia/Fox-IT). DigiNotar was bankrupt a few weeks later.

Even large, established providers are not immune. Through the Certificate Transparency program, Google uncovered between 2015 and 2017 that Symantec had issued up to 30,000 certificates over the years without proper validation (The SSL Store/Google). The consequence: Chrome and other browsers gradually withdrew trust from the affected certificates — a process that would never have come to light without the public visibility of the CT logs.

How a CT Log Works Technically

A CT log is a single, ever-growing, append-only data structure — technically a Merkle tree whose nodes are labelled with cryptographic SHA-256 hashes of their child nodes (RFC Editor). Certificates can only be added, never deleted, modified, or retroactively inserted. Violations of this append-only property can be detected by comparing the signed tree heads across independent observers.

When a CA submits a valid certificate, the log must immediately return a Signed Certificate Timestamp (SCT) — the promise to incorporate the certificate into the tree within a fixed period, the Maximum Merge Delay (typically 24 hours) (RFC Editor). This SCT is embedded into the certificate and checked by the browser. Proof that a certificate is actually contained in the log can be produced efficiently in logarithmic time (RFC Editor) — even with billions of entries.

The distinction between a certificate and a precertificate matters here. So that the SCT can be embedded into the certificate at the moment of issuance, the CA first submits a special preliminary version — the precertificate — to the logs and receives the SCTs in return. Only afterwards does the final, delivered certificate with embedded SCTs come into being. From a monitoring perspective this is relevant because both precertificates and final certificates appear in the logs: one and the same issuance can become visible in several entries, which good monitoring consolidates rather than reporting as separate incidents. The original log architecture from RFC 6962 is also currently being replaced by a more efficient, tiled structure (Static CT API) (RFC Editor) — for domain owners, the principle of public auditability remains unchanged.

Why CT Logs Are Now Mandatory for Browsers

Certificate Transparency is long past being optional. Since July 24, 2018, Google has enforced CT in Chrome 68 and above: all publicly trusted TLS certificates issued after April 2018 must be CT-compliant to validate successfully (IDManagement.gov/Google). A few months later, on October 15, 2018, Apple followed suit and has since required at least two SCTs from recognized CT logs (DigiCert/Apple).

Apple's policy scales the number of required SCTs by the certificate's lifetime: certificates valid for less than 15 months need two SCTs, 15 to 27 months need three, 27 to 39 months need four, and anything beyond that needs five (Apple/Entrust). In practice this means: a certificate not present in the CT logs simply does not work in modern browsers. Your domain is therefore already represented in these logs whether you actively watch them or not — the only question is whether you are reading along, or only potential attackers.

Which Threats CT Log Monitoring Reveals

The real security gain comes not from CT alone, but from actively watching the logs. Without monitoring, the data is public but no one looks. With monitoring, the few entries that concern your domain are filtered out of the 17 billion — and from those, the ones you did not request yourself.

The phishing aspect in particular is severe. According to the Anti-Phishing Working Group, 84% of phishing sites already used a valid SSL certificate with a padlock icon — an increase of roughly 26 percentage points over the first quarter of 2019 (58%) (APWG, Q4 2020). The availability of free, domain-validated certificates has fuelled this trend: Let's Encrypt alone issues up to ten million certificates per day at times in late 2025 (Let's Encrypt). The padlock alone says nothing about a site's trustworthiness today — but the CT log does reveal who is issuing certificates for your brand.

The historic major incidents illustrate why exactly this visibility is so valuable. In the 2011 DigiNotar hack, the compromise was only uncovered through certificate pinning in Chrome — that is, through a client-side control, because systematic log monitoring did not yet exist back then (Slate/Wikipedia). In the Symantec case it was the other way round: the Certificate Transparency program itself made the mis-issuances visible (The SSL Store/Google). The lesson for any brand today: those who watch their own domains in the logs do not depend on a browser vendor or an external researcher noticing the problem by chance. This shortens the gap between issuance and discovery from weeks or months to minutes — and it is precisely this gap that determines how much damage a rogue certificate can do.

Legitimate vs. Unexpected Certificate: The Distinction

The heart of CT monitoring is a classification: is a newly appeared certificate expected or not? A well-configured monitor compares every new log entry for your domain against a set of criteria, distinguishing between normal operation and a suspected incident — without flooding you with false alarms on every routine renewal.

• Issuing CA: Does the certificate come from a CA you actually use and that your CAA record permits? A foreign CA is a warning sign.
• Common Name and SAN: Does the registered domain name match your known (sub)domains? A subdomain you never requested suggests shadow IT or compromise.
• Typo variants: Was a certificate issued for a domain strikingly similar to your name? That is a classic lookalike/phishing pattern.
• Timing: Does the issuance align with a planned rollout or an automatic renewal — or does it come out of nowhere?
• Number and origin of SCTs: Does the certificate meet browser requirements, or does the logging appear manipulated?

CT Monitoring Combined With Other Security Signals

CT log monitoring reaches its full value only in concert with the other pillars of website security. A rogue certificate is rarely an isolated incident — it is often the first visible step of an attack chain that also surfaces elsewhere. Those who correlate multiple signals detect attacks earlier and with fewer false alarms.

Email authentication belongs in this picture too. Anyone setting up a phishing domain with a valid certificate often tries, in the same move, to send emails in your brand's name. Evaluating DMARC reports makes such abuse attempts visible and complements CT monitoring with the mail perspective. The result is a situational picture that considers domain, certificate, DNS, and email together.

Setting Up CT Monitoring in Practice: Step by Step

Getting started with CT monitoring is straightforward, because the data already exists — you only need to observe it systematically and filter it sensibly. A structured approach prevents you from drowning in false alarms or, conversely, missing genuine incidents.

1. Build a domain inventory: Capture all domains and subdomains belonging to your organization — including rarely used and historical names. You can only classify as legitimate what you know about.
2. Define permitted CAs: Determine which certificate authorities you use and record this consistently in your CAA records.
3. Derive typo variants: Collect plausible lookalike domains of your brand so that phishing certificates stand out.
4. Watch the logs continuously: Have the public CT logs searched automatically for your domains and variants — new entries often appear within seconds of issuance.
5. Set up alerting: Connect every unexpected finding to an immediate notification via email, Slack, Discord, or Telegram.
6. Define a response plan: Decide in advance who examines a suspicious certificate, when a revocation is requested, and how a potential data breach under Art. 33 GDPR is handled.

A common stumbling block in practice is the handling of wildcard certificates. An entry for *.your-domain.com covers any number of subdomains without each one appearing as a separate certificate in the logs. That is convenient but can obscure shadow IT: anyone using a wildcard should additionally monitor which subdomains are actually active rather than relying on the CT entries alone. A second typical mistake is an incomplete domain list — especially with acquisitions, campaign domains, or expired projects, names that are still registered to the organization fall into oblivion. These forgotten domains are precisely a preferred target for takeovers. A living, regularly maintained inventory is therefore the basic prerequisite for the distinction between expected and unexpected to work reliably at all.

Economic Consequences and Compliance Context

The cost of an undetected certificate problem is substantial. A single telecommunications company caused an outage through an expired certificate that affected 32 million customers in 11 countries and involved billions in remediation-related follow-up costs (Red Sift/Sectigo). Industry-wide, 88% of companies report an unplanned outage due to an expired certificate in the past two years (Red Sift). While these figures concern expired certificates, they illustrate the operational weight of the entire certificate lifecycle — and CT monitoring is the upstream detection layer for its issuance phase.

Shadow IT plays directly into this too: according to Gartner, around 41% of employees acquire technology their IT department is unaware of (Gartner). A subdomain set up on someone's own initiative with its own certificate is a typical example — and reliably appears in the CT logs long before IT notices it by other means. This matters for compliance: being able to demonstrate oversight of all certificates for your domains fulfils one component of the “appropriate technical and organizational measures” that the GDPR demands.

The German context reinforces this. The BSI addresses the secure use of TLS in its technical guideline TR-02102-2 (BSI), whose current version is 2026-01. With the NIS2 Implementation Act taking effect on December 6, 2025, minimum standards also gain a new legal basis in Section 44 BSIG (BSI). Complete visibility into your own certificates is therefore not just good practice but increasingly a regulatory expectation.

Trust Through Transparency: CT as Part of Your Security Strategy

Certificate Transparency has transformed the web PKI from an opaque trust system into an auditable infrastructure. But transparency only helps if someone looks. The public logs are a vast, freely accessible trove of data — yet at roughly 121.6 million new certificates per day (Cloudflare Radar, Certificate Transparency) impossible to evaluate manually. This is exactly where automated monitoring comes in: it reduces the billions of entries to the handful relevant to your domain.

The XICTRAQ Security Scan watches the Certificate Transparency logs for your domains and subdomains. If a certificate from an unexpected CA, for a subdomain you never requested, or for a typo variant of your name appears, you receive a prompt notification — combinable with monitoring the expiry dates, certificate chain, and configuration of your active certificates. This turns the raw transparency of the CT logs into a concrete, actionable early-warning mechanism for your brand.

Frequently Asked Questions About Certificate Transparency