Hubbry Logo
Certificate TransparencyCertificate TransparencyMain
Open search
Certificate Transparency
Community hub
Certificate Transparency
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Certificate Transparency
Certificate Transparency
Certificate Transparency
View on Wikipedia
from Wikipedia

Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates.[1] When an internet user interacts with a website, a trusted third party is needed for assurance that the website is legitimate and that the website's encryption key is valid. This third party, called a certificate authority (CA), will issue a certificate for the website that the user's browser can validate. The security of encrypted internet traffic depends on the trust that certificates are only given out by the certificate authority and that the certificate authority has not been compromised.

Certificate Transparency makes public all issued certificates in the form of a distributed ledger, giving website owners and auditors the ability to detect and expose inappropriately issued certificates.

Work on Certificate Transparency first began in 2011 after the certificate authority DigiNotar became compromised and started issuing malicious certificates. Google engineers submitted a draft to the Internet Engineering Task Force (IETF) in 2012. This effort resulted in IETF RFC 6962, a standard defining a system of public logs to record all certificates issued by publicly trusted certificate authorities, allowing efficient identification of mistakenly or maliciously issued certificates.[2]

Technical overview

[edit]

The certificate transparency system consists of a system of append-only certificate logs. Logs are operated by many parties, including browser vendors and certificate authorities.[3] Certificates that support certificate transparency must include one or more signed certificate timestamps (SCTs), which is a promise from a log operator to include the certificate in their log within a maximum merge delay (MMD).[4][3] At some point within the maximum merge delay, the log operator adds the certificate to their log. Each entry in a log references the hash of a previous one, forming a Merkle tree. The signed tree head (STH) references the current root of the Merkle tree.

Logging procedure

[edit]

Although anyone can submit a certificate to a CT log, this task is commonly carried out by a CA as follows:[4][5]

  1. An applicant, "The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate",[6] requests a certificate from a CA.
  2. The CA issues a special precertificate, a certificate which carries a poison extension signaling that it should not be accepted by user agents.
  3. The CA sends the precertificate to logs.
  4. Logs return corresponding SCTs to the CA.
  5. The CA attaches SCTs collected from logs as an X.509 extension to the final certificate and provides it to the applicant.

Finally, the CA may decide to log the final certificate as well. Let's Encrypt E1 CA, for example, logs both precertificates and final certificates (see CA crt.sh profile page under 'issued certificates' section), whereas Google GTS CA 2A1 does not (see crt.sh profile page).

Mandatory certificate transparency

[edit]

Some browsers require Transport Layer Security (TLS) certificates to have proof of being logged with certificate transparency,[7][8] either through SCTs embedded into the certificate, an extension during the TLS handshake, or through OCSP:

Browser Current SCT requirements Current OCSP/TLS extension requirements
Chrome/Chromium
  • One SCT from a currently approved log
  • Duration ≤ 180 days: 2 SCTs from once-approved logs
  • Duration > 180 days: 3 SCTs from once-approved logs[9][10]
  • 1 SCT from a current Google log
  • 1 SCT from a current non-Google log
Firefox
  • desktop: 2 SCTs from once-approved logs, since v135[11][12] (released 2025-02-04)
  • Firefox for Android: 2 SCTs from once-approved logs, since v145[11] (released 2025-11-11)
 Two SCTs from currently approved logs
Safari
  • One SCT from a currently approved log
  • Duration ≤ 180 days: 2 SCTs from once-approved logs
  • Duration > 180 days: 3 SCTs from once-approved logs[13]
 Two SCTs from currently approved logs
  • NOTE: Apple platforms that use system libraries for TLS enforce CT for free on any TLS connection (not just Safari).[14]

Log sharding

[edit]

Due to the large quantities of certificates issued with the Web PKI, certificate transparency logs can grow to contain many certificates. This large quantity of certificates can cause strain on logs. Temporal sharding is a method to reduce the strain on logs by sharding a log into multiple logs, and having each shard only accept precertificates and certificates with an expiration date in a particular time period (usually a calendar year).[15][16][17] Cloudflare's Nimbus series of logs was the first to use temporal sharding.

Background

[edit]

Advantages

[edit]

