Skip to content

The history of certificate authorities and the disasters that reformed them

· 29 min read
Copyright: MIT
history pki tls
The wordmark X.509 in large monospace type with a single orange underline bar and a small grey CA / PKI subtitle

Open a TLS connection to your bank and a stranger you have never met vouches for the server you are talking to. The stranger is a certificate authority, a company you did not choose and cannot easily refuse, and your browser trusts it because someone at Mozilla or Apple or Google decided years ago that it belonged in a list. There are a few dozen such companies whose roots ship in the trust stores on your machine, and any one of them can issue a certificate for any domain on the internet. Not just the domains that belong to it. Any of them. The whole edifice of HTTPS rests on the assumption that every one of those companies, in every one of its issuance systems, run by every one of its resellers, never makes a mistake.

That assumption has failed, publicly and expensively, more than once. This is the story of how the certificate authority came to hold that much power, what happened the times it abused or lost control of it, and the machinery the web grew afterward to watch the watchers. The technical core of it is a 1988 ITU standard for naming things in a directory that got repurposed into the trust anchor for global commerce. The interesting parts are the failures.

The road map is roughly chronological. We start with X.509 and the structure of a certificate, then the way that structure turned into a small set of companies with enormous leverage. Then the governance layer, the CA/Browser Forum, that tried to put rules around them. Then the run of breaches from 2011 to 2017 that proved the rules were not enough on their own: Comodo, DigiNotar, TURKTRUST, and the slow-motion distrust of Symantec. Then Certificate Transparency, the thing that finally made mis-issuance visible. And finally where the system sits now, with free automated certificates, multi-perspective validation, and a clock ticking down toward certificates that live six weeks.

What a certificate actually is

A certificate is a signed claim. It says: this public key belongs to this name, and I, the issuer, attest to that, and here is my signature so you can check I really said it. The format that carries the claim is X.509, and it is older than the web by several years.

X.509 was first published on 3 July 1988 as part of the ITU’s X.500 series, a set of recommendations for building a global directory. The original idea had nothing to do with web browsers. X.500 imagined a worldwide hierarchical directory of people and organizations, and X.509 was the piece that handled authentication into that directory. The certificate format in the 1988 standard is the version 1 layout. When X.500 was revised in 1993 it gained two fields and became v2. The version most of the web uses now is v3, which added the extension mechanism that lets a certificate carry arbitrary typed fields, and that extension mechanism is where almost everything interesting later got bolted on.

The directory never happened the way X.500 imagined. What survived was the certificate. In 1995 the IETF, working with NIST, formed the Public-Key Infrastructure (X.509) working group, universally called PKIX, to profile the ITU format for use on the internet. PKIX produced RFC 3280 and then its successor RFC 5280, which is the document people mean when they say “X.509 certificate” today. RFC 5280 defines which fields a CA must populate, how a relying party builds and validates a chain from a leaf certificate up to a trusted root, and how revocation lists are formatted. When a TLS library rejects a certificate, it is usually rejecting it against the rules in 5280.

The structure that matters is the chain. A root CA holds a self-signed certificate, the trust anchor, whose private key is kept offline in a hardware security module and used as rarely as possible. The root signs one or more intermediate certificates. The intermediates do the day-to-day work of signing the leaf certificates that go on web servers. Your browser ships the roots; the server sends the leaf and the intermediates; the browser walks the chain upward and checks each signature until it reaches a root it already trusts. The reason for the intermediate layer is blast radius. If an intermediate key is compromised you can revoke that intermediate without burning the root, and the root never has to come out of its vault.

Root CA (self-signed) offline key, ships in trust store Intermediate CA signs leaf certs day to day Leaf: example.com on the web server, sent in handshake trust anchor verified upward *The chain of trust: a browser ships the root, the server sends the leaf and intermediate, and verification walks upward until it reaches an anchor already in the trust store.*

The flaw in this design, the one that runs through every story below, is that the trust is not scoped. A certificate from any trusted root validates for any hostname unless something external constrains it. There is nothing in the basic X.509 model that says a Dutch CA may only sign Dutch domains, or that a CA whose business is government certificates may not sign google.com. The constraint, when it exists, comes from policy bolted on top: name constraints in an intermediate, the rules of a root program, or after-the-fact detection. For most of the web’s history the constraint was simply trust that the CA would behave.

The oligopoly: VeriSign and the price of a padlock

