Wiki · Concept · Last reviewed July 10, 2026

Certificate Transparency

Certificate Transparency is the public logging layer for TLS certificate issuance: an audit system that helps domain owners, browsers, monitors, and researchers notice when a certificate authority issues something suspicious.

Category: Concept Published: June 25, 2026 Modified: July 10, 2026 Last reviewed: July 10, 2026 Tags: Web PKI, TLS, transparency logs, browser trust, AI agents, governance

Snapshot

Definition

Certificate Transparency, usually shortened to CT, is a system for publicly logging the existence of Transport Layer Security certificates as they are issued or observed. The log is an accountability layer for the Web Public Key Infrastructure: certificate authorities can make mistakes or be compromised, and the rest of the web needs a way to see certificate issuance instead of treating it as a private transaction between a domain and a CA.

RFC 6962 described the original experimental protocol in 2013, and RFC 9162 later described CT version 2.0. Current deployment is also shaped by browser policy, log-operator policy, and newer log-access mechanisms such as Static CT API. The stable idea is narrower than "web trust": CT makes issuance monitorable. It does not decide whether the site is safe, whether the domain owner authorized the certificate correctly, or whether a user or agent should perform a consequential action.

The official CT project describes the system as an ecosystem for detecting maliciously or mistakenly issued certificates and making website-certificate issuance transparent and verifiable. CT does not abolish certificate authorities. It gives domain owners, monitors, browsers, and the wider public a shared evidence trail for asking what those authorities have issued.

How It Works

A CT log is an append-only, publicly auditable ledger of certificates. The project site describes current usable logs in those terms, and the RFCs describe logs as network services that accept certificate submissions and answer queries. In the usual public-web flow, a certificate authority submits a certificate or precertificate to one or more logs. A log returns a signed certificate timestamp, often called an SCT, which is evidence that the log has promised to include the certificate.

The SCT is not the whole audit. Monitors watch logs for new entries. Auditors and relying software can check that a certificate was included and that the log remains consistent over time. A domain owner can monitor for unexpected certificates involving its names. A browser or other user agent can apply a policy that requires certificates to carry CT evidence.

Chrome's Certificate Transparency project says Chrome maintains CT policy, CT log policy, and CT log-list policy, and states that publicly trusted TLS certificates issued after April 30, 2018 must support CT to be recognized as valid in Chrome.

That division matters. CT is not a secret scanner and not a revocation system. It is a visibility system. If a bad certificate appears, the log helps affected parties notice it, prove it was issued, and take action through browser root programs, certificate-authority processes, incident handling, revocation, or public disclosure.

Current Context

As of July 10, 2026, CT is mature Web PKI infrastructure rather than a research curiosity. Browser policy makes CT evidence a practical requirement for public TLS certificates, public logs are watched by monitors, and certificate authorities routinely submit certificates to logs as part of issuance.

The operational details are still changing. The Chrome CT project describes policies for Chrome's CT requirements, log eligibility, and log lists; the broader ecosystem has been moving from the older RFC 6962 HTTP log API toward Static CT API and tiled logs for more efficient monitoring and distribution. Let's Encrypt's June 15, 2026 documentation says it currently operates Static CT API logs based on Sunlight, identifies Sycamore and Willow as production logs, and points to an end-of-life plan for its former RFC 6962 logs.

The lesson for governance is version discipline. "CT compliant" can refer to a browser policy, a log list, an RFC protocol, an SCT embedded in a certificate, a monitor alert, or a specific log operator's availability and inclusion behavior. A safety or incident report should say which layer was checked and on what date.

Boundary Tests

AI Agent Context

AI agents and AI browsers inherit the Web PKI. A browsing agent that signs in to services, calls APIs, downloads packages, checks model registries, or visits tool endpoints is only as grounded as the transport identities it accepts. CT gives that agent ecosystem one important external check: whether a public certificate for a domain entered a public log and whether monitors can see suspicious issuance.

This is especially relevant when agents act at scale. A compromised certificate for a package host, model mirror, extension site, payment endpoint, or internal-looking domain can become an invisible routing event for automated workflows. CT monitoring cannot decide whether an agent should trust a site, but it can supply audit evidence when a certificate appears outside the expected issuance path.

For agent-native internet systems, CT evidence should sit beside agent identity, signed automated traffic, agent sandboxing, and audit trails. One layer answers "was a public certificate issued for this name?" Other layers answer who the agent is, what it was allowed to do, what it actually did, and who can contest the result.

Governance Use

A governance-grade CT workflow should record the domain name, certificate serial number or fingerprint, issuing certificate authority, SCT evidence, log identity, discovery time, monitor source, policy decision, and response path. For production AI systems, connect CT evidence to DNS ownership, TLS configuration, deployment records, vendor domains, package registries, model endpoints, system inventory, and incident response.

Let's Encrypt's CT-log documentation, updated June 15, 2026, says CT is a system for logging and monitoring TLS certificate issuance, notes that Let's Encrypt submits all certificates it issues to CT logs, and describes CT as becoming critical infrastructure. That is the right scale of the issue: the log is no longer a niche debugging tool. It is part of the public memory of web identity.

CT should also inform procurement and vendor governance. If an AI vendor, package registry, model hub, payment endpoint, or agent tool server appears in a system boundary, the organization should know which public names it depends on, which certificate authorities normally issue for them, what monitor watches them, and who investigates unexpected issuance.

Minimum CT Record

Surveillance Limits

CT also has privacy and exposure costs. Public logs can reveal hostnames, infrastructure timing, certificate-authority relationships, and the existence of services that were not meant to be advertised. Those facts may be legitimate public accountability for the Web PKI, but they can also become reconnaissance material. Teams should avoid placing sensitive internal names in publicly trusted certificates unless they are prepared for those names to be logged.

The bigger mistake is treating CT as proof of safety. A certificate can be logged and still front a phishing site, compromised service, malicious package host, unsafe model endpoint, or coercive surveillance system. CT says that issuance became visible. It does not say that the site is good, that the operator is accountable, or that an agent may act there without further authorization.

Source Discipline

Claims about CT should distinguish the protocol, the browser policy, the log operator, and the monitor. Cite RFC 6962 or RFC 9162 for protocol structure, the Certificate Transparency project site for ecosystem language and actor roles, Chrome materials for Chrome-specific policy claims, Static CT API materials for tiled-log behavior, and a certificate authority's own documentation for how that authority logs certificates. Do not cite CT as if it governs all transparency logs, all provenance systems, or all AI supply-chain evidence.

For current claims, record the review date. CT log lists, qualified logs, CA practices, browser requirements, and log APIs are operational policy surfaces that can change faster than the underlying RFCs.

Spiralist Reading

Spiralism reads Certificate Transparency as a public ledger of permission becoming infrastructure. A certificate used to look like a quiet handshake between a domain, an authority, and a browser. CT turns that handshake into a trace that others can inspect. The web becomes less mystical because one more trust event has a record.

The lesson travels to AI governance, but only if we keep the modesty of the mechanism. A log is not moral judgment. It is a memory device. It lets the community ask who issued what, when, and under which authority, then decide whether the answer holds.

Sources

Return to Wiki