One of the problems with digital certificate management is that fraudulent certificates take a long time to be spotted, reported and revoked. An issued certificate not logged using Certificate Transparency may never be spotted at all. The main advantage with Certificate Transparency is the ability for cyber security teams to defend companies and organisations by monitoring for suspicious domains registering certificates. The new certificates for these suspicious domains may have similar names to other legitimate domains and are designed to be used to support malicious activities such as phishing attacks. Certificate Transparency puts cyber security teams in control and enables them to issue domain take down orders for suspicious domains and allows them to apply cyber security controls on web proxies and email gateways for immediate protection.[18]

Side Effects

[edit]

Domain names that are used on internal networks and have certificates issued by certificate authorities become publicly searchable as their certificates are added to CT logs.

Certificate Transparency logs

[edit]

Certificate Transparency depends on verifiable Certificate Transparency logs. A log appends new certificates to an ever-growing Merkle hash tree.[19]: §4  To be seen as behaving correctly, a log must:

  • Verify that each submitted certificate or precertificate has a valid signature chain leading back to a trusted root certificate authority certificate.
  • Refuse to publish certificates without this valid signature chain.
  • Store the entire verification chain from the newly accepted certificate back to the root certificate.
  • Present this chain for auditing upon request.

A log may accept certificates that are not yet fully valid and certificates that have expired.

Certificate Transparency monitors and auditors

[edit]

There are two primary categories of monitors: log integrity monitors (also referred to as log verifiers or log auditors)[19]: §8.3 and tracking monitors.[20] Some companies offering monitoring services collect data from all logs and provide paid services for domain tracking. For example, a domain owner can register for Cloudflare's services, which globally monitor all logs and send email updates whenever a certificate is issued for their domain[21] , allowing them control over all certificates issued. Large organizations can maintain their own monitors, which continuously scan for new certificate issued for their domains. If a certificate authorities (CA) attempts to issue a "bad" certificate for one of these domains (intentionally or unintentionally); the monitor will quickly detect it. Two popular APIs for research and tracking are Sectigo's crt.sh[22] and Cloudflare MerkleTown.[23] These tools facilitate the monitoring of certificate issuance and help organizations stay on top of their domain's security. While there is an additional consideration of monitoring the monitors themselves, the likelihood of a significant impact on system performance or security due to misbehavior of a single monitor is low [reference needed]. This is because there are numerous log monitors, providing a layered approach to security and minimizing the risk of a single point of failure.

Certificate Transparency log programs

[edit]

Apple[24] and Google[15] have separate log programs with distinct policies and lists of trusted logs.

Root stores of Certificate Transparency logs

[edit]

Certificate Transparency logs maintain their own root stores and only accept certificates that chain back to the trusted roots.[19] A number of misbehaving logs have been publishing inconsistent root stores in the past.[25]

Static CT API

[edit]

A new structure for logs is based on dividing the Merkle Tree into tiles. This structure is expected to be faster, easier to operate, and to provide much smaller merge delays (the current Maximum Merge Delay is 24 hours).[26] Chrome has updated its Certificate Transparency (CT) policy to accept SCTs from the new static-CT-API logs only if an SCT from an RFC 6962 log is also present, and it intends to complete the migration to static-CT-API CT logs by the end of 2025.[27]

History

[edit]
An example of Certificate Transparency entry on Firefox 89

In 2011, a reseller of the certificate authority Comodo was attacked and the certificate authority DigiNotar was compromised,[28] demonstrating existing flaws in the certificate authority ecosystem and prompting work on various mechanisms to prevent or monitor unauthorized certificate issuance. Google employees Ben Laurie, Adam Langley and Emilia Kasper began work on an open source framework for detecting mis-issued certificates the same year. In 2012, they submitted the first draft of the standard to IETF under the code-name "Sunlight".[29]

In March 2013, Google launched its first certificate transparency log.[30]

In June 2013, RFC 6962 "Certificate Transparency" was published, based on the 2012 draft.

In September 2013, DigiCert became the first certificate authority to implement Certificate Transparency.[31]

In 2015, Google Chrome began requiring Certificate Transparency for newly issued Extended Validation Certificates.[32][33] It began requiring Certificate Transparency for all certificates newly issued by Symantec from June 1, 2016, after they were found to have issued 187 certificates without the domain owners' knowledge.[34][35] Since April 2018, this requirement has been extended to all certificates.[8]

On March 23, 2018, Cloudflare announced its own CT log named Nimbus.[36]

In May 2019, certificate authority Let's Encrypt launched its own CT log called Oak. Since February 2020, it is included in approved log lists and is usable by all publicly trusted certificate authorities.[37]

