What Does the Padlock in Your Address Bar Actually Guarantee? — Instead of Picking a Trustworthy Authority, the Web Decided to Write Every Issuance Down

The Question of Verifying Without a Middleman, and One Mechanism Already Running

This series has continuously asked one question: Can we verify something without trusting a middleman.

The answers so far have largely been "It is possible, but we are not quite there yet." In "Is Blockchain Really Decentralized", even when the theory of consensus was solid, power reconvened layer by layer in practice. In "Zero-Knowledge Proofs: Proving the Truth Without Revealing the Data", the most efficient family of tools for proving without revealing contents left behind a setup secret that required a new leap of faith, and the family that eliminated that secret traded away efficiency. In "If We Voted on a Blockchain, Nobody Could Tamper With It", making things verifiable collided head-on with the secrecy of the ballot. Elegant designs failed to leave the laboratory, or remained small-scale even when they did.

Yet there is a mechanism that achieves "don't trust, verify" without a blockchain, and it is already deployed on the web. It is a mechanism adopted by several major browser companies (arXiv:1806.08817, as of 2018, preprint). Its name is Certificate Transparency (CT for short), and it forces every single certificate issued to a website to be recorded in a public ledger that anyone can read.

This article traces what that mechanism has achieved and what it has failed to achieve. The conclusion comes first: Putting a verification mechanism in place and actually having things verified are two different things. CT has widely achieved the first half, while the second half is still under debate.

Articles uploaded to arXiv, SSRN, and TechRxiv are designated as preprints, meaning papers published before peer review, and whether they were subsequently published in academic journals or conferences was not checked.

What We Commonly Believe the Padlock Guarantees

When a padlock appears in the address bar, we are commonly taught that it means two things: that the communication is encrypted, and that the other party is truly that site. The first half is mostly correct, and the tricky half is the second half.

The second half leans on certificates. In the definition from "Keys and Locks — Why a Public Key Is Safe to Publish", a certificate is a document where a third party has signed that this public key belongs to this person. A Certificate Authority (CA for short) is an entity that signs a certificate with its own private key to vouch for the owner of that public key. On the web, this certificate vouches that "the owner of this domain name, in other words this site address, is indeed the owner of this public key." The integrity and trust of the web stand upon this certificate in a standard format called X.509 (arXiv:2407.02287, preprint).

A root store is a list of CAs that browsers and operating systems have decided to trust and carry around. Institutions on this list are called root CAs. If it is a certificate signed by an institution inside the list, the browser displays the padlock.

Therefore, writing the common belief accurately yields "we just need to pick trustworthy institutions well." It is not a bad starting point, but the problem is what "picking well" means in this structure.

Trust Is Determined by the Weakest Link

Different software products have different root stores, and a single store usually contains hundreds of roots. Every single one of those roots can issue a "trusted" certificate for any domain (arXiv:2001.04319, preprint). A root CA can also delegate issuing authority to intermediate CAs, which are other organizations placed beneath it. Therefore, it is difficult for an end user to discern which organization is truly trustworthy (DOI: 10.1142/s0218126623501037, published in a general engineering journal).

If we write this structure in one sentence, it is this: In the Web PKI, the web's trust system woven with certificate authorities and certificates, every CA is trusted equally, and security is determined by the weakest link (arXiv:2108.08581, 2021 preprint).

The security of my site is determined by whether someone else can obtain a certificate under my domain name. No matter how thorough the organization I chose is, if one other organization in the list issues a certificate in my name, that certificate is trusted just the same.

When a Single Organization Is Compromised

There was an incident where at least 531 fraudulent certificates were issued by a single Certificate Authority. That organization knew its system had been breached for over a month and did not even possess the complete records of the improperly issued certificates, so the final tally will never be known (DOI: 10.1145/2668152.2668154, a contribution to a practical magazine rather than an academic journal).

Analyses on the policy and regulation side point out the structure in that same event. Out of 650 Certificate Authorities scattered across 54 jurisdictions at the time, succeeding in breaching just a single one allowed the attacker to forge false certificates for any website or service. During the 90 days that the breach went unknown, browsers continued to trust that organization's certificates, and in the meantime, the attacker was able to intercept communications for roughly 300,000 people. In the authors' words, each CA is a single point of failure for the security of the entire ecosystem (DOI: 10.2139/ssrn.2031409, SSRN preprint).

With false certificates, the man-in-the-middle attack described in "Keys and Locks" becomes possible—an attack where someone stuck in the middle pretends to be the other party to both sides. The person in the middle presents a certificate that looks like the real site's certificate, and the browser accepts it because an organization inside its list signed it.

This article does not deal with the behind-the-scenes or the locations of that incident. We only look at the fact that it was a structure where if one shook, everything shook.

Why "Who to Trust" Cannot Solve It

This flaw does not lie only in the technology. The structural flaws of the CA trust model span law, economics, and organization (DOI: 10.2139/ssrn.2249042, SSRN preprint).