The commercial CA business begins with RSA. The RSA algorithm came out of MIT in 1977, named for Rivest, Shamir, and Adleman, and RSA Data Security was the company built to license it. In April 1995 RSA spun out its certificate services arm as an independent company, VeriSign, to issue and verify certificates at scale. Jim Bidzos, who had run RSA Data Security, was behind the move. VeriSign demonstrated its first online certificate-issuing system at the RSA conference in January 1996, and by 1997 it was the dominant certificate authority on the web.

Dominant is an understatement for what followed. When Netscape needed an entity to vouch for server identities in its new SSL protocol, VeriSign was there with a root already trusted in the browser. Being in the browser was everything. A root that shipped in Netscape and then Internet Explorer could sell certificates that worked for everyone; a root that did not might as well not exist. The barrier to entry was not cryptography, which was public, but distribution, which was controlled by a handful of browser vendors. VeriSign had it, and it spent the next decade buying or out-competing most of the companies that did not.

The economics were strange. The marginal cost of issuing a certificate is close to zero, a signing operation that takes milliseconds. The price was hundreds of dollars a year. What customers paid for was not the bytes but the trust path, the fact that the issuer’s root sat in the browsers. For a long stretch in the late 1990s and 2000s a small number of companies, VeriSign chief among them, collected rent on a padlock icon. The padlock did not even mean much. It meant the connection was encrypted and that some CA had done some validation, often nothing more than checking that the buyer could answer an email at the domain.

The industry’s answer to “the padlock means too little” was to invent a more expensive padlock. Extended Validation certificates arrived in 2007, defined by the newly formed CA/Browser Forum, and required the CA to verify the legal existence of the organization behind the domain rather than just control of the domain. In return browsers showed the company name in a green bar next to the URL. EV was, in part, an attempt by the established CAs to defend their margins against the commoditization that domain-validated certificates were bringing. The green bar is gone now. Browsers removed the special EV treatment around 2019 after studies showed users did not read it and it provided little real security benefit, which tells you something about what the premium had been buying.

VeriSign sold its authentication business, the SSL and PKI unit, to Symantec in 2010 for 1.28 billion dollars. Symantec would later sell the same business to DigiCert in 2017, and the reason it sold is the subject of one of the breakdowns below. The point for now is that the names changed but the structure did not. A small set of roots, controlled by a small set of companies, sat at the base of all web trust, and the only thing standing between that arrangement and disaster was that the companies kept their houses in order.

Governance: the CA/Browser Forum

There was, for a long time, no written rulebook for what a public CA had to do. Validation practices varied. Some CAs checked organizational identity carefully; others issued on a confirmation email. There was no shared baseline for how a CA secured its issuance systems, how long certificates could live, or what a CA had to do when something went wrong. The browsers held the ultimate sanction, removal from the trust store, but exercised it rarely and without a standard to point to.

The CA/Browser Forum formed to fix this. The first meeting was organized in 2005 by Melih Abdulhayoglu of Comodo, held in New York, followed by meetings later that year in Ontario and Arizona. The Forum is a voluntary consortium of certificate authorities and the vendors of browsers and operating systems whose trust stores decide which CAs matter. Its first product was the EV Guidelines in 2007. Its most consequential product came later: the Baseline Requirements, version 1.0 of which took effect on 1 July 2012, the first industry-wide rules that every public CA had to follow regardless of whether it was a Forum member.

The Baseline Requirements matter because they turned the trust store from a list of companies the browsers liked into a list of companies that agreed to follow specific rules. The rules cover how domain control may be validated, what a certificate may and may not contain, how a CA must run its infrastructure, and how it must respond to incidents. A CA that violates them can be cited in a public bug tracker, and a pattern of violations can end with the browsers pulling its root. The enforcement is unusual. It runs through public mailing lists and bug trackers where anyone, not just members, can file an incident against a CA, and the CA must respond in the open. This is why CA failures since 2012 have such detailed paper trails: the post-mortems are mandatory and public.

The Forum’s power is real but indirect. It cannot fine a CA or shut it down. What it can do, through the browser members, is make a CA’s certificates stop working, and the threat of that is what gives the rules teeth. The history of CA reform is largely the history of browsers, Google above all, deciding the rules were not being followed and acting unilaterally when the consensus process moved too slowly.

Comodo, 2011: a reseller hands over the keys

The first of the modern CA disasters did not breach a CA’s core systems at all. It breached a partner.