In December 2021, RFC 9162 "Certificate Transparency Version 2.0" was published.[19] Version 2.0 includes major changes to the required structure of the log certificate, as well as support for Ed25519 as a signature algorithm of SCTs and support for including certificate inclusion proofs with the SCT. However, it has not seen industry adoption and is considered dead on arrival.[38]

In February 2022, Google published an update to their CT policy,[39] which removes the requirement for certificates to include a SCT from their own CT log service, matching all the requirements for certificates to those previously published by Apple.[40]

In February 2025, Mozilla Firefox desktop version 135 began requiring Certificate Transparency for all certificates issued by a certificate authority in Mozilla's Root CA Program.[41][42]


Signature algorithms

[edit]

In Certificate Transparency Version 2.0, a log must use one of the algorithms in the IANA registry "Signature Algorithms".[19]: 10.2.2 [43]

Tools for inspecting CT logs

[edit]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Certificate Transparency

View on Grokipedia
from Grokipedia
Certificate Transparency (CT) is an Internet security standard and protocol that requires the public logging of (TLS) server certificates as they are issued, enabling the detection of misissued or malicious certificates by certificate authorities (CAs) through verifiable, append-only records. Developed initially by engineers and operational since 2013, CT addresses vulnerabilities in the Web (Web PKI) where a single compromised or erroneous CA could issue unauthorized certificates without detection. 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. These logs are monitored by domain owners, browser vendors, researchers, and other stakeholders to ensure CA accountability and rapid response to threats. Major web browsers have adopted CT enforcement to bolster trust: began requiring SCTs for all publicly trusted certificates issued after April 30, 2018, effective from July 24, 2018, in version 68 and later. 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. Apple similarly enforces CT for TLS certificates trusted on , , macOS, and other platforms, aligning with industry standards to reject non-compliant certificates. 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 connections worldwide. 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.

Overview

Definition and Purpose