A study re-examining the certificate authority ecosystem writes more painfully. It states that while we took a big step toward encrypting all communications, we lost trust in the task of verifying whether the communication counterpart is genuine. The authors trace the root of the remaining problems to misaligned incentives among participants, meaning directions where each profits diverge from one another. And they view that the security extensions proposed up to that point fail to properly correct those incentives (arXiv:1801.00933, preprint).

The options held by the browser are also crude. A client is a program like a browser that runs on the user side and accesses sites. In the web PKI, when a client encounters a suspicious CA, the only thing it can do is completely distrust that organization. Then collateral damage occurs where even faultless certificates issued by that organization are rejected all at once (arXiv:2108.08581). Since trust is only two values, on and off, the responses are also only two values.

Instead of Choosing the Institution, Write Down What Was Issued

This is where the direction turns, and this turn is what this series has been continuously searching for.

The goal of CT is to store all issued certificates in a public log so that anyone can check whether there are any certificates that might have been misissued (DOI: 10.56553/popets-2022-0075). Here, the log is the ledger described in "What Is a Blockchain — Why a Ledger With No One in Charge Holds Up", in other words, a record listing who did what and when in the order it happened. CT logs store certificates in a public, auditable, and append-only manner (arXiv:2001.04319, preprint). Append-only is a property where you can only add to the back, and you cannot fix or erase what has already been written.

The nature of this shift is captured precisely in a sentence from a privacy conference paper. It states that major browsers have begun to mandate CT log records in addition to certificate authority signatures to move past the security of the CA ecosystem's weakest link (DOI: 10.2478/popets-2021-0024).

The resulting answer is this. Write down everything about who issued what, and let anyone read it. Instead of vetting the qualifications of the institution, its actions are left as a record.

There is also a sentence that does not inflate what this design promises. Trust in publicly verifiable CT logs is reduced through cryptography, gossip, auditing, and monitoring (arXiv:1711.03952, preprint). Gossip is the procedure, to be covered later, where everyone cross-checks the logs they have seen with each other. The verb this sentence chose is "reduced". The rest of this article follows where the trust that remains after being reduced resides.

Merkle Trees — How to Check Short Logs That Show Tampering

Let us imagine that eight certificates are written in a log. For each certificate, we take a hash of the kind explained in "What Is a Blockchain — Why a Ledger With No One in Charge Holds Up". A hash takes a piece of writing of any length and shrinks it down to a single short value of a fixed length, where the same writing always produces the same value, and changing even a single letter changes the value entirely.

If we take two neighboring hashes, glue them together, and hash them again, we get four values; repeating the same process leaves us with two, and then one. We call the single value left at the top the root. A Merkle tree is a data structure built by pairing up data with hashes like this all the way up to make a single value at the top. Change just one letter in a single certificate at the very bottom, and the values going up change one after another, altering the root. The log signs this root and makes it public.

There is a study that translates the CT protocol precisely into a model up to the Merkle tree and tests for the first time with a mathematical proof whether the properties that must be preserved are indeed preserved. This study points to two things that a Merkle tree gives: a concise proof that data is there, and a concise proof that the tree has grown (arXiv:2303.04500, preprint).

An inclusion proof is a proof showing that a certain certificate is inside this log using only a few hashes, without downloading the entire log. If we want to check whether the third certificate is among the eight, we only need to receive three hashes that sit beside the path going up from the third certificate to the root. If we recalculate the root using the hash of the third certificate and those three, and it matches the published root, then the third certificate is in the log.

A consistency proof is a proof showing that the current log is simply an extension appended to the end of a past log. Let us imagine someone who remembered the root when there were four certificates yesterday. Today, the log can present a few hashes from an eight-certificate tree to show that yesterday's four certificates remain intact at the very front. If even one of yesterday's four certificates had been altered or deleted, yesterday's root would not come out again, so this proof would fail.

The proof grows very slowly even as certificates increase. The size grows by roughly one hash every time the number of certificates doubles, and this kind of growth is called logarithmic (the log here is the name of a mathematical function, not a ledger). All CT configurations known around 2017 used Merkle trees so that the proof size was logarithmic relative to the number of certificates, and there are cryptographic attempts to reduce this size to a constant size independent of the number of certificates (arXiv:1704.04937, preprint).

If everyone looks at the same log and actually checks its proofs, there is no need to trust that the log operator is honest; "if you lie, you get caught" is enough. Whether that condition is actually met is revisited below in "Remaining Issues". This is precisely the property that "What Is a Blockchain — Why a Ledger With No One in Charge Holds Up" called tamper detection—that is, a property that does not prevent tampering, but ensures the fact of tampering is exposed. This is also precisely what the phrase "reducing trust" means. The kind of trust has changed. It shifted from "this operator will not do bad things" to "if this operator does bad things, traces will be left behind."

This property is not unique to CT. Relative timestamps, which guarantee that a record existed before another, and append-only logs are two lines of work that have been studied almost separately, but one systematization paper summarizes the two as two sides of the same coin: certification of a prefix relation. A prefix relation is a relation where old records are contained as-is in the front part of current records. The graph type defined in this paper encompasses all hash-based timestamp and log designs known to the authors (arXiv:2308.13836, preprint). "The past must be the front part of the present" is the common backbone of this entire lineage.