On 15 March 2011 an attacker compromised a registration authority affiliated with Comodo. A registration authority is a reseller trusted to validate certificate requests on the CA’s behalf and submit them for signing. The attacker used the RA’s credentials to request and obtain nine fraudulent certificates covering seven domains, and the domains were not random. They were mail.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org, login.live.com, and global trustee. These are the login endpoints of the major webmail and identity services. A certificate for mail.google.com from a trusted CA lets an attacker who can also redirect traffic impersonate Gmail’s login page with a padlock that validates cleanly.

Comodo caught it fast. An internal check flagged the issuance, the certificates were revoked through CRL and OCSP, and Comodo notified the browser vendors so they could blacklist the specific certificates directly in their code, which Mozilla and others did within days. The attack was traced to an IP address in Tehran. Shortly after, a person posting as “ComodoHacker” claimed responsibility, posted a private key to prove it, and framed the operation in nationalist terms, claiming to act alone rather than for a state.

The Comodo incident exposed a structural weakness that revocation alone could not fix. The fraudulent certificates were caught because Comodo happened to notice. But the affected parties had no independent way to know a rogue mail.google.com certificate existed. Google could not look anywhere to discover that some CA had signed its domain without permission. The only reason the world found out was that the issuing CA confessed. That asymmetry, the certificate holder being the last to know, is the problem Certificate Transparency would eventually attack. But first came a worse breach, one where the CA did not catch it fast, did not confess promptly, and did not survive.

DigiNotar, 2011: the CA that died

DigiNotar was a Dutch certificate authority, acquired by VASCO in January 2011, that issued certificates for the general web and, more sensitively, for the Dutch government’s PKIoverheid program. In the summer of 2011 it was thoroughly compromised, and the way it handled that compromise ended the company.

The timeline is grim. The attacker breached the outer network around 17 June 2011 and worked inward, reaching the segment that held the CA signing systems by early July. The first rogue certificate was issued on 10 July. DigiNotar’s own logs were incomplete, so the full count of fraudulent certificates was never knowable, but the investigation found more than 200 certificates issued against more than 20 domains. One of them was a wildcard *.google.com certificate, and unlike the Comodo certificates, this one was used.

In late August 2011 that *.google.com certificate turned up in a live man-in-the-middle attack against Gmail users in Iran. It was caught because a Chrome user in Iran hit a certificate warning and reported it. Chrome had a feature that helped here: it pinned Google’s own certificates, so a certificate for a Google domain from a CA that was not supposed to sign Google domains tripped an alarm in the browser even though the certificate was technically valid by the standard chain rules. Estimates from the incident put the number of Iranian users exposed to interception in the hundreds of thousands. This was not a theoretical mis-issuance. People’s email was being read.

User in Iran expects gmail.com Attacker holds rogue *.google.com cert Real Google never contacted TLS, padlock OK intercepted Chrome's pin on Google certificates is what tripped the alarm: a valid-looking cert from a CA that should never sign google.com. *A fraudulent but chain-valid certificate lets an interceptor present a clean padlock. The standard validation rules pass; only Chrome's hardcoded pin on Google's own certificates caught the DigiNotar forgery.*

DigiNotar’s response sealed its fate. It had detected an intrusion on 19 July and begun quietly revoking certificates, but it did not go public. For more than a month the company sat on the knowledge that its CA had been compromised while continuing to operate. The rogue Google certificate was not even revoked until 29 July. The wider world did not learn the scope until the end of August, when the live attack forced it into the open.

Once it was public the browsers moved hard. On 29 August 2011 Google announced Chrome would distrust all DigiNotar certificates. Mozilla published its analysis the same day and removed DigiNotar from Firefox’s root store, shipping the removal in Firefox 6.0.2 and 3.6.22 on 6 September. There was a complication: DigiNotar also ran the Dutch government’s PKIoverheid CA, and pulling it would break government services. Mozilla initially exempted those certificates, then rescinded the exemption after the Dutch government’s own audit could not vouch for the integrity of any DigiNotar issuance. On 3 September the Dutch government took over operational management of the company. DigiNotar filed for bankruptcy later that month. It is the cleanest example in the history of the trust store of a CA being executed: it failed, it concealed the failure, and it ceased to exist.

The forensic report on the breach, commissioned from Fox-IT and published under the name Operation Black Tulip, became a reference document for how badly a CA could be run. Out-of-date antivirus, no central logging, a flat network where the signing systems were reachable from compromised web servers, and software months behind on patches. The lesson the industry drew was not only that CAs could be breached but that nobody outside the CA could see it happening. The certificates were valid. The chains checked out. The only signals were a hardcoded pin in one browser and a user who reported a warning.