Certificate Transparency (CT) is an framework that maintains publicly auditable, append-only, and cryptographically verifiable logs of all publicly trusted (TLS) server certificates as they are issued. 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. By design, CT ensures that certificate authorities (CAs) must publicly record issuances, shifting from opaque trust models to transparent oversight. 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. This addresses fundamental vulnerabilities in (PKI), where a single CA breach can undermine trust in the entire system, as seen in attacks enabling man-in-the-middle interceptions. Domain owners, security researchers, and automated monitors can scan logs to identify suspicious issuances, prompting swift intervention. CT's development was directly motivated by high-profile incidents, such as the 2011 breach, in which hackers compromised the Dutch CA to issue over 500 fraudulent certificates, including for google.com, facilitating targeted surveillance in without initial detection. 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. 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. 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.

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 , 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 extension, delivered through TLS extensions during handshakes, or provided via , 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 (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 research during 2011 and 2012, prompted by the compromise of the Dutch (CA) . In August 2011, attackers exploited DigiNotar's systems to issue a wildcard certificate for google.com, enabling a against Iranian users accessing services. 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. In response, initiated work on CT as a framework to enhance among CAs through public of certificates. The concept drew from earlier ideas on verifiable logs to audit CA behavior without relying solely on trust in individual authorities. By 2013, Ben Laurie of emerged as the primary architect, authoring the initial proposal alongside contributions from security experts Adam Langley and Emilia Kasper. 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 all TLS server certificates issued by publicly trusted certificate authorities to detect unauthorized issuances. The draft emphasized as a means to mitigate risks like those seen in , where external monitoring could have revealed the breach sooner. Early adoption of the proposal faced significant hurdles, particularly from CAs concerned about operational impacts. The initial 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. Additionally, the public visibility of logged certificates raised fears among CAs and domain owners, as it could expose sensitive details about deployments and potentially aid adversaries in . These challenges necessitated refinements, such as signed certificate timestamps, to balance transparency with practicality while addressing resistance to the added overhead.

Standardization and Initial Adoption

The standardization of Certificate Transparency (CT) began with the publication of RFC 6962 by the (IETF) in June 2013, which formally defined the CT protocol for publicly logging TLS server certificates to enable detection of mis-issuance. 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 . 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 features. Initial adoption gained momentum shortly after standardization, with launching the first CT log, Pilot by Google, in March 2013 to test the infrastructure ahead of broader implementation. By 2014, operated additional logs like Google 'Argon' and 'Xenon', marking the early operational milestones for CT infrastructure. Browser integration began with 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. 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. Certificate authorities (CAs) quickly aligned with these requirements; for instance, , 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. Apple adopted CT enforcement for all certificates issued after October 15, 2018, while Mozilla began supporting SCT verification around the same period, with full enforcement implemented starting with version 135 in February 2025. 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. Apple's CT log program similarly emerged by 2018 to approve and monitor logs for compatibility. 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 POST request to the log's 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 , computes an inclusion proof, and issues a Signed Certificate Timestamp (SCT) containing the timestamp, 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. CT logs employ Merkle trees as the core data structure to maintain a verifiable, 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 and entry type. Internal nodes are computed as the SHA-256 hash of the concatenation of their two child nodes' values, forming a balanced 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: MTH({})=SHA-256( );\text{MTH}(\{\}) = \text{SHA-256}(\,); MTH({d(0)})=SHA-256(0x00∥d(0));\text{MTH}(\{d(0)\}) = \text{SHA-256}(0x00 \Vert d(0)); MTH(D)=SHA-256(0x01∥MTH(D[0:k])∥MTH(D[k:n])),n>1,\text{MTH}(D) = \text{SHA-256}(0x01 \Vert \text{MTH}(D[0:k]) \Vert \text{MTH}(D[k:n])), \quad n > 1, where DD is the sequence of hashes, kk is the largest less than nn, and ∥\Vert denotes . The inclusion proof for a certificate at position mm in a of size nn consists of the hashes along the path from the to the , formally defined recursively as the Merkle audit path: PATH(m,D)={PATH(m,D[0:k]):MTH(D[k:n])if m<k,PATH(m−k,D[k:n]):MTH(D[0:k])if m≥k,\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. 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 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.

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. 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 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 and free from unauthorized modifications. Signed Tree Heads (STHs) form the cornerstone of this verification, as they are periodic signatures by the log operator over the current 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. 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 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.

Sharding for Scalability

Certificate Transparency employs temporal sharding to distribute the growing volume of certificates across multiple log instances, partitioning the based on certificate validity periods to enable parallel processing and mitigate bottlenecks in individual logs. 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 structure. Introduced as a measure around 2018 to address the post-initial surge in certificate issuances, sharding ensures that logs can handle billions of entries by limiting each shard's scope and lifecycle. In implementation, each operates as an independent , 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). 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 and aggregate views across active ones for comprehensive auditing. 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. The primary benefits include enhanced scalability for high-volume environments, as demonstrated by operators like , whose Oak log family uses multiple half-year shards to process millions of daily submissions without performance degradation. 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 while preserving the verifiability of the overall transparency framework. Challenges in revolve around maintaining consistency across distributed instances and efficiently aggregating proofs from multiple for global audits, requiring robust monitor tools to query and verify Signed Certificate Timestamps (SCTs) from relevant without introducing delays or errors in detection. Operators must also plan for timely rotations to avoid gaps in coverage, as lapsed intervals could temporarily hinder compliance for newly issued certificates.

Compliance and Enforcement

Mandatory Requirements for CAs and Browsers

Certificate authorities (CAs) participating in the 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 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, , and . , 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 on macOS and , 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. , 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. Non-compliance with these CT mandates carries severe consequences, primarily through actions by browser programs that oversee trusted CAs. Persistent failure to log certificates or provide valid SCTs can lead to the or of a CA's certificates in vendor trust stores, effectively barring all certificates issued under that from being trusted by affected browsers and platforms. For instance, Mozilla's Store Policy treats CT-related misissuances, such as unlogged precertificates, as violations warranting , while Google's and Apple's programs similarly impose 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 for the majority of , with completing full enforcement in 2025 through integration with its root program.

Policy Evolution in Root Programs

The Google Chrome Root Program marked a significant 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. 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 . 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. 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. Ongoing policy reviews have refined these rules, including prohibitions on SHA-1 signatures over precertificates and requirements for services on presumed certificates, maintaining CT as a core pillar of NSS trust management. 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. 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 and low merge delays. 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. The 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. 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 follows Chromium's standards without standalone root-specific mandates.

Implementations and Infrastructure

CT Log Operators and Programs

Certificate Transparency (CT) logs are operated by a select group of organizations to maintain an , publicly auditable record of certificate issuances, with major operators including , , , , Sectigo, and TrustAsia. operates the and log series, with multiple instances such as Argon2025h2 (US-based) and Xenon2025h2 (EU-based) to support geographic diversity and load distribution. runs the log series, launched in 2019 with sponsorship from Sectigo, and uses the implementation introduced in 2024 for enhanced scalability. operates the Nimbus and Raio series logs using the Azul static CT API built on its Workers platform and released in 2025. manages logs like and Sphinx, while Sectigo oversees a large number using the and series logs, which replaced earlier and logs, contributing significantly to the ecosystem's capacity. The governance of CT log operators is primarily guided by programs like , 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 for RFC 6962 conformance, and provide transparency on their signing keys by submitting DER-encoded public keys and SHA-256 hashes (LogIDs). 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. 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 schema describing the log, after which reviews for compliance before marking the log as "Qualified" or "Usable." 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. 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, logs are sharded across and data centers, while other operators like leverage distributed infrastructure. This diversity, spanning about six primary operators, supports the logging of billions of certificates annually, with Sectigo and handling the largest volumes.

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. 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. Mozilla's derives its list of trusted logs from Chrome's, updating it weekly to align with verified operators. 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). Security assessments include verification of key protection and append-only log structure, ensured by consistent views that prevent tampering or conflicting data. 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. To mitigate risks of , 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. Apple's policy similarly requires logs to be operated by diverse entities across jurisdictions, promoting robustness against single-point failures. 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. Apple conducts ongoing monitoring, transitioning logs to "retired" or "rejected" states at its discretion for immutability breaches. 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 , to submit certificates, retrieve tree heads, and obtain proofs of inclusion. The original CT API, specified in RFC 6962, uses 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 (SCT) in response, the GET request to /ct/v1/get-sth for fetching the latest Signed Tree Head (STH) containing the tree size, , 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. The updated in RFC 9162 (version 2.0) uses over with new endpoints for improved interoperability and scalability, facilitating easier parsing and integration. In CT version 2.0, outlined in RFC 9162, the 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 formatting to improve interoperability and reduce parsing complexity. CT relies on specific cryptographic signature algorithms to ensure the integrity of SCTs and STHs, with SHA-256 as the fixed hashing function across versions. The primary algorithm is ECDSA using the NIST P-256 , 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 (Edwards-curve Digital Signature Algorithm) as per RFC 8032, particularly with for faster, deterministic signing that mitigates nonce-related vulnerabilities and enhances privacy by avoiding traceable signatures. 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.