Connecting things with hashes so that altering the past leaves a trace is just like the notebook in "What Is a Blockchain — Why a Ledger With No One in Charge Holds Up". However, deployed CT logs currently lack a consensus of witnesses where multiple parties decide what the true record is. A single log is written by its operator, and other people read and check that log. Therefore, we must separately check whether everyone is looking at the same version, and this issue comes up again in "Remaining Issue ②".

SCT — A Promise Note Written by the Log

When a certificate is submitted to a log, the log returns an SCT (Signed Certificate Timestamp). An SCT is a promise note signed by the log stating, "We will put this certificate into the log within a specified time."

This note became the handle that enforces CT. Browsers simply need to refuse certificates without an attached SCT, which leaves CAs with no choice but to put certificates into logs. As we saw earlier, browsers began to mandate CT log records in addition to CA signatures using this method (DOI: 10.2478/popets-2021-0024).

Here lies the core crack of this article. An SCT is a promise, not proof of having entered the log. Whether a certificate actually went into the log must be verified later by receiving an inclusion proof. SCT auditing is the work of verifying whether a certificate that received such a promise note actually went into the log. How much this auditing actually happens is revisited below.

Monitors and Auditors — Two Roles for Reading Logs

CT splits the work of watching logs into two.

A monitor watches every single log entry without missing one, looking for suspicious certificates they care about (arXiv:1711.03952, preprint). For a domain owner, this means looking to see if a certificate with their domain name was issued that they did not request. Anyone can run a monitor, but it must be run without stopping and you must also hold a copy of the log.

Because the burden is heavy, proxy businesses have emerged. Monitoring-as-a-service is a service where a trusted third party runs the monitor instead, and sends filtered alerts to registered users, such as "let me know if a foo.com certificate is issued." A trusted third party has stepped back into a system created to reduce trust. Therefore, extensions have been proposed to allow recipients to verify whether those alerts are accurate without missing anything. This is an attempt to reduce the trust placed in the proxy once again (arXiv:1711.03952).

An auditor checks whether a log is behaving consistently and honestly. As of 2015, this was precisely what log-based systems still lacked: a way for clients to verify the consistency and honesty of logs (arXiv:1511.01514, preprint).

Devices That Block and Devices That Reveal

CT does not prevent misissuance; it reveals it. What log-based methods like CT do is make fraudulent certificates visible to anyone (arXiv:1511.01514).

The blocking-side device is separate. DNS is the internet's address book that turns domain names into actual server addresses. CAA is a safety device where a domain owner writes in their DNS, "Only this CA can issue certificates for my domain." However, flaws in CAA's concept and operation chip away at its effectiveness in preventing misissuance (arXiv:2411.07702, preprint).

Measurements tracking 4 million popular domains are more specific (arXiv:2407.02287, preprint). CAA was largely deployed correctly in format, but the written strings tended not to pick and choose among CAs. And countless domains held certificates outside the scope permitted by their CAA.

It also misaligned with other devices protecting DNS. DNSSEC is a device that attaches signatures to DNS records to prevent forgery. CAA was deployed almost entirely where DNSSEC was absent, and conversely, names protected by DNSSEC tended not to use DNS to protect certificates. DANE's TLSA records, which write certificate information directly into DNS, suffered from repeatedly sloppy management and were sometimes without DNSSEC (arXiv:2407.02287).

Placing a device and that device actually doing the work are two different things. This sentence now returns to CT itself.

Remaining Problem ① — Clients Do Not Check

The core requirement of CT is that a given certificate is actually in one or more logs. However, a 2022 privacy symposium paper that systematized this problem describes the deployment state at the time as follows: most individual clients do not check whether a certificate they saw is in a log (DOI: 10.56553/popets-2022-0075).

The stumbling block is privacy. If a client directly requests a proof of inclusion from a log, the specific certificate they are asking about is exposed as-is, which is equivalent to revealing which site that user visited. It is a structure where you have to give up your privacy in order to check.

Therefore, various techniques have been proposed to audit while protecting privacy. There is a method that allows browsers to audit CT logs without violating user privacy (DOI: 10.1515/popets-2017-0052). There are also attempts to hide queries using an oblivious file-sharing system equipped with strong anonymity—in other words, a file-sharing method that prevents even the server from knowing who is taking what (arXiv:1905.09478, preprint).

After reviewing the proposals, the same systematization paper points out yet another limitation. Many proposals focus solely on the exchanges between the client and the log, while leaving open how a client can privately report the fact that they 「saw a certificate not in the log」 (DOI: 10.56553/popets-2022-0075).

If you check, find an anomaly, but have no way to speak up, the check is only half done.

Remaining Issue ② — Is Everyone Looking at the Same Log?

Consistency proofs connect the log I saw yesterday with the log I saw today. They do not tell us whether the log I saw is the same as the log someone else saw.

In theory, you do not need to trust a CT log. But that premise relies on one condition: that all clients look at the same log and verify it cryptographically. That is why practical implementation requires gossip in some form. Gossip is a procedure where clients compare the logs they each saw with one another. And this has been a long-standing unresolved problem in CT. As of 2018, even though several major browser companies had adopted CT, no widely deployed gossip method existed (arXiv:1806.08817, preprint).