TURKTRUST, 2013: the mistake that signs everything

If DigiNotar was malice exploiting weak security, TURKTRUST was the danger of a plain mistake. In August 2011 the Turkish CA TURKTRUST accidentally issued two intermediate CA certificates to customers who should have received ordinary leaf certificates. The cause was mundane: a certificate profile migration error between test and production left two test profiles, which carried CA extensions, active on the production issuing system. They were used exactly once, on 8 August 2011, and produced two certificates that were not web-server certificates but intermediate CAs.

An intermediate CA certificate is not a small mistake. A leaf certificate vouches for one name. An intermediate can sign certificates for any name, because it inherits the unscoped signing power of the chain above it. TURKTRUST had handed two of its customers, without meaning to, the ability to mint trusted certificates for any domain on the internet.

One of them did exactly that. The holder of one mis-issued intermediate used it to generate a certificate for *.google.com and deployed it on a web proxy, apparently as part of intercepting and filtering its own network’s traffic. The forgery surfaced on 24 December 2012 when a Chrome installation flagged an unauthorized certificate for a Google domain, again caught by the same certificate-pinning mechanism that had caught DigiNotar. Google investigated, traced it to TURKTRUST, and the browsers revoked the two intermediates in early January 2013. Firefox shipped the revocation on 8 January.

TURKTRUST survived, because it had not been breached and had not concealed anything; it had made an error and owned it. But the incident drove home a point the breaches had already raised. The damage a CA can do is not proportional to the size of its mistake. A single mis-clicked profile, used once, created a tool capable of impersonating any site on the web. There was no way to make CAs incapable of such errors. The only durable defense was to make the errors visible quickly, so that one mis-issued certificate could be found and revoked before it did much harm. Three incidents in two years, all caught by luck or by a Google-specific pin that did not protect the rest of the web, made the case that the web needed a systematic way to see every certificate as it was issued.

Certificate Transparency: making issuance visible

That systematic way is Certificate Transparency, and the three incidents above are why it exists. The work began at Google in 2011, the year of Comodo and DigiNotar, led by Ben Laurie with Adam Langley and Emilia Kasper. They submitted a draft to the IETF in 2012, and it was published as the experimental RFC 6962 in June 2013.

The core idea is simple to state. Every certificate a public CA issues must be recorded in a public, append-only log before browsers will accept it. Anyone can read the logs. A domain owner can watch the logs for certificates issued for their own domains and detect a mis-issuance the moment it appears, rather than waiting for a user to hit a warning. The asymmetry that doomed the response to Comodo and DigiNotar, the certificate holder being the last to know, is inverted. Now the holder can be among the first.

The mechanics are worth understanding because they are clever about a hard problem: how do you make a log you cannot trust still useful? The logs are structured as Merkle trees, append-only hash trees where each new entry folds into a single root hash called the signed tree head. The append-only structure means a log cannot quietly remove or alter an entry it already published without the root hash changing in a way auditors can detect. When a CA submits a certificate, the log returns a signed certificate timestamp, an SCT, which is a signed promise to include that certificate in the log within a bounded time called the maximum merge delay. The browser checks for valid SCTs during the handshake. A certificate without the required SCTs is not trusted.

CA issues precert CT logs Merkle tree, append-only Monitor domain owner watches submit SCT promise read Web server leaf + embedded SCTs Browser requires valid SCTs handshake No required SCTs, no trust. Every issued certificate becomes a public record a domain owner can audit. *Certificate Transparency in one diagram: the CA logs each certificate and receives SCTs, the server presents them in the handshake, the browser refuses certificates that lack them, and a monitor watches the public log for unexpected issuance.*

The SCT has to ride along with the certificate, and there are a few ways to deliver it. The common one uses a precertificate. The CA builds a special version of the certificate carrying a poison extension that marks it as not-for-use, submits that to the logs, collects the SCTs, then embeds those SCTs as an extension in the real certificate it issues. Alternatives exist, a TLS extension and an OCSP-stapled delivery, but the embedded precertificate path is what most issuance uses now. The poison extension is the detail that lets the SCTs be baked into the final certificate without a circular dependency.