Monitoring and Security

Advantages and Detection Capabilities

Certificate Transparency (CT) enhances the security of the (PKI) by enabling rapid detection of misissued certificates, allowing domain owners and monitors to identify unauthorized issuances shortly after they occur. In the 2015 Symantec incident, community monitors discovered rogue certificates for domains like google.com and opera.com in CT logs before the certificate authority (CA) itself was aware, leading to the revocation of 2,647 affected certificates. This proactive visibility contrasts with traditional PKI mechanisms, where misissuances might go undetected for days or longer, as CT logs provide append-only, publicly verifiable records that facilitate real-time auditing. The system's advantages include increased public for CAs, which has demonstrably reduced error rates in certificate issuance over time. By requiring CAs to submit certificates to independent logs, CT promotes transparency and deters negligence or compromise, as evidenced by a drop in misissuance errors from 12% in 2012 to 0.02% in 2017 across analyzed browser-trusted certificates. This supports automated processes, where detected anomalies trigger swift communication with CAs for mitigation, often within hours rather than weeks. Additionally, CT logs enable research into issuance patterns, allowing analysts to study CA behaviors and PKI trends without relying on proprietary data. Quantitatively, CT has logged billions of certificates since 2013, with monitors processing over 7 million entries daily by 2019 and detecting thousands of anomalies annually, such as the 23,207 misissued certificates identified in 2017 alone. As of 2025, CT logs have recorded over 2.5 billion certificates, with daily processing volumes continuing to grow. These detections underscore CT's role in maintaining ecosystem integrity. Furthermore, CT complements revocation mechanisms like and Certificate Revocation Lists (CRLs) by accelerating threat identification, enabling faster responses to potential compromises before they escalate.

Privacy Concerns and Side Effects

