Certificate Transparency
Certificate Transparency (CT) is an Internet security standard and protocol that requires the public logging of Transport Layer Security (TLS) server certificates as they are issued, enabling the detection of misissued or malicious certificates by certificate authorities (CAs) through verifiable, append-only records.[1] Developed initially by Google engineers and operational since 2013, CT addresses vulnerabilities in the Web Public Key Infrastructure (Web PKI) where a single compromised or erroneous CA could issue unauthorized certificates without detection.[2] The core mechanism involves independent CT logs—public, tamper-evident services structured as Merkle trees—that store certificate chains, issue Signed Certificate Timestamps (SCTs) as proofs of inclusion, and allow auditors to verify log integrity via inclusion and consistency proofs.[1] These logs are monitored by domain owners, browser vendors, researchers, and other stakeholders to ensure CA accountability and rapid response to threats.[2] Major web browsers have adopted CT enforcement to bolster trust: Google Chrome began requiring SCTs for all publicly trusted certificates issued after April 30, 2018, effective from July 24, 2018, in version 68 and later.[3] Mozilla Firefox implemented full enforcement on desktop platforms starting with version 135 in early 2025, mandating at least two valid SCTs from public CAs for certificate acceptance.[4] Apple Safari similarly enforces CT for TLS certificates trusted on iOS, iPadOS, macOS, and other platforms, aligning with industry standards to reject non-compliant certificates.[1] As of 2025, over 2.5 billion certificates have been logged across multiple operator-run logs, demonstrating widespread participation and the framework's role in enhancing the security of HTTPS connections worldwide.[2] The protocol evolved from the experimental RFC 6962 (2013) to the standards-track RFC 9162 (2021), with ongoing updates to support scalability and resilience against log failures.[1]Overview
Definition and Purpose
Certificate Transparency (CT) is an Internet security framework that maintains publicly auditable, append-only, and cryptographically verifiable logs of all publicly trusted Transport Layer Security (TLS) server certificates as they are issued.[1] These logs operate as independent, untrusted network services, allowing anyone to submit certificates for inclusion and query the logs to verify their presence, with Merkle trees providing efficient proofs of inclusion without trusting the log operators.[1] By design, CT ensures that certificate authorities (CAs) must publicly record issuances, shifting from opaque trust models to transparent oversight.[5] The primary purpose of CT is to enable the early detection of misissued or unauthorized certificates through public monitoring, mitigating risks from compromised or rogue CAs that could issue fraudulent certificates for domains they do not control.[1] This addresses fundamental vulnerabilities in public key infrastructure (PKI), where a single CA breach can undermine trust in the entire system, as seen in attacks enabling man-in-the-middle interceptions.[6] Domain owners, security researchers, and automated monitors can scan logs to identify suspicious issuances, prompting swift intervention.[5] CT's development was directly motivated by high-profile incidents, such as the 2011 DigiNotar breach, in which hackers compromised the Dutch CA to issue over 500 fraudulent certificates, including for google.com, facilitating targeted surveillance in Iran without initial detection.[6] This event exposed the dangers of blind reliance on CAs and spurred efforts to enforce transparency, ensuring that all certificates become publicly visible shortly after issuance to prevent similar undetected misuses.[1] Among its core goals, CT aims to enhance CA accountability by making issuance practices verifiable, facilitate rapid detection of errors or attacks via continuous log auditing, and complement traditional revocation mechanisms like Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP) by enabling timely identification of misissuances that may require revocation.[1] This promotes a more resilient PKI ecosystem, where browsers and root program operators can enforce compliance by rejecting unlogged certificates, ultimately reducing the window for malicious certificates to cause harm.[5]Key Components and Principles
Certificate Transparency (CT) relies on a distributed ecosystem of components to ensure the public logging and auditing of TLS certificates. The core elements include CT logs, which operate as append-only, publicly verifiable data structures using Merkle trees to record certificates as they are issued by certificate authorities (CAs). Monitors serve as independent entities that continuously scan these logs to detect anomalies, such as unauthorized or misissued certificates, enabling rapid identification and response to potential threats. Auditors, which may integrate with monitors or function standalone, verify the integrity and consistency of logs by checking cryptographic proofs against partial log data, ensuring no tampering or omissions occur. Clients, primarily web browsers like Chrome and Firefox, enforce CT compliance by requiring proof of logging before trusting certificates, thereby extending verifiability to end-users. The system operates on several foundational principles to maintain security and trustworthiness. Public verifiability is achieved through cryptographic proofs, such as Merkle audit paths, allowing anyone to confirm a certificate's inclusion in a log without needing the full log contents. Timeliness ensures that logs publish new certificate entries within a defined Maximum Merge Delay (MMD), typically 24 hours or less, to prevent delays in detecting misissuances. Consistency mandates that logs remain synchronized and append-only across operators, with mechanisms like Signed Tree Heads (STHs) enabling cross-verification to detect forks or inconsistencies. A critical mechanism in CT is the Signed Certificate Timestamp (SCT), which a log issues immediately upon receiving a certificate submission. SCTs, containing a timestamp and Merkle leaf hash, can be embedded directly in the certificate via an X.509 extension, delivered through TLS extensions during handshakes, or provided via OCSP stapling, proving to clients that the certificate has been logged. Browsers validate these SCTs against known logs to reject non-compliant certificates, with policies evolving to require multiple SCTs from diverse logs for enhanced reliability. Unlike traditional Public Key Infrastructure (PKI), which relies on opaque trust in CAs without public oversight, CT introduces observable and auditable issuance processes, shifting the model toward community-enforced accountability to mitigate risks like secret key compromises or erroneous issuances.Historical Development
Origins and Early Proposals
The development of Certificate Transparency (CT) originated in Google research during 2011 and 2012, prompted by the compromise of the Dutch certificate authority (CA) DigiNotar. In August 2011, attackers exploited DigiNotar's systems to issue a wildcard HTTPS certificate for google.com, enabling a man-in-the-middle attack against Iranian users accessing Google services.[6] This incident exposed 531 fraudulent certificates issued by DigiNotar, leading to the CA's bankruptcy on September 20, 2011, and highlighting systemic vulnerabilities in the public key infrastructure where misissuances could go undetected for extended periods.[6] In response, Google initiated work on CT as a framework to enhance accountability among CAs through public logging of certificates. The concept drew from earlier ideas on verifiable append-only logs to audit CA behavior without relying solely on trust in individual authorities.[6] By 2013, Ben Laurie of Google emerged as the primary architect, authoring the initial proposal alongside contributions from security experts Adam Langley and Emilia Kasper.[7] This effort culminated in the publication of the IETF draft "Certificate Transparency" (draft-ietf-trans-rfc6962) in early 2013, which outlined a system for publicly logging all TLS server certificates issued by publicly trusted certificate authorities to detect unauthorized issuances.[7] The draft emphasized logging as a means to mitigate risks like those seen in DigiNotar, where external monitoring could have revealed the breach sooner.[7] Early adoption of the proposal faced significant hurdles, particularly from CAs concerned about operational impacts. The initial design required CAs to submit certificates to distributed logs and await synchronization, introducing delays of hours or even days into issuance pipelines, which many CAs deemed unacceptable for business efficiency.[6] Additionally, the public visibility of logged certificates raised privacy fears among CAs and domain owners, as it could expose sensitive details about website deployments and potentially aid adversaries in reconnaissance.[6] These challenges necessitated refinements, such as signed certificate timestamps, to balance transparency with practicality while addressing resistance to the added overhead.[6]Standardization and Initial Adoption
The standardization of Certificate Transparency (CT) began with the publication of RFC 6962 by the Internet Engineering Task Force (IETF) in June 2013, which formally defined the CT protocol for publicly logging TLS server certificates to enable detection of mis-issuance.[8] This RFC outlined the core mechanisms, including the use of append-only Merkle trees for logs and signed timestamps to prove inclusion, establishing CT as an open framework to enhance the security of the public key infrastructure.[8] In December 2021, the IETF published RFC 9162, which obsoleted RFC 6962 and introduced version 2.0 of the protocol with improvements such as support for certificate extensions and enhanced scalability features.[1] Initial adoption gained momentum shortly after standardization, with Google launching the first CT log, Pilot by Google, in March 2013 to test the infrastructure ahead of broader implementation. By 2014, Google operated additional logs like Google 'Argon' and 'Xenon', marking the early operational milestones for CT infrastructure. Browser integration began with Google Chrome requiring CT compliance for Extended Validation (EV) certificates issued after January 1, 2015, to display the green address bar, ensuring these high-assurance certificates were logged publicly.[9] This policy extended to all publicly trusted certificates by April 30, 2018, when Chrome version 68 began enforcing CT, rejecting non-compliant certificates issued after that date.[10] Certificate authorities (CAs) quickly aligned with these requirements; for instance, Let's Encrypt, upon its public launch in December 2015, began submitting all issued certificates to CT logs to obtain signed certificate timestamps (SCTs). Other major CAs followed suit, integrating SCT submission by 2015 to meet Chrome's EV policy.[11] Apple Safari adopted CT enforcement for all certificates issued after October 15, 2018, while Mozilla Firefox began supporting SCT verification around the same period, with full enforcement implemented starting with version 135 in February 2025.[12][4] Concurrently, browser root programs established formal log operator policies; Google's CT log program, initiated in 2014, defined criteria for trusted logs, including security audits and operator commitments, to curate lists of compliant operators.[13] Apple's CT log program similarly emerged by 2018 to approve and monitor logs for Safari compatibility.[14] These developments solidified CT's role in the ecosystem by 2018, with widespread CA participation and browser enforcement driving initial uptake, though full enforcement timelines evolved over time.Core Mechanisms
Logging Procedure and Merkle Trees
Certificate Authorities (CAs) are required to submit all issued certificates and precertificates to one or more Certificate Transparency (CT) logs operated by independent parties. Submissions occur via a secure HTTPS POST request to the log's API endpoint, including the certificate or precertificate chain rooted in a trusted CA. Upon validation of the submission—ensuring the chain is properly formed and the entry is novel—the log operator appends the certificate data to an append-only sequence of log entries. The operator then integrates this entry into the log's Merkle tree, computes an inclusion proof, and issues a Signed Certificate Timestamp (SCT) containing the timestamp, Merkle tree path, and a signature over this data using the log's private key. This SCT serves as a receipt confirming the certificate's logging commitment.[1] CT logs employ Merkle trees as the core data structure to maintain a verifiable, append-only ledger of certificate entries. Each leaf node in the tree represents a hash of a log entry, which encapsulates the certificate or precertificate chain along with metadata such as a timestamp and entry type. Internal nodes are computed as the SHA-256 hash of the concatenation of their two child nodes' values, forming a balanced binary tree that grows with new appendages. This hierarchical hashing enables efficient proofs of inclusion or consistency with minimal data: specifically, an inclusion proof requires only O(log n) hashes, where n is the number of leaves, allowing verifiers to reconstruct the tree root from a single leaf without downloading the entire structure. The tree construction follows a precise recursive definition to handle varying sizes: \text{MTH}(\{\}) = \text{SHA-256}(\,); \text{MTH}(\{d(0)\}) = \text{SHA-256}(0x00 \Vert d(0)); \text{MTH}(D) = \text{SHA-256}(0x01 \Vert \text{MTH}(D[0:k]) \Vert \text{MTH}(D[k:n])), \quad n > 1, where D is the sequence of leaf hashes, k is the largest power of two less than n, and \Vert denotes concatenation.[1] The inclusion proof for a certificate at position m in a tree of size n consists of the sibling hashes along the path from the leaf to the root, formally defined recursively as the Merkle audit path: \text{PATH}(m, D) = \begin{cases} \text{PATH}(m, D[0:k]) : \text{MTH}(D[k:n]) & \text{if } m < k, \\ \text{PATH}(m - k, D[k:n]) : \text{MTH}(D[0:k]) & \text{if } m \geq k, \end{cases} with base cases for small trees. This path allows recomputation of the root hash, known as the Tree Head. To ensure authenticity, the log periodically signs the Tree Head along with a timestamp—producing a Signed Tree Head (STH)—using its private key, which clients can fetch to verify against SCTs.[1] CT logs enforce timeliness to maintain transparency: they must accept valid submissions and issue SCTs immediately upon receipt, while incorporating the certificate into the publicly queryable Merkle tree within the log's specified Maximum Merge Delay (MMD), not exceeding 24 hours as per browser policies. The STH must be updated and signed at least as frequently as the MMD to reflect recent additions without delay.[1][14]Inclusion Proofs and Auditing Process
In Certificate Transparency, inclusion proofs enable clients and auditors to verify that a specific certificate has been incorporated into a log's Merkle tree without needing to download the entire tree. When a certificate authority (CA) submits a certificate to a log, the log returns a Signed Certificate Timestamp (SCT) containing the certificate's leaf hash, the tree size at the time of inclusion, and the Merkle inclusion proof, which consists of the sibling hashes along the path from the leaf to the tree root. To validate the SCT, a client reconstructs the Merkle root by iteratively hashing the leaf with its siblings according to the tree's structure and checks if this computed root matches the root hash in the corresponding Signed Tree Head (STH). The proof's validity is confirmed if the computed Merkle root equals the STH's root hash, with the STH's timestamp ensuring the inclusion occurred within the MMD.[15][16] The auditing process relies on independent monitors and auditors to ensure log integrity and detect potential misbehavior by CAs or logs. Monitors periodically query logs for the latest STH via the GET /ct/v1/get-sth endpoint and retrieve all entries up to the tree size using GET /ct/v1/get-entries, then verify that the Merkle tree constructed from these entries produces the exact root hash in the STH. Auditors further check consistency by obtaining consistency proofs for pairs of STHs (via GET /ct/v1/get-sth-consistency) or by validating multiple inclusion proofs against known certificates, confirming that the logs remain append-only and free from unauthorized modifications.[17][18][19] Signed Tree Heads (STHs) form the cornerstone of this verification, as they are periodic signatures by the log operator over the current Merkle tree root, including the tree version, timestamp, size, and root hash. Logs must produce and make available an STH at least every Maximum Merge Delay (MMD), which does not exceed 24 hours for compliant logs, allowing verifiers to ensure the tree head is fresh. To promote global consistency across multiple logs, STHs are gossiped through a network of monitors, enabling cross-log comparisons that detect discrepancies in reported tree states.[20][21][22] Through these mechanisms, auditors can detect misbehavior such as delays in certificate inclusion beyond the MMD—by requesting and validating inclusion proofs for SCTs—or violations of the append-only property, where conflicting STHs across gossiped data reveal forks or unauthorized changes. Duplicate entries or unexpected certificates are flagged by cross-referencing audited proofs against expected submissions, ensuring the system's transparency and accountability.[22][18]Sharding for Scalability
Certificate Transparency employs temporal sharding to distribute the growing volume of certificates across multiple log instances, partitioning the namespace based on certificate validity periods to enable parallel processing and mitigate bottlenecks in individual logs.[23] This approach divides logs into shards, each responsible for certificates with expiration dates falling within a defined temporal range, typically six to twelve months, allowing operators to manage load distribution without overloading a single append-only structure.[23] Introduced as a scalability measure around 2018 to address the post-initial adoption surge in certificate issuances, sharding ensures that logs can handle billions of entries by limiting each shard's scope and lifecycle.[24] In implementation, each shard operates as an independent Merkle tree, accepting submissions only for precertificates or certificates whose "notAfter" dates align with its predefined interval, such as half-year periods (e.g., 2024h1 covering mid-2023 to mid-2024).[25] Shard descriptors, including unique URIs, public keys, and log IDs, are published for each instance, enabling clients and monitors to direct submissions to the appropriate shard and aggregate views across active ones for comprehensive auditing.[25] Once a shard's interval expires, it rejects new entries and transitions to read-only mode, with operators deploying new shards to cover future periods, maintaining a contiguous coverage spanning three to four years ahead.[23] The primary benefits include enhanced scalability for high-volume environments, as demonstrated by operators like Let's Encrypt, whose Oak log family uses multiple half-year shards to process millions of daily submissions without performance degradation.[25] By parallelizing operations, sharding reduces storage and computational demands on any single log, supporting the ecosystem's growth to over 2.5 billion certificates logged since inception while preserving the verifiability of the overall transparency framework.[26][2] Challenges in sharding revolve around maintaining consistency across distributed instances and efficiently aggregating proofs from multiple shards for global audits, requiring robust monitor tools to query and verify Signed Certificate Timestamps (SCTs) from relevant logs without introducing delays or errors in detection.[24] Operators must also plan for timely shard rotations to avoid gaps in coverage, as lapsed intervals could temporarily hinder logging compliance for newly issued certificates.[23]Compliance and Enforcement
Mandatory Requirements for CAs and Browsers
Certificate authorities (CAs) participating in the public key infrastructure are required to submit all newly issued public TLS certificates to Certificate Transparency (CT) logs to obtain Signed Certificate Timestamps (SCTs), which serve as verifiable proofs of logging. According to RFC 6962, public CAs are expected to contribute all such certificates to one or more logs, with each log returning an SCT immediately upon valid submission; these SCTs must then be included in the certificates via an X.509v3 extension or delivered during TLS handshakes through OCSP stapling or a dedicated TLS extension. To meet compliance standards enforced by major browser root programs, CAs must submit certificates to at least two independent, distinct logs prior to issuance, ensuring redundancy and verifiability; for certificates with lifetimes exceeding 180 days, three SCTs from distinct operators are typically required. This submission often involves precertificates—unsigned versions of the final certificate with a poison extension—to allow logging before final issuance, treating any precertificate misissuance equivalently to a full certificate under root program policies. Browser vendors enforce CT compliance through their root certificate programs, rejecting non-compliant certificates in user agents like Chrome, Firefox, and Safari. Google Chrome, starting with version 68 in July 2018, mandates CT compliance for all publicly trusted TLS certificates issued after April 30, 2018, validating at least two SCTs from qualified logs during certificate chain checks; failure results in the certificate being treated as invalid, preventing secure connections. Apple extended CT enforcement across its ecosystem, including Safari on macOS and iOS, requiring all TLS certificates issued after October 15, 2018, to include SCTs from at least two separate logs, with non-compliant certificates rejected as untrusted and triggering connection errors akin to self-signed or expired ones. Mozilla Firefox, via its Root CA Program, began enforcing CT for all certificates from included CAs starting with desktop version 135 in early 2025, aligning with the same multi-log submission and SCT inclusion rules to ensure public auditability.[27] Non-compliance with these CT mandates carries severe consequences, primarily through actions by browser root programs that oversee trusted CAs. Persistent failure to log certificates or provide valid SCTs can lead to the revocation or distrust of a CA's root certificates in vendor trust stores, effectively barring all certificates issued under that root from being trusted by affected browsers and platforms. For instance, Mozilla's Root Store Policy treats CT-related misissuances, such as unlogged precertificates, as violations warranting root revocation, while Google's and Apple's programs similarly impose distrust for repeated non-adherence, impacting global website accessibility. The evolution of these requirements transitioned CT from an optional monitoring framework to a mandatory obligation for public TLS certificates. Proposed in 2013 via RFC 6962 as a voluntary protocol to enhance CA accountability, CT became enforceable in Chrome for Extended Validation certificates in 2015 before expanding to all public TLS certificates by 2018. Apple's policy followed suit in 2018, and by 2019, CT compliance was required across Chrome and Safari for the majority of web traffic, with Firefox completing full enforcement in 2025 through integration with its root program.Policy Evolution in Root Programs
The Google Chrome Root Program marked a significant milestone in Certificate Transparency (CT) enforcement by requiring all publicly trusted TLS certificates issued after April 30, 2018, to include Signed Certificate Timestamps (SCTs) from compliant CT logs, treating non-compliant certificates as invalid. This policy extension applied to Domain Validated (DV), Organization Validated (OV), and Extended Validation (EV) certificates, building on earlier requirements for EV certificates since 2015.[28] In 2020, the program introduced enhanced compliance monitoring through updates to the CT Log Operator Policy, enabling automated audits to verify log integrity and SCT correspondence to logged entries, thereby strengthening overall enforcement. Mozilla's Network Security Services (NSS) integrated CT requirements into its root store policy around 2017, mandating that Certificate Authorities (CAs) submit precertificates and final certificates to CT logs as part of compliance for root inclusion.[29] This integration emphasized logging as a mechanism to detect misissuance, with CAs required to ensure exact matches between precertificates and issued certificates under RFC 6962.[29] Ongoing policy reviews have refined these rules, including prohibitions on SHA-1 signatures over precertificates and requirements for revocation services on presumed certificates, maintaining CT as a core pillar of NSS trust management.[29] Apple's Root Certificate Program mandated SCTs for all newly issued TLS server authentication certificates effective October 15, 2018, requiring inclusion in multiple qualified CT logs to validate trust on Apple platforms.[14] This policy aligns with Apple's trust store, where SCTs must originate from logs compliant with RFC 6962 or the Static Certificate Transparency API, ensuring high availability and low merge delays.[14] Emphasizing log diversity, the program qualifies logs only after a 74-day probationary period and trusts a curated set of operators to mitigate single-point failures, promoting resilience in the CT ecosystem.[14] The Microsoft Trusted Roots Program provides partial support for CT, distributing CT Log Monitor (CTLM) policies via monthly Windows Certificate Trust Lists (CTLs) starting in early 2025, allowing users to opt in to validation requiring at least two SCTs from public CAs.[30] This integration aligns with Windows updates, enabling automatic propagation of trusted log lists and CT enforcement through system-level mechanisms, though full browser enforcement in Microsoft Edge follows Chromium's standards without standalone root-specific mandates.[31]Implementations and Infrastructure
CT Log Operators and Programs
Certificate Transparency (CT) logs are operated by a select group of organizations to maintain an append-only, publicly auditable record of certificate issuances, with major operators including Google, Let's Encrypt, Cloudflare, DigiCert, Sectigo, and TrustAsia. Google operates the Argon and Xenon log series, with multiple instances such as Argon2025h2 (US-based) and Xenon2025h2 (EU-based) to support geographic diversity and load distribution.[32][33] Let's Encrypt runs the Oak log series, launched in 2019 with sponsorship from Sectigo, and uses the Sunlight implementation introduced in 2024 for enhanced scalability.[34][35] Cloudflare operates the Nimbus and Raio series logs using the Azul static CT API implementation built on its Workers platform and released in 2025.[36] DigiCert manages logs like Wyvern and Sphinx, while Sectigo oversees a large number using the Elephant and Tiger series logs, which replaced earlier Mammoth and Sabre logs, contributing significantly to the ecosystem's capacity.[37] The governance of CT log operators is primarily guided by programs like Google's Certificate Transparency Log Policy, initiated in 2014 and updated periodically to ensure reliability and compliance. This policy mandates that operators maintain 99% availability over a 90-day rolling average, undergo random compliance audits by Google for RFC 6962 conformance, and provide transparency on their signing keys by submitting DER-encoded public keys and SHA-256 hashes (LogIDs).[23] It also requires logs to accept submissions from all Chrome-trusted certificate authorities as listed in the CA/Browser Forum's CCADB, and operators must monitor for policy changes via dedicated channels. Similar policies exist for other root programs, such as Apple's CT log program, which emphasizes trusted logs for iOS and macOS platforms.[14] Qualification for operating a CT log involves submitting the log's public key and operational details to browser root programs for verification and inclusion in their trusted lists. For Chrome, operators file a bug report with contact information, log endpoints, and a JSON schema describing the log, after which Google reviews for compliance before marking the log as "Qualified" or "Usable."[23] To foster diversity and mitigate single points of failure, root programs require certificates to include Signed Certificate Timestamps (SCTs) from multiple independent operators—typically at least two, with no more than one per operator for shorter-lived certificates—and encourage organizational independence among operators.[13] Public keys are integrated into browser trust stores, enabling validation of SCTs during certificate checks. As of 2025, the CT landscape features over 30 active logs across major browser programs, with a strong emphasis on geographic distribution to enhance resilience and global accessibility; for instance, Google's logs are sharded across US and EU data centers, while other operators like Cloudflare leverage distributed infrastructure.[38] This diversity, spanning about six primary operators, supports the logging of billions of certificates annually, with Sectigo and Google handling the largest volumes.[39]Trusted Logs and Root Store Integration
Certificate Transparency relies on a set of vetted logs whose public keys are incorporated into browser trust stores to ensure their reliability in validating Signed Certificate Timestamps (SCTs). For instance, Google's Chrome maintains a publicly available list of qualified CT logs, where each log's signing key is embedded in the browser's validation process, allowing it to verify SCT authenticity during TLS handshakes.[13] Similarly, Apple integrates trusted log keys into its root store, requiring logs to accept submissions from all roots in Apple's trust store for TLS server authentication certificates.[14] Mozilla's Firefox derives its list of trusted logs from Chrome's, updating it weekly to align with verified operators.[40] Vetting of CT logs involves rigorous criteria focused on security, immutability, and compliance, enforced through independent audits and testing periods. Log operators must submit their public keys, log IDs, and endpoints for review, undergoing a 90-day availability test to achieve at least 99% uptime and no outages exceeding 24 hours for Maximum Merge Delay (MMD).[23] Security assessments include verification of key protection and append-only log structure, ensured by consistent Merkle tree views that prevent tampering or conflicting data.[14] Compliance with RFC 6962 or the static-ct-api v1.0.0 is mandatory, with audits checking for proper handling of certificate submissions and rejection of invalid entries, such as expired or non-server-auth certificates. These audits are conducted by browser teams, like Google's ongoing monitoring via random queries to logs.[23] To mitigate risks of collusion, browsers enforce diversity in log submissions by requiring certificates to include SCTs from multiple distinct operators. Chrome mandates at least two SCTs from independent operators for certificates up to 180 days valid, increasing to three for longer ones, with at least one from an RFC 6962-compliant log.[13] Apple's policy similarly requires logs to be operated by diverse entities across jurisdictions, promoting robustness against single-point failures.[14] This distribution ensures no single operator can suppress misissued certificates without detection by others. Periodic reviews maintain log trustworthiness, with browsers updating their lists daily or weekly and removing non-compliant entries. For example, Chrome retires logs failing availability thresholds (e.g., below 95% over 90 days) or those not including logged certificates, as seen in the deprecation of certain operators' logs due to audit failures.[23] Apple conducts ongoing monitoring, transitioning logs to "retired" or "rejected" states at its discretion for immutability breaches.[14] These mechanisms, often using algorithms like ECDSA with P-256 curves for log signatures, enable dynamic ecosystem adjustments without compromising transparency.APIs, Protocols, and Signature Algorithms
The Certificate Transparency (CT) framework defines a set of APIs for clients to interact with logs, primarily over HTTPS, to submit certificates, retrieve tree heads, and obtain proofs of inclusion. The original CT API, specified in RFC 6962, uses HTTPS endpoints with JSON-encoded payloads for core operations. These include the POST request to/ct/v1/add-chain for submitting a certificate chain and receiving a Signed Certificate Timestamp (SCT) in response, the GET request to /ct/v1/get-sth for fetching the latest Signed Tree Head (STH) containing the tree size, timestamp, and root hash, and the GET request to /ct/v1/get-proof-by-hash for retrieving a Merkle inclusion proof by leaf certificate hash up to a specified tree size.[8]
The updated API in RFC 9162 (version 2.0) uses JSON over HTTPS with new endpoints for improved interoperability and scalability, facilitating easier parsing and integration. In CT version 2.0, outlined in RFC 9162, the API evolves with new endpoints such as POST /ct/v2/submit-entry to replace chain submission (supporting both certificates and precertificates), GET /ct/v2/get-sth for the current tree head, GET /ct/v2/get-proof-by-hash for inclusion proofs, and additional paths like GET /ct/v2/get-entries for batch retrieval of log entries and GET /ct/v2/get-all-by-hash for comprehensive proofs including consistency checks. These v2 endpoints maintain backward compatibility where possible but emphasize JSON formatting to improve interoperability and reduce parsing complexity.[1]
CT relies on specific cryptographic signature algorithms to ensure the integrity of SCTs and STHs, with SHA-256 as the fixed Merkle tree hashing function across versions. The primary algorithm is ECDSA using the NIST P-256 elliptic curve, providing efficient signing for log operators while maintaining security equivalent to 128-bit symmetric strength. RSA signatures with SHA-256 are also permitted for legacy compatibility, requiring keys of at least 2048 bits. Newer implementations in CT v2 support EdDSA (Edwards-curve Digital Signature Algorithm) as per RFC 8032, particularly with Curve25519 for faster, deterministic signing that mitigates nonce-related vulnerabilities and enhances privacy by avoiding traceable signatures.[8][1]
The protocol has evolved from the monolithic v1 design in RFC 6962 (published in 2013), which assumed single-tree logs, to v2 in RFC 9162 (published in 2021), which promotes scalability through multiple independent logs—effectively enabling sharded architectures by distributing certificate submissions across operators without a unified tree. This shift addresses growing certificate volumes by allowing parallel log operations while preserving verifiable inclusion via cross-log proofs.[8][1]