A split-view is an attack where a log shows a different version only to a target. It is also called a split-world attack. The target finds nothing amiss within the log they see, and the rest of the world does not know what the target is seeing. If this attack is possible, the guarantees of log-based PKI collapse. The criticism that log-based PKI improvement proposals remain vulnerable to this attack is repeated in multiple places (arXiv:1806.03914, preprint; DOI: 10.1002/dac.4503).

From the research that first proposed gossip protocols, it was noted that this task of clients verifying logs is difficult because of privacy, efficiency, and deployability (arXiv:1511.01514). Subsequent proposals are creative. There is a design where network equipment like routers or switches passively collect cryptographic material that CT logs output unencrypted as it passes by, and then periodically verify log consistency out-of-band. This is a method where the network provides gossip as a service.

The evaluation of this design released in 2018 used 20 days of measurements. Those measurements represent 3,500 autonomous systems and clients spanning 40% of the IPv4 address space. An autonomous system is an independent network unit of the Internet managed by a single administrative entity, like a telecommunications carrier or a university. Based on these measurements, the authors report that merely deploying this method incrementally achieves meaningful defense against split-view logs in a realistic threat model. They also demonstrated an implementation capable of running at 10 Gbps line rates on router- and switch-grade hardware (arXiv:1806.08817, preprint). Proposals exist, but as of 2018–2020 when the studies cited by this article came out, widely deployed gossip did not.

There is also a more fundamental criticism. Most proposals assume a global auditor set, meaning a group of auditors who will inspect all logs on behalf of everyone. And to achieve the targeted transparency, one must blindly trust that they will do their jobs. That is why gossip protocols and verifiable registries that allow users to audit for themselves have been proposed (arXiv:2011.04551, preprint).

Where trust is removed, trust creeps back in. This is a pattern we have seen several times in this series.

Remaining Problem ③ — Trust Left in the Hands of Log Operators

According to a 2021 privacy conference paper, CT rests on a distributed system shared across multiple logs, but the accuracy of those logs was not being sufficiently protected. A covert attacker who has compromised both a CA and its corresponding log can still issue fraudulent certificates without getting caught (DOI: 10.2478/popets-2021-0066).

As a countermeasure, a design in which logs collaborate has been proposed. It groups multiple logs together, and when one randomly selected log among them enters a certificate, the rest watch the issuance process and attest to it. This allows logs to audit each other without a trusted third party, and an attacker would have to compromise every single participating witness (DOI: 10.2478/popets-2021-0066).

There is also a little-known fact. CT logs maintain their own root lists. With the introduction of CT, the trust landscape shifted, and logs came to maintain their own trusted root lists and record only certificates that chain back to those roots. The study that first mapped out this new landscape compared the root lists of logs with one another, as well as with the root stores of major software companies. And it showed that poor management of root lists can lead to misconduct by logs (arXiv:2001.04319, preprint).

A 2021 paper proposing a design to mount CT on an anonymous browsing network sums up the problem in one sentence. The CT deployment at the time lacked strong mechanisms to verify whether log operators behaved according to the rules (DOI: 10.2478/popets-2021-0024). Concluding that the enforced CT deployment at the time relied on blind trust, the same paper puts forward a design that probabilistically catches and exposes evidence of wrongdoing by CAs and logs.

Alternative designs are numerous. There is a proposal to eliminate split-views by placing CT on top of a blockchain (arXiv:1806.03914, preprint). There are also alternative PKIs with verifiable trusted parties (DOI: 10.1155/2018/8527010), and decentralized audits running on the client side (DOI: 10.3390/cryptography5020014). Another approach enables servers to automatically detect certificate swap attacks and infer their source (DOI: 10.1049/iet-ifs.2016.0611). There is also a proposal to introduce "trust heterogeneity," where domain owners and clients each set their own issuance and verification policies so that different parties use different trust criteria (arXiv:2108.08581).

A sentence written in 2018 by one of the papers in this list explains the situation of this entire lineage. Although various solutions have been proposed to solve this problem, none have been widely adopted yet due to issues of complexity and deployability (DOI: 10.1049/iet-ifs.2016.0611).

We can inversely deduce from this why CT took root. In areas where alternatives got bogged down by complexity and deployability, CT could be enforced solely through browser policies.

Remaining Problem ④ — The Cost of Disclosure

The number of certificates piled into CT logs grew exponentially, and site support for CT grew steadily as well. A 2018 measurement found that 33% of established connections supported CT (arXiv:1809.08325, preprint). That success bred a new problem. The certificates recorded in the logs contain domain names, and the very fact that all certificates are visible in CT logs becomes a channel for information leakage.

The same study confirmed this experimentally. The authors built a CT honeypot. A honeypot is a decoy left intentionally; here, it is a setup where a certificate is issued but that name is kept secret from everywhere while watching who comes looking. The results are as follows. Just minutes after a certificate was issued, CT log data was being used to select targets for a scanning campaign (arXiv:1809.08325, preprint). A scanning campaign is an activity that sweeps through machines on the internet one by one to find places to attack.