Chrome rolled out enforcement in stages, and the stages track the failures. CT was first required for Extended Validation certificates in 2015. After Google found Symantec mis-issuing certificates, it required CT for new Symantec certificates from June 2016, a targeted sanction. And from April 2018 Chrome required CT for all newly issued publicly trusted certificates, full coverage. The current rule depends on certificate lifetime: short-lived certificates need fewer SCTs than longer ones, with the exact counts set by Chrome’s CT policy rather than the RFC.

Certificate Transparency changed the character of CA oversight permanently. Before CT, catching a mis-issued certificate required a victim to stumble into it. After CT, services like crt.sh let anyone query the entire public certificate corpus, security teams run monitors that alert on any certificate touching their domains, and researchers can study CA behavior in bulk. It is also the mechanism that made the next story possible, because the evidence that brought down the largest CA on the web came out of the logs.

Symantec, 2015 to 2018: distrust at scale

The Symantec affair is different from the others. There was no dramatic breach, no nation-state interception, no company that vanished in a month. It was a slow accumulation of issuance problems at the largest CA on the web, surfaced largely through Certificate Transparency, that ended with Google forcing the distrust of every certificate from a brand that had once been VeriSign.

It started small. In 2015 Google found, through CT, that Symantec had issued certificates for Google domains it did not control. Symantec characterized these as test certificates, a limited mistake, and put the count at 23 then later acknowledged more. The browsers were not reassured, because the issue was not the harm of those specific certificates, which was minimal, but what they revealed about Symantec’s controls. If a CA can issue unauthorized certificates for google.com as a test, what else is its issuance pipeline doing without proper authorization?

Over 2016 and 2017 the picture widened. Google’s investigation, aired in the public mozilla.dev.security.policy forum, found a long pattern of issuance that did not meet the Baseline Requirements, spread across Symantec and the registration authorities it had delegated trust to. The numbers cited grew into the tens of thousands of questionable certificates once the full scope of Symantec’s partner programs was included. Symantec disputed the framing and the counts, and a public, often bitter argument ran for months over how bad the problem really was. The substance under the argument was that Symantec had delegated issuance authority widely and could not fully account for what had been issued under its roots.

In 2017 the browsers and Symantec reached a settlement of sorts. Rather than an immediate distrust, Symantec would transition its issuance to infrastructure run by another CA while it rebuilt, and existing certificates would be distrusted on a schedule keyed to Chrome versions. The schedule pulled trust from certificates issued before June 2016 in Chrome 66 and from those issued before December 2017 in Chrome 70. Faced with rebuilding its entire PKI under browser supervision, Symantec instead sold the business. In August 2017 DigiCert agreed to acquire Symantec’s website security and PKI operation for roughly 950 million dollars, taking over issuance from December 2017 and running the managed transition that let existing site operators replace their certificates before the distrust dates hit.

The Symantec distrust is the moment it became unambiguous that the browsers, not the CAs, held final authority over the trust store. The largest, oldest, most established CA brand on the web, the direct descendant of VeriSign, was removed from trust not for being hacked but for a sustained failure to follow the rules and account for its own issuance. The sanction was applied through Certificate Transparency evidence and executed through Chrome version numbers. No ballot at the Forum was needed. Google decided the rules had been broken badly enough, published the evidence, set the dates, and the rest of the ecosystem followed.

The other side: free certificates and automation

While the breaches were forcing the trust model to grow eyes, a separate movement was attacking the oligopoly’s economics directly. For most of the web’s history HTTPS cost money and effort, which is a large part of why most of the web ran on plain HTTP. A certificate meant paying a CA and manually installing and renewing the result, often a yearly chore that lapsed and broke sites. The padlock was a paywall.

Let’s Encrypt removed the paywall. Announced on 18 November 2014 and run by the nonprofit Internet Security Research Group, it issued its first browser-trusted certificate on 14 September 2015 and opened to the public on 3 December 2015. Its certificates are free, and more important than free, they are automatic. The enrollment protocol, ACME, submitted to the IETF in early 2015, lets a server prove control of a domain and obtain a certificate without a human in the loop. The CA’s own software, an open-source Go implementation called Boulder, runs the issuance side. A server can request, install, and renew certificates on a timer with no manual step at all. Let’s Encrypt bootstrapped its trust by having its intermediates cross-signed by IdenTrust in October 2015, so its certificates worked in browsers before its own roots were widely embedded.