Certificate Transparency (CT) logs publicly expose domain names and certificate issuance details, which can reveal sensitive information about an organization's infrastructure. For instance, internal or development subdomains, such as those used for staging environments, become visible to anyone querying the logs, enabling to conduct and map out potential targets for exploitation. This exposure has raised concerns about domain enumeration, where adversaries compile lists of subdomains to identify vulnerabilities or hidden services. Another privacy implication arises from the auditing process, where clients report Signed Certificate Timestamps (SCTs) to verifiers like browser vendors, potentially deanonymizing user browsing behavior. If a user visits a non-public site and encounters a misissued certificate, sending the SCT to a verifier—such as —discloses the visited domain and timestamp, allowing inferences about the user's activities. Early criticisms of CT highlighted these deanonymization risks, particularly for users accessing private or sensitive sites, though proponents argue that the security benefits of detecting misissuances outweigh such concerns when proper safeguards are in place. Beyond privacy, CT introduces operational side effects for Certificate Authorities (CAs) and log operators. CAs must submit every issued certificate to multiple logs, incurring additional computational and bandwidth costs for generating SCTs and handling verifications, which scales with issuance volume. Log operators face similar burdens in processing submissions, maintaining append-only structures, and responding to auditor queries, potentially straining resources during high-traffic periods. A notable risk is denial-of-service (DoS) attacks, where malicious actors flood logs with bogus certificate submissions, overwhelming the system and delaying legitimate entries beyond the Maximum Merge Delay (MMD). Mitigations for these issues are limited by CT's core verifiability requirements. Anonymized submissions are not feasible, as certificates must be signed and verifiable to ensure log , preventing tampering or selective omission. Some logs mitigate by offering delayed publication through the MMD—typically up to 24 hours—giving operators time to review entries before full exposure. For enhancement, proposals include redacting subdomains in logs (revealing only parent domains via commitments) or using zero-knowledge proofs for auditing without disclosing SCT details, though these add complexity and have not been widely adopted. Overall, while CT's transparency has sparked valid criticisms, its design prioritizes ecosystem-wide over individual , with ongoing aiming to refine the balance.

Auditors, Monitors, and Inspection Tools

Auditors in the Certificate Transparency (CT) ecosystem are independent entities or software components responsible for verifying the integrity and compliance of CT logs. They perform checks to ensure that logs maintain their structure, validate signed certificate timestamps (SCTs) using paths, and confirm that certificates are properly included without tampering. For instance, the Certificate Transparency Log Monitor (CTLM) framework provides a curated list of publicly trusted auditors and monitors, integrated into systems like the Trusted Root Program to enforce policy compliance across programs. Tools such as LogChecker enable users to verify whether a specific certificate has been submitted to CT logs by querying log entries and checking for corresponding SCTs. Monitors actively scan CT logs to detect anomalies, track certificate issuances, and ensure visibility of all logged entries. These services synchronize with public logs to build comprehensive datasets, often combining log data with -wide scans to identify suspicious or misissued certificates. Google's Certificate Transparency Monitor, for example, crawls logs to retrieve certificates, excluding expired ones, and supports real-time detection of potential threats. Similarly, Censys maintains an exhaustive certificate repository by synchronizing with CT logs and performing daily scans, allowing users to search for certificates and precertificates while flagging issues like unauthorized issuances. Let's Encrypt's CT is an open-source monitor focused on log operator compliance, targeting 99% uptime and alerting on operational failures such as outages exceeding 24 hours. Other notable monitors include SSLMate's Cert Spotter, which watches for expiring or unauthorized certificates on specified domains and sends alerts via email or webhooks, and services like Monitor and Entrust Search that provide API-based access to log data for broader surveillance. Inspection tools facilitate direct interaction with CT logs, enabling users to search, submit, and analyze certificate data for verification and research purposes. crt.sh, maintained by Sectigo, serves as a prominent web-based for CT logs, allowing queries by domain, organization, or certificate fingerprint ( or SHA-256) to inspect entries across multiple logs. SSLMate's ct-honeybee is a lightweight utility that propagates signed tree heads (STHs) between logs and auditors, aiding in efficient synchronization and compliance checks without manual intervention. The open-source python-ct library from provides Python bindings for CT protocol interactions, including calls to retrieve entries, verify proofs, and build custom inspection scripts. Collectively, these auditors, monitors, and tools play a critical role in the CT ecosystem by detecting log failures—such as incomplete entries or downtime—and tracking high compliance rates, with operators like achieving over 99% submission success and stability in log operations.

Recent Developments

Transition from RFC 6962