Even names intended for use only within an organization go up on the public ledger the moment they receive a certificate. Sub-names attached in front of a domain, like vpn-test in vpn-test.mycompany.com, are called subdomains, and names like this leak what that organization operates and tests. The authors went a step further and presented a method to learn and verify new subdomains from the vast domains recorded in CT (arXiv:1809.08325).

So proposals emerged to expand CT to support private subdomains (DOI: 10.1515/popets-2017-0052). This cost shares a root with ①. Verification demands disclosure, and disclosure demands a price. The privacy of the client doing the verifying and the privacy of the domain owner being verified pay the price together.

Remaining Problem ⑤ — Revocation, the Area CT Does Not Cover

CT does not prevent issuance, and there is also one major area that CT does not cover at all: revocation. As defined in "Keys and Locks — Why a Public Key Is Safe to Publish", revocation is the act of invalidating an issued certificate before its expiration date. Even if CT exposes a wrongful issuance, invalidating that certificate and communicating that fact to browsers worldwide are separate matters.

That spot is empty. As of 2021, a procedure corresponding to CT for certificate issuance—namely, a procedure to record a transparent and immutable history of all revocations—has never been adopted (arXiv:2102.04288, preprint). The same study examined over 1 million revoked certificates and, for the first time, tracked their history over a long period from when the certificates expired until the revocation status information disappeared. Among them, 773,000 were revoked all at once by a single certificate authority. The study showed with figures how briefly revocation status remains and how differently each authority practices revocation.

That revocation is difficult is an old story. Work classifying and analyzing the pros and cons of revocation methods came out over 20 years ago (DOI: 10.1145/956981.956991), and a 2026 comprehensive survey summarizes that major revocation methods have shown limitations in various aspects such as privacy and scalability (DOI: 10.1145/3785653).

One more circumstance overlaps. TLS is the protocol introduced in "Keys and Locks — Why a Public Key Is Safe to Publish" that establishes and protects the connection between a browser and a site. Most traditional revocation methods carry latency, availability, and privacy problems, and the problem grows because TLS lacks a built-in delegation mechanism. Delegation is when a domain owner grants someone else the right to serve that site on their behalf without handing over their private key. Lacking this mechanism, domain owners are increasingly driven into the dangerous practice of sharing their private keys with third parties (arXiv:1906.10775, preprint).

After evaluating revocation and delegation methods, the same study concludes that bundling short-lived delegation credentials or proxy certificates with a proper revocation system solves several urgent problems. Rather than there being no answer, from the perspective of this 2019 study, the pieces of the answer were already out there, and the remaining task was to assemble and deploy them. No matter how well verification mechanisms are designed, if nobody knows how many places a private key is copied to, its usefulness diminishes.

Proposals to attach transparency to revocation also exist. Post-certificates are certificates where the certificate owner submits directly to an existing CT log without going through the issuing CA, initiating the revocation process themselves. The CA must monitor the CT log and proceed with revocation upon discovering a post-certificate. The authors argue that deployment costs are low because they reuse existing CT logs as they are (arXiv:2203.02280, preprint).

Remaining Problem ⑥ — People

Flawed TLS certificates are not rare on the internet, and most stem from harmless causes like configuration mistakes or intentional deployments. That blurs the judgment on whether to trust a connection or not (arXiv:2207.11610, preprint). The final link is the person, and this link is the hardest to handle.

A study observing 75 industry IT conference participants as they investigated various certificate validation errors reports three things. First, IT professionals' views were highly nuanced, and trust judgments were far from binary. Second, self-signed certificates signed by the users themselves and name-constraint certificates that restrict the range of usable names in advance tended to be trusted more than they actually deserved, and name-constraint certificates were poorly understood. Third, even tiny tweaks to existing error messages shifted data utilization, comprehension, and trust judgments for the better (arXiv:2207.11610, preprint).

The third item is important. "People don't check" is not a constant dropped from the sky, but a variable that can be moved through design.

Certificate-issuing software is also subject to inspection. ACME is a standard protocol that automatically handles domain verification and certificate issuance. A preprint analyzing developer-written tests across four open-source CA implementations following ACME reports that the tests cover a narrow range of the protocol (39.5% of protocol operations, 25.6% of error handling). Regression tests, which check whether a protocol bug returns when fixed, were also rarely added. The authors raised both ranges to 100% using a generator that extracts behavioral models from the specification and follows states to create tests, finding three bugs that had never been reported before (DOI: 10.36227/techrxiv.176972158.85579194/v1, TechRxiv preprint). Certificate-verifying implementations also harbor latent flaws that only emerge when rules are extracted from standard documents and tested across multiple implementations against each other (DOI: 10.1145/3355048).

What It Actually Achieved Despite All That

If it ends only with criticism, this article is half-baked. CT quietly pulled off one very big thing. Once public records came into existence, watchers who found other uses besides issuance monitoring appeared.