The effect on the web was enormous. The fraction of web traffic served over HTTPS, which had been stuck for years, climbed steadily as free automated certificates removed the cost and the friction. The premium CA business that VeriSign had built was hollowed out from below; the rent on the padlock collapsed. We trace that shift in more detail in the Let’s Encrypt revolution, and the trust-store mechanics that decide which roots get to play in the Web PKI trust store. For this story the relevant point is that automation, pioneered to make certificates free, turned out to be the thing that made the next round of reforms feasible. You cannot ask the web to replace its certificates every six weeks if replacement is a manual chore. Once ACME made renewal a cron job, short certificate lifetimes became possible.

Entrust, 2024: the pattern repeats with a known name

The Symantec playbook ran again in 2024, against Entrust. The pattern was the same: not a single catastrophic breach but a sustained record of compliance failures, mis-issuances, and what the browsers judged to be inadequate responses to public incident reports, accumulated over years and aired in public bug trackers.

In late June 2024 Google announced that Chrome would stop trusting new TLS server certificates from Entrust and AffirmTrust. The cutoff was keyed to the SCT timestamp, the same Certificate Transparency machinery built after DigiNotar: certificates whose SCT is dated after 11 November 2024 would not be trusted in Chrome. Apple set its own date a few days later and Mozilla a few weeks after that. Certificates already issued before the cutoff kept working for their natural lifetime, and Entrust arranged, as Symantec had, to keep serving its customers by issuing from another CA’s infrastructure.

Two distrust events of major CAs, seven years apart, both driven by compliance failures rather than breaches, both executed through CT timestamps and browser version gates, establish that the trust store is now actively policed. A CA’s place in it is conditional on continuous good behavior, measured against public rules, with the evidence sitting in logs anyone can read. The era when a root was a permanent franchise is over.

Where the system sits now

The certificate authority of 2026 operates under constraints that would have been unrecognizable to VeriSign in 1997. Every certificate it issues lands in a public log within seconds. Its domain validation has to be confirmed from multiple network vantage points, a rule called Multi-Perspective Issuance Corroboration that the Forum ratified in August 2024 and that became mandatory across the industry in 2025. MPIC checks domain control from at least two independent network perspectives in different regions, hundreds of kilometers apart, specifically to defeat the BGP-hijacking attacks that could otherwise trick a CA into validating a domain an attacker has temporarily rerouted. The threat MPIC addresses connects directly to routing security, which we cover in BGP hijacks and route leaks.

And the certificates are getting short. In April 2025 the Forum passed Ballot SC-081v3, originally proposed by Apple, on a vote of 29 in favor and none against with five abstentions. It sets a schedule that ratchets the maximum certificate lifetime down from 398 days to 47 days, in steps, reaching the final 47-day limit on 15 March 2029, with intermediate stops including a 100-day cap by March 2027. The odd number is deliberate. A round figure invites a calendar reminder and a human renewing by hand; 47 days is meant to be short enough that the only sane way to comply is full automation, the kind ACME and Let’s Encrypt normalized a decade earlier.

The logic running through all of it is the same logic the breaches taught. A long-lived certificate is a long-lived liability, because a compromised key or a mis-issued certificate keeps working until it expires or until revocation reaches everyone, and revocation has never worked reliably. The CRL and OCSP mechanisms defined back in RFC 5280 were always leaky; a browser that cannot reach the revocation responder usually fails open and trusts the certificate anyway, which is why a 47-day lifetime does more for safety than a perfect revocation system that does not exist. Shrink the window and you shrink the damage any single failure can do. Certificate Transparency made mis-issuance visible. MPIC makes validation harder to fool. Short lifetimes make every certificate, good or bad, expire before it can do much harm. The reforms are different mechanisms aimed at the same target: limiting the blast radius of a trust model that hands every CA the power to vouch for the entire internet, and that has, repeatedly, proven it cannot be trusted to never make a mistake.

That is the through-line worth holding onto. The X.509 model put no scope on a CA’s signing power and never did acquire one at the protocol level. A root that can sign google.com can still sign anything. Everything built since 2011, the logs, the multi-perspective checks, the shrinking lifetimes, the public bug trackers where a CA must explain itself or lose its franchise, is scaffolding erected around a load-bearing flaw nobody could remove. The web did not fix the certificate authority. It surrounded it with enough surveillance that the next mistake gets caught in hours instead of months, and it shortened the fuse on every certificate so that catching it late costs less. DigiNotar took six weeks to admit it had been breached and the company was dead within the month. The reforms since exist so that the six weeks can never happen again.

Sources & further reading

Further reading