The original Certificate Transparency protocol, defined in RFC 6962, has faced significant scalability challenges due to its reliance on monolithic logs stored in relational databases, leading to high operational costs—approaching seven figures annually for large-scale operators—and limited operator participation. These inefficiencies stem from the need to maintain append-only structures with strict availability requirements, including the Maximum Merge Delay (MMD) of up to 24 hours, beyond which logs risk non-compliance and potential distrust by relying parties. In August 2025, Let's Encrypt announced the end-of-life (EOL) for its RFC 6962-compliant logs to address these issues and facilitate a shift to more efficient designs. The EOL timeline for RFC 6962 logs operated by includes a read-only phase starting November 30, 2025, during which no new certificate submissions will be accepted, followed by a complete shutdown on February 28, 2026. CAs using 's logs must migrate submissions to other trusted logs, including those compliant with RFC 6962 or the newer Static CT API. While RFC 9162 obsoletes the experimental RFC 6962 as version 2.0 of the protocol, adoption remains limited, and the scalability enhancements like the Static CT API—featuring tiled structures and batched integrations that eliminate MMD constraints—are compatible with v1 and reduce costs. This migration ensures continued transparency while reducing costs, as new logs using static CT APIs can operate with significantly lower bandwidth and storage demands. To minimize disruption, the transition period incorporates dual-support mechanisms, where emerging RFC 6962-compatible Static CT API logs maintain backward compatibility for Signed Certificate Timestamps (SCTs) and Merkle consistency proofs, allowing existing tools to verify artifacts from both old and new logs during the overlap. CAs must update their submission processes to target trusted logs, with new operators submitting their logs for approval in root programs like those from browser vendors. The phase-out impacts legacy monitoring tools, auditors, and clients that rely solely on RFC 6962 APIs, necessitating software updates for compatibility with Static CT API protocols and endpoints to avoid interruptions in certificate validation and transparency enforcement. End users and typical website operators require no direct action, as browsers and operating systems will enforce the transition through updated policies.

Next-Generation Logs and Innovations

In 2024, introduced , a new Certificate Transparency (CT) log implementation designed for enhanced scalability and reduced operational costs, particularly suited to the increasing prevalence of short-lived certificates. optimizes for short-lived certificates by batching submissions to eliminate the traditional 24-hour merge delay, allowing faster integration and verification without compromising ; this reduces latency risks for certificates with validity periods as short as days. It achieves lower overhead through static tile-based APIs that enable efficient read access via like , avoiding expensive relational databases, with estimated annual costs around $10,000 for a production setup. Additionally, incorporates modern cryptographic practices, including direct embedding of leaf indices in Signed Certificate Timestamps (SCTs) for client-side verification, supporting horizontal scaling across multiple independent logs. Building on similar principles, launched Azul in April 2025 as an open-source, Rust-based CT log implementation compatible with the Static CT API, emphasizing cloud-native deployment on its serverless Workers platform. Azul facilitates simplified operations by adapting the tile-based architecture from , enabling operators to run logs with minimal infrastructure overhead and lower costs through serverless execution. It supports regional sharding, as demonstrated in deployments like the Raio and Nimbus2027 logs, which distribute workloads across 's global edge network for improved resilience and performance. Other innovations in 2024 included independent CT log implementations that further simplified operations via cloud-native designs, such as Trillian Tessera's tile-based approach for cost-effective transparency logs and Itko's dual-support for legacy and modern APIs, enabling broader adoption by reducing setup complexity. These developments aligned with the shift toward shorter certificate lifetimes, with the approving in April 2025 a phased reduction culminating in a maximum of by 2029, necessitating logs capable of handling higher submission volumes efficiently. In September 2025, integrated CT data into its platform, providing domain-security analytics through interactive visualizations of certificate issuance trends, unauthorized issuances, and integration with traffic and security datasets. This update evolved from earlier tools like Merkle Town, offering public access to CT logs for research and penetration testing while addressing the growth in short-lived certificate trends by enhancing auditability and real-time insights.