Classification pipelines have emerged that read CT logs in real time to catch phishing sites under preparation during the certificate issuance stage. The conventional approach of adding already exposed sites to a blocklist leaves attackers a "window of opportunity," but the idea is to capture the moment a site is created via logs to narrow that window. What the authors tested and confirmed with several classifiers is the room to improve classifiers going forward (arXiv:2106.12343, preprint).

Detection techniques for finding weird certificates that are not filtered out by standard compliance checks have been validated with a sample of CT logs (arXiv:2405.05206, preprint). A system that ties the CT stream to browser rendering and semantic analysis to classify new sites in real time reports processing 8.51 million X.509 records for 23.83 hours (DOI: 10.47813/2782-5280-2026-5-3-1001-1014, published in a small regional journal).

All three of these were possible because the logs are public. Phishing detection and new-site classification are especially cases where the utility expanded outside CT's goal of finding misissuances.

The certificate ecosystem itself became material for monitoring. DNS tampering is when actors like censors change the responses in an address book to block or intercept user access. A study that used TLS certificates as a verifiable signal to catch DNS tampering found that 55 autonomous systems across 26 countries are tampering with DNS at the carrier level. It also identified 17 commercial DNS filtering products used in 52 countries and a bundle of 226 new block pages that prior research did not cover. The consistency-based heuristic used by prior research had a 72.45% false positive rate among cases detected as DNS tampering (arXiv:2305.08189, preprint).

A paper systematizing log-based transparency technology overall organizes the goals, usefulness, and pitfalls of transparency. At the same time, it covers how transparency connects to external devices—namely, devices that allow raising objections to the system and holding operators accountable (arXiv:2305.01378, preprint). Logs are merely inputs to those external devices, and the logs themselves hold no one accountable.

There are institutional achievements as well. There is a non-governmental forum where CAs that create certificates and browser companies build baseline requirements for issuance together, as well as create and enforce CT itself. There is a governance study that collected 369 meeting minutes of this forum from 2013 to 2022, analyzing attendance records of 553 people from 123 organizations and 192 votes. This study explains why this cooperation stays stable through the incentive structures of the participants (DOI: 10.2139/ssrn.4528663, SSRN preprint). For verifiability to become a practice, there must be institutions that sustain that practice.

There are also remaining worries. A 2025 preprint investigating domain certificates of BRICS countries and the European Union reports that for both sides, over 75% are issued by CAs based in the United States, outside both regions. The authors view this high external dependence as a risk to digital sovereignty (arXiv:2504.16897, preprint). Even though trust was turned into records, issuance itself is still concentrated in narrow places.

Verifiability Is a Practice, Not a Device

We can sum it up in three sentences.

First, this problem cannot be solved by asking "whom should we trust?" In a structure where every CA is trusted equally, security is determined by its weakest link. If even one of the hundreds inside the root list is shaken, a certificate for any domain can be forged, and when one actually was shaken, that one was enough.

Second, the solution therefore shifted from choosing institutions to publishing records. Every issuance is written to an append-only log, inclusion proofs and consistency proofs make it so that "if you lie, you get caught," an SCT promise ticket forces browsers to enforce this, and monitors and auditors are made to read it. This was achieved without a blockchain-style ledger or witness consensus rules, and it is already deployed across the web.

Third, nothing happens just because things are written down. As of 2022, in deployments, most clients did not check whether the certificate they saw was in the log. Gossip to match whether everyone is looking at the same log has not been widely deployed. There is also no strong mechanism to verify whether log operators behave according to the rules. The verification devices were put in place, and verification still happens only partially.

There are also things left over. CT does not block issuance; it only exposes it. Revocation still lacks transparency equivalent to CT. Public logs are open equally to those who protect and those who hunt for targets, and in honeypot experiments, that time lag was a matter of minutes. And all the figures in this article are values observed by each study at its own point in time using its own methods. It has already been pointed out that conflicting measurement results in this field are rooted more in differences in measurement setups than in actual deployment differences (arXiv:2401.18053, preprint). Deployment states continue to move even after this article is written.

So the answer CT gives to the question of this series is this:

What must we trust — that the log operators follow the rules, and that someone is actually reading that log. What can we verify — the fact that a certificate was issued, and the fact that the log has not altered its own past.

The first list has become shorter than the second list. That is what CT did. And the fact that the first list is not yet empty, that is the work still remaining.

Verifiability is a practice that only holds true when someone actually reads.

Source Papers

• "Certificate Transparency" (2014) — DOI: 10.1145/2668152.2668154 (industry magazine article) — A single certificate authority issued at least 531 fraudulent certificates, knew about the compromise for over a month, and lacked even a complete record of the misissued certificates.
• "Certificate Authority Collapse: Regulating Systemic Vulnerabilities in the HTTPS Value Chain" (2012) — DOI: 10.2139/ssrn.2031409 (preprint) — If even one of 650 CAs across 54 jurisdictions is breached, fake certificates can be generated for arbitrary sites. 90 days of silence, intercepting communications for roughly 300,000 people. Each CA is a single point of failure.
• "F-PKI: Enabling Innovation and Trust Flexibility in the HTTPS Public-Key Infrastructure" (2021) — arXiv:2108.08581 (preprint) — All CAs are trusted equally and security is defined by the weakest link. The client's only option is "complete distrust," resulting in collateral damage.
• "Characterizing the Root Landscape of Certificate Transparency Logs" (2020) — arXiv:2001.04319 (preprint) — Each root store has hundreds of roots, each capable of issuing for any domain. CT logs also maintain their own root lists, and mismanagement of those can tie into log misconduct.
• "Trust Darknet: Control and Compromise in the Internet's Certificate Authority Model" (2013) — DOI: 10.2139/ssrn.2249042 (preprint) — The flaws in the CA trust model span law, economics, and organization, not just technology.
• "New Directions for Trust in the Certificate Authority Ecosystem" (2018) — arXiv:1801.00933 (preprint) — Progress in universal encryption came at the cost of trust in peer authentication, misaligned incentives are at the root of the structural problem, and proposed extensions fail to realign them.
• "A Secure Two-Tier Domain Verification and Certificate Validation…" (2022) — DOI: 10.1142/s0218126623501037 (general engineering journal) — Any CA can issue certificates for any entity on the internet, making it hard for end users to determine whether to trust them.
• "SoK: SCT Auditing in Certificate Transparency" (2022) — DOI: 10.56553/popets-2022-0075 — The goals of CT and the reality of SCT auditing. Most individual clients do not verify the log presence of certificates because requesting a proof of inclusion is itself a privacy invasion. Proposed solutions leave open the question of "how to report a missing certificate privately."
• "Privacy-Preserving & Incrementally-Deployable Support for Certificate Transparency in Tor" (2021) — DOI: 10.2478/popets-2021-0024 — Browsers mandate CT logging to overcome the security of the CA ecosystem's weakest link. Current CT deployments lack strong mechanisms to verify whether log operators behave according to rules.
• "Verifiable Light-Weight Monitoring for Certificate Transparency Logs" (2017) — arXiv:1711.03952 (preprint) — Trust in CT logs is "reduced" through cryptography, gossip, auditing, and monitoring. The role of monitors, the trust issues of monitoring-as-a-service, and extensions to make their alerts verifiable.
• "Automatic verification of transparency protocols (extended version)" (2023) — arXiv:2303.04500 (preprint) — What Merkle trees provide are "concise proofs of data existence" and "concise proofs of tree extension." The first formal verification of CT modeling Merkle trees precisely.
• "SoK: Authenticated Prefix Relations — A Unified Perspective On Relative Time-Stamping and Append-Only Logs" (2023) — arXiv:2308.13836 (preprint) — Relative timestamps and append-only logs are two sides of the same coin: authenticated prefix relations.
• "Certificate Transparency with Enhancements and Short Proofs" (2017) — arXiv:1704.04937 (preprint) — Proof size in existing constructions scales logarithmically with the number of certificates. An alternative targeting constant-size proofs.
• "A Call to Reconsider Certification Authority Authorization (CAA)" (2024) — arXiv:2411.07702 (preprint) — Conceptual and operational flaws in CAA undermine its misissuance prevention effectiveness.
• "Do CAA, CT, and DANE Interlink in Certificate Deployments? A Web PKI Measurement Study" (2024) — arXiv:2407.02287 (preprint) — Empirical measurement of 4 million popular domains. CAA is deployed almost exclusively in environments lacking DNSSEC, and numerous domains hold certificates outside their CAA scope. TLSA suffers from poor management.
• "Efficient Gossip Protocols for Verifying the Consistency of Certificate Logs" (2015) — arXiv:1511.01514 (preprint) — The lack of a way for clients to verify whether logs are behaving consistently and honestly. The proposal of the first gossip protocol and the challenges of privacy, efficiency, and deployability.
• "Aggregation-Based Certificate Transparency Gossip" (2018) — arXiv:1806.08817 (preprint) — Despite major browsers adopting CT, no gossip mechanism is widely deployed. A design where network equipment provides gossip as a service, measured over 20 days across 3,500 ASes and 40% of IPv4.
• "Think Global, Act Local: Gossip and Client Audits in Verifiable Data Structures" (2020) — arXiv:2011.04551 (preprint) — Existing gossip proposals assume a global set of auditors and require trusting them blindly. A protocol and verifiable registry that allow users to audit for themselves.
• "CertLedger: A New PKI Model with Certificate Transparency Based on Blockchain" (2018) — arXiv:1806.03914 (preprint) — Log-based PKI improvements remain vulnerable to split-world attacks.
• "SCM: Secure and accountable TLS certificate management" (2020) — DOI: 10.1002/dac.4503 — Log-based PKI remains vulnerable if an attacker can present different signed log versions to a target.
• "LogPicker: Strengthening Certificate Transparency Against Covert Adversaries" (2021) — DOI: 10.2478/popets-2021-0066 — A covert adversary who has co-opted both a CA and a corresponding log can still issue fraudulent certificates. A design where log pools act as witnesses for each other.
• "Server notaries: a complementary approach to the web PKI trust model" (2018) — DOI: 10.1049/iet-ifs.2016.0611 — Although various solutions have been proposed, none has seen widespread adoption due to complexity and deployability issues. Detecting server-side certificate replacement attacks.
• "Accountable and Transparent TLS Certificate Management…" (2018) — DOI: 10.1155/2018/8527010 — Proposal for an alternative PKI featuring verifiable trusted parties.
• "Associative Blockchain for Decentralized PKI Transparency" (2021) — DOI: 10.3390/cryptography5020014 — Pointing out that existing transparency approaches remain somewhat centralized, and introducing client-side decentralized auditing.
• "The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem" (2018) — arXiv:1809.08325 (preprint) — The exponential growth of CT-logged certificates and expanded site support. CT honeypot experiment — log data was used to select scanning targets mere minutes after issuance.
• "Certificate Transparency with Privacy" (2017) — DOI: 10.1515/popets-2017-0052 — Browser log auditing without compromising user privacy, extending support to private subdomains.
• "Private Queries on Public Certificate Transparency Data" (2019) — arXiv:1905.09478 (preprint) — The issue where client CT queries expose browsing habits to hosting servers, and attempts at anonymous querying.
• "Revocation Statuses on the Internet" (2021) — arXiv:2102.04288 (preprint) — No revocation transparency procedure corresponding to CT has been adopted for certificate issuance. Longitudinal analysis of status history for over 1 million revoked certificates (773,000 of which were a single institution's mass revocation).
• "SoK: Delegation and Revocation, the Missing Links in the Web's Chain of Trust" (2019) — arXiv:1906.10775 (preprint) — Issues of delay, availability, and privacy in revocation schemes, and the lack of native delegation in TLS driving domain owners into the dangerous practice of sharing private keys.
• "Postcertificates for Revocation Transparency" (2022) — arXiv:2203.02280 (preprint) — A design where certificate owners bypass CAs and initiate revocation themselves by submitting to existing CT logs.
• "Tradeoffs in certificate revocation schemes" (2003) — DOI: 10.1145/956981.956991 — Classification and tradeoff analysis of revocation schemes.
• "Certificate Revocation in the TLS Ecosystem: A Survey" (2026) — DOI: 10.1145/3785653 — The limitations major revocation schemes have shown in privacy, scalability, and other areas, alongside the real-world deployment implications of latest techniques.
• "Will You Trust This TLS Certificate? Perceptions of People Working in IT (Extended Version)" (2022) — arXiv:2207.11610 (preprint) — Observation of 75 IT workers. Trust judgments are far from binary, and self-signed or name-constrained certificates tend to be overestimated. Small changes in error messages improve comprehension and judgment.
• "Testing Certificate Authorities: An Empirical Study and Stateful Fuzzing Approach" (2026) — DOI: 10.36227/techrxiv.176972158.85579194/v1 (preprint server version, publication status unverified) — Developer test protocol coverage of 39.5%/25.6% across 4 open-source CA implementations, reaching up to 100% with a specification-based generator, uncovering 3 unreported bugs.
• "Differential Testing of Certificate Validation in SSL/TLS Implementations" (2019) — DOI: 10.1145/3355048 — Extracting certificate rules from standard documents and differentially testing implementations to expose potential flaws.
• "Finding Phish in a Haystack: A Pipeline for Phishing Classification on Certificate Transparency Logs" (2021) — arXiv:2106.12343 (preprint) — A pipeline that catches phishing in the staging phase via CT logs to narrow the "window of opportunity" for blocklists.
• "Anomaly Detection in Certificate Transparency Logs" (2024) — arXiv:2405.05206 (preprint) — Detecting anomalous certificates uncatchable by standard compliance checks, verified on CT log samples.
• "Certificate Transparency-driven real-time website categorization…" (2026) — DOI: 10.47813/2782-5280-2026-5-3-1001-1014 (small regional journal) — Processing 8.51 million X.509 records over 23.83 hours, categorized into 36 buckets.
• "CERTainty: Detecting DNS Manipulation at Scale using TLS Certificates" (2023) — arXiv:2305.08189 (preprint) — Detecting DNS manipulation using TLS certificates as a verifiable signal. A 72.45% false positive rate for existing consistency-based heuristics.
• "SoK: Log Based Transparency Enhancing Technologies" (2023) — arXiv:2305.01378 (preprint) — The purpose, utility, and pitfalls of log-based transparency technologies, and how transparency relates to external mechanisms that challenge systems and hold operators accountable.
• "Non-governmental Governance of Trust on the Internet: The CA/Browser Forum" (2023) — DOI: 10.2139/ssrn.4528663 (preprint) — A forum where certificate producers and browser vendors jointly develop and enforce issuance baselines and CT. Analysis of 369 meeting minutes, 553 individuals across 123 organizations, and 192 votes.
• "Assessing SSL/TLS Certificate Centralization: Implications for Digital Sovereignty" (2025) — arXiv:2504.16897 (preprint) — Over 75% of domain certificates in two political and economic spheres are issued by a single country-based CA.
• "How to Measure TLS, X.509 Certificates, and Web PKI: A Tutorial and Brief Survey" (2024) — arXiv:2401.18053 (preprint) — Conflicting results from prior TLS measurement studies are rooted in differences in measurement setup rather than actual deployment differences.