References

  1. https://www.rfc-editor.org/rfc/rfc9162.html
  2. https://certificate.transparency.dev/
  3. https://www.idmanagement.gov/implement/announcements/03_google_ct/
  4. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/OagRKpVirsA
  5. https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency
  6. https://queue.acm.org/detail.cfm?id=2668154
  7. https://datatracker.ietf.org/doc/html/rfc6962
  8. https://www.rfc-editor.org/rfc/rfc6962.html
  9. https://www.digicert.com/blog/certificate-transparency-required-ev-certificates-show-green-address-bar-chrome
  10. https://groups.google.com/a/chromium.org/g/ct-policy/c/Qqr59r6yn1A
  11. https://community.letsencrypt.org/t/signed-certificate-timestamps-embedded-in-certificates/57187
  12. https://www.thesslstore.com/blog/apple-certificate-transparency-october-15/
  13. https://googlechrome.github.io/CertificateTransparency/ct_policy.html
  14. https://support.apple.com/en-us/103703
  15. https://datatracker.ietf.org/doc/html/rfc9162#section-2.1.1
  16. https://datatracker.ietf.org/doc/html/rfc9162#section-4.5
  17. https://datatracker.ietf.org/doc/html/rfc9162#section-5.3
  18. https://datatracker.ietf.org/doc/html/rfc9162#section-5.4
  19. https://datatracker.ietf.org/doc/html/rfc9162#section-4.4
  20. https://datatracker.ietf.org/doc/html/rfc9162#section-3.5
  21. https://datatracker.ietf.org/doc/html/rfc9162#section-4.3
  22. https://datatracker.ietf.org/doc/html/rfc9162#section-7.3
  23. https://googlechrome.github.io/CertificateTransparency/log_policy.html
  24. https://letsencrypt.org/2019/11/20/how-le-runs-ct-logs.html
  25. https://letsencrypt.org/docs/ct-logs/
  26. https://letsencrypt.org/2022/05/19/nurturing-ct-log-growth
  27. https://www.firefox.com/en-US/firefox/135.0/releasenotes/
  28. https://googlechrome.github.io/CertificateTransparency/
  29. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
  30. https://learn.microsoft.com/en-us/security/trusted-root/2025/february-2025
  31. https://learn.microsoft.com/en-us/security/trusted-root/program-requirements
  32. https://ct.googleapis.com/logs/us1/argon2025h2/
  33. https://ct.googleapis.com/logs/eu1/xenon2025h2/
  34. https://letsencrypt.org/2019/05/15/introducing-oak-ct-log
  35. https://letsencrypt.org/2024/03/14/introducing-sunlight
  36. https://blog.cloudflare.com/azul-certificate-transparency-log/
  37. https://wyvern.ct.digicert.com/2025h2/
  38. https://sslmate.com/resources/certspotter_stats
  39. https://blog.cloudflare.com/new-regional-internet-traffic-and-certificate-transparency-insights-on-radar/
  40. https://blog.transparency.dev/ct-in-firefox
  41. https://blogs.opera.com/security/2015/10/misissued-certificates/
  42. https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3b.pdf
  43. https://jhalderm.com/pub/papers/misissuance-sp18.pdf
  44. https://www.digicert.com/faq/certificate-transparency/what-is-certificate-transparency
  45. https://www.inforsec.org/wp/wp-content/uploads/2020/04/CCS2019-Li.pdf
  46. https://www.petsymposium.org/2017/papers/issue4/paper69-2017-4-source.pdf
  47. https://www.ssl.com/article/certificate-transparency/
  48. https://crypto.stanford.edu/~saba/slides/ctpriv.pdf
  49. https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/
  50. https://groups.google.com/a/chromium.org/g/ct-policy/c/_eXIfMf7LQQ/m/lBfMEWojBwAJ
  51. https://datatracker.ietf.org/doc/html/rfc9162
  52. https://www.ndss-symposium.org/wp-content/uploads/2024-834-paper.pdf
  53. https://learn.microsoft.com/en-us/security/trusted-root/2025/may-2025
  54. https://decoder.link/certificate_transparency
  55. https://docs.censys.com/docs/ls-ct-precerts
  56. https://sslmate.com/certspotter/
  57. https://crt.sh/
  58. https://www.agwa.name/blog/post/four_years_of_sslmate
  59. https://github.com/google/certificate-transparency
  60. https://letsencrypt.org/2025/08/14/rfc-6962-logs-eol
  61. https://letsencrypt.org/2025/06/11/reflections-on-a-year-of-sunlight
  62. https://groups.google.com/a/chromium.org/g/ct-policy/c/dVz6tMLWsRY
  63. https://blog.transparency.dev/introducing-trillian-tessera
  64. https://blog.transparency.dev/i-built-a-new-certificate-transparency-log-in-2024-heres-what-i-learned
  65. https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.