When a Certificate Authority Fails

35.0 What this chapter gives you#

1. You will be able to state, in one sentence a non-technical colleague can repeat, why the security of every website on the internet is bounded by the worst-run certificate authority in the browser’s trust store.
2. You will be able to recount the Comodo breach of 15 March 2011 with the correct number of certificates, the correct names, and the correct account that was compromised.
3. You will be able to give the DigiNotar timeline from first intrusion to bankruptcy with the dates, the certificate counts and the interception figures from the Fox-IT investigation.
4. You will be able to explain what an accidentally issued intermediate certificate is, why TURKTRUST issued two of them on 8 August 2011, and why nobody noticed for sixteen months.
5. You will be able to describe how a publicly trusted certificate ended up inside a traffic-inspection appliance on a French government network in 2013, and what browsers did about the root above it.
6. You will be able to trace the Symantec case from a single test certificate in September 2015 to the two-stage Chrome and Firefox distrust of 2018, with the numbers at each stage.
7. You will be able to say precisely what WoSign and StartCom did wrong in 2016, and why backdating a certificate is a lie that the industry can now detect.
8. You will be able to name the four standing controls that came out of these incidents, say which incident produced each, and give the date each became mandatory.
9. You will be able to describe the four mechanisms browsers actually use to withdraw trust, from an emergency blocklist to a dated cut-off, and say which one a given situation calls for.
10. You will be able to explain why any certificate authority can still issue for any name in August 2026, what limits that in practice, and what the remaining unfixed risk is.

Every chapter in this volume so far has described a machine that works. A certificate authority checks that you control a name, signs a statement binding that name to your public key, and browsers accept the statement because they already trust the authority’s own key. It is an elegant arrangement and it carries almost all of the encrypted traffic on the public internet.

This chapter is about the times it did not work. Not hypothetically, not in a research paper, but in production, against real users, with consequences that ranged from a corrected error to the destruction of a company and the exposure of several hundred thousand people’s private mail to a government that wanted to read it.

The reason to spend a long chapter on six old incidents is not history for its own sake. It is that almost every control a certificate authority operates under today exists because of a specific incident, and you cannot understand the control without the incident. Certificate Transparency exists because misissuance was invisible. Mandatory CAA checking exists because domain owners had no way to say which authority they used. Name constraints on government roots exist because a government root was used to inspect traffic. Certificate lifetimes measured in weeks rather than years exist because the industry gave up on cancelling certificates and decided to make them expire before the cancellation would have mattered. The controls look arbitrary until you know what they are scar tissue from.

There is also a structural lesson underneath all six, and it has not been fixed. Any authority in the trust store can issue a certificate for any name in the world. Your bank’s security depends on an authority in a country you have never visited, operated by a company you have never heard of, because your browser will accept that company’s signature on a certificate for your bank exactly as readily as it accepts the one your bank actually bought. Everything in this chapter is either a demonstration of that fact or an attempt to contain it. Three boundaries before we start: the public log of issued certificates is chapter 31, “Certificate Transparency”, and this chapter only says which incidents caused it; cancelling an individual certificate is chapter 30, “Revocation”, and the short version there is that cancellation mostly does not work; and keeping a signature verifiable for decades after the signing key has gone is chapter 34, “Time, and Signatures That Must Outlive Their Keys”.

The plain version#

A city where any locksmith can cut a key for your door#

Imagine a city of about a million front doors. Every door has the same kind of lock, built to one civic standard, and the standard has an unusual property: the lock opens to any key that carries the stamp of a licensed key-cutter. Not your key-cutter. Any of them. There are around a hundred and twenty licensed key-cutters in the city.

At first this sounds mad, and by the end of this chapter you may still think so, but it is what makes the city work. You have never met the person who delivers your parcels, and the delivery firm has never met your locksmith. If every door only accepted keys from the one cutter its owner happened to choose, nobody could ever open anything for anybody without a prior introduction. By agreeing that every lock accepts every licensed cutter’s stamp, the city allows strangers to do business on the first meeting. That is the whole trick, and it is the same trick that lets your browser connect to a website it has never seen before and get an encrypted, authenticated connection on the first try.

The cutters are licensed by a small committee. To get a licence you must show that you have a proper workshop, that you keep records, that you check who is asking before you cut, and that an outside inspector visits you once a year. The rule that matters most is the one about checking: before a cutter makes a key for 14 Nehru Road, the cutter must satisfy itself that the person asking really controls 14 Nehru Road.

Now hold that arrangement in your head and notice the exposure. A key cut for your door by any of the hundred and twenty cutters opens your door. Not a similar door. Yours. And the lock has no way of telling a key that was cut for you from a key that was cut for somebody pretending to be you, because the lock only inspects the stamp, and the stamp is genuine in both cases. So the safety of your house is not the safety of your own cutter. It is the safety of the least careful cutter in the city, on the least careful day of their year.

That is the entire subject of this chapter, and everything below is what happened when that exposure was tested.

The night the apprentice sold nine keys#

The first case is small, fast and instructive.

A large cutter does not do all its own counter work. It has franchises: small shops in other towns that take orders, do the checking, and send the order back to the main workshop, which cuts the key and stamps it. The franchise never touches the stamping machine. But the franchise’s order form is, in effect, an instruction the workshop obeys.

On the evening of 15 March 2011 somebody got into one franchise’s account. Not the workshop. Not the stamping machine. One account at one franchise. In about two hours they placed nine orders, and the workshop cut and stamped all nine. The nine were not addresses in a suburb. They were the front doors of the city’s post office, its telegraph exchange, its two largest message services and the office that hands out browser extensions. In real terms: mail servers belonging to Google, Yahoo, Microsoft, Skype and Mozilla.

The workshop noticed within hours, cancelled all nine, and told the committee. One of the nine was actually taken to a door and tried; the door’s owner checked with the workshop, was told the key had been cancelled, and refused it. The site in Iran where that test happened went offline immediately afterwards.

Two things to take away. First, the attacker never needed to break the cryptography or steal the workshop’s stamping die. They needed one password at one small franchise, because the franchise’s word was enough to make the workshop act. Second, the workshop’s own report concluded, from the pattern of targets and the origin of the connections, that this was not an ordinary thief after money. It was somebody who wanted to read other people’s mail.

The workshop that was taken over completely#

The second case is the one everybody remembers, and it destroyed a company.

A small Dutch cutter, DigiNotar, was compromised in June 2011. Not one account at a franchise: the workshop itself. The attacker got administrator control of the network the stamping machines sat on. Over the following weeks they cut five hundred and thirty-one keys and, crucially, they deleted the order book entries for many of them. When investigators arrived, the company literally could not produce a list of what it had made.

One of those keys was for Google’s mail. It was cut on 10 July 2011. It then sat quietly for three weeks. From 4 August, doors all over Iran started checking that key with the workshop, which is what a lock does when a key is presented to it. The investigators counted the checks. Around three hundred thousand different households presented that key or had it presented to them, and more than ninety-nine in a hundred of them were in Iran. That is not a theoretical risk. That is several hundred thousand people whose mail was being read, in real time, for four weeks, because one small company’s password was weak enough to be guessed.

The key was cancelled on the evening of 29 August 2011. The city withdrew the company’s licence over the following week. On 19 September 2011, three weeks after the cancellation, the company filed for bankruptcy. It never traded again.

The list of what investigators found inside the workshop reads like a checklist of things you are told not to do: every stamping machine on one shared network with one shared administrator password, that password weak enough to be brute-forced, no antivirus software on any of the examined servers, unpatched web software facing the public, and no secure central log. This was a company whose entire product was the claim that it could be trusted to check things.

Two ways to hand out a key-cutting machine#

The third and fourth cases are different in kind, and once you see the difference you will never forget it.

A cutter can make you an ordinary key. A cutter can also make you a key-cutting machine of your own, stamped with its authority, so that keys you cut yourself are accepted everywhere. There are legitimate uses for that; large organizations sometimes run their own internal key desk. But a machine is not a key. A key opens one door. A machine opens every door in the city, forever, until somebody notices.

In August 2011 a Turkish cutter, TURKTRUST, meant to hand two customers ordinary keys and handed them machines instead. The cause was mundane and therefore terrifying: during a software migration, two test settings were copied into the live system, and for one day the live system produced the wrong kind of output. Two customers walked away with machines. One of them realized and gave it back. The other installed it on a mail server, and later somebody loaded it into a network appliance that inspects staff traffic, and the appliance did what such appliances do: it started cutting keys for whatever site an employee visited. On 24 December 2012, sixteen months later, one of those freshly cut keys was presented to a Google server, and Google’s own browser noticed that it did not match the key Google knew it should be seeing. That is how it was found: by accident, by the one party in the world that had hard-coded what its own key should look like.

A year later, in December 2013, the same shape of failure appeared with the opposite intent. A French government cutter had issued a machine to a French government office, and that office had installed it in exactly such an inspection appliance, on its own internal network, to read its own staff’s encrypted traffic. Within the office’s own walls that is a policy question, not a crime. The problem is that the machine did not know it was only supposed to work inside those walls. It carried the authority of a cutter every lock in the city accepts. A key cut on that machine would have opened doors in Mumbai.

The fix the city eventually adopted for this is beautifully simple in principle: a machine can be branded so that keys cut on it only work on particular streets. In the French case, browsers went one better and branded the cutter itself, so that from then on its keys were accepted only in France and French overseas territories.

Sloppiness at scale, and a lie about a date#

The fifth case has no attacker in it at all, which is why it is the most important one.

Symantec was, at the time, the largest cutter in the city. In September 2015 a key was cut for Google’s own front door as part of an internal test. Nobody asked Google. It was found within four days, and only because a public register of cut keys had recently been started and Google was reading it. Symantec’s first count was twenty-three test keys across five customers. An audit found a hundred and sixty-four more, across seventy-six real addresses, plus two thousand four hundred and fifty-eight cut for addresses that did not exist.

Then, in 2017, the same question was asked about the four sub-contractors Symantec had allowed to do counter work on its behalf. Symantec’s first figure was a hundred and twenty-seven keys wrongly cut. By the time the investigation finished the figure was at least thirty thousand.

Nobody stole anything. Nobody broke in. A very large, very respectable business had simply stopped checking, at scale, for years, and had reported small numbers each time it was asked. The city’s response was the harshest yet, and it is worth stating exactly: browsers announced that they would stop accepting that cutter’s stamp entirely, in two stages, with about a year of notice. The business was sold to a competitor before the second stage arrived.

The sixth case is the one where a cutter lied about a date. The city had banned a particular weak cutting technique from 1 January 2016. A Chinese cutter, WoSign, kept using it and stamped the keys with December dates so they looked as though they had been made before the ban. It also bought another licensed cutter, StartCom, and did not tell the committee, which it was required to do. When asked about both, it denied both, until the evidence was overwhelming. In October 2016 all the major browsers stopped accepting new keys from either name. StartCom stopped issuing on 1 January 2018 and closed.

What the city built afterwards, and who actually pays#

Four repairs came out of these six cases, and all four are now standard.

The first is the public register. Every key cut must be written into a public, append-only book before it is valid, so that a householder can look up their own address and see keys they never ordered. That is Certificate Transparency, and chapter 31 is entirely about how it works.

The second is a plate on your own door naming which cutters are allowed to cut for you. A cutter must read the plate before cutting. That is the CAA record, and chapter 28 covers it.

The third is street branding on machines, so that a machine issued to a French office produces keys that only work in France. Those are name constraints, and chapter 27 covers how a chain is validated against them.

The fourth is expiry. Keys used to last three years. As of 15 March 2026 the maximum is two hundred days, and the agreed schedule takes it to forty-seven days in March 2029. A key that expires in seven weeks is a key that a thief has seven weeks to use, and a mistake that corrects itself.

Now the part that is genuinely unfair, and that you should carry away from the plain version. When the city withdraws a cutter’s licence, the cutter loses a business. But the people whose doors stop opening are the householders who bought that cutter’s keys in good faith, who did nothing wrong, and who now have a week to get new keys cut or their visitors will be turned away at the door with a frightening red warning. That asymmetry is the reason distrust takes years instead of days, and it is the reason a very large cutter is harder to punish than a small one. DigiNotar was small and died in three weeks. Symantec was enormous and got eighteen months of notice and a phased exit.

Where the plain version stops being true#

A certificate authority is not one workshop#

The locksmith picture has one workshop with one stamping machine. Real authorities are layered, and almost every incident in this chapter happened in a layer the picture does not have.

There is the root: a key kept offline, usually in a safe, in hardware, used a handful of times a year. There are intermediates: keys signed by the root and used for day-to-day issuance, kept online. There are registration authorities: separate organizations contractually permitted to perform the validation and tell the authority to issue. There are resellers, who may or may not be registration authorities. And there are what Symantec’s case called delegated third parties: partners with direct access to issuance systems.

The honest version: when we say “a CA was compromised”, six of the seven incidents in this chapter did not involve the root key at all, and four did not involve the authority’s own staff. Comodo was a reseller account. Symantec’s thirty thousand were four sub-contractors. TURKTRUST was a configuration file. The root key is the best-defended object in the whole system, and it is almost never what fails.

Revoked does not mean unusable#

In the plain story, the workshop cancels the nine keys and they stop working. In reality, cancelling a certificate is a request that the client may not make, may not receive, and will usually ignore if it fails.

Browsers do not, by default, ask the authority whether a certificate is still valid on every connection. Chrome does not perform online revocation checks in the normal case at all. Firefox uses a pushed, compressed data set. Both fall back to accepting the certificate if a check cannot be completed, because the alternative — refusing to load a site because a third party’s server is slow — was tried and produced a worse internet. Chapter 30, “Revocation”, is the full treatment; the sentence you need here is that revoking a misissued certificate is necessary, is not sufficient, and is one of the reasons browsers now reach for blunter instruments.

Distrust is not deletion#

The plain version says the city withdraws the licence. Real browsers almost never simply delete a root, because deleting a root breaks every certificate under it at once, including the millions issued to blameless customers.

What they do instead is set a dated cut-off. Mozilla marks a root with a date and says: certificates under this root whose validity begins after this date are not trusted; earlier ones are, until they expire. Chrome, since 2024, does the same thing with a different clock — it uses the timestamp on the certificate’s public-log receipt rather than the date the certificate claims, because the authority controls the claimed date and does not control the log. Only when the last legitimately issued certificate has expired is the root actually removed. For a distrust announced in 2024 under a 398-day maximum lifetime, that is well over a year of tail.

The victim of a sanction is not the offender#

This is the part the analogy gets right emotionally and understates practically. When Chrome announced the Symantec distrust in September 2017, it was not punishing Symantec in any direct sense. Symantec’s revenue from a certificate is collected at issuance. The people who had to act were tens of thousands of site operators who had bought a two-year certificate in good faith and now had to replace it early, test it, and deploy it, at their own cost, on somebody else’s schedule.

That is why browser root programmes negotiate for months, publish timetables a year ahead, and phase changes across two releases. It is not softness. It is that the sanction lands on third parties, and a sanction that breaks a large fraction of the web is a sanction that gets rolled back under pressure, which teaches every authority that the threat is empty.

The trust store is not a licensing committee#

There is no city government. There is no regulator of the public web PKI, no statute, no appeal.

What exists is four private root programmes — Mozilla, Apple, Microsoft and Google — each of which decides, on its own terms, which authorities ship in its software. They coordinate through the CA/Browser Forum and share disclosure infrastructure through the Common CA Database, but a root programme’s decision is a product decision by a software vendor, enforceable only by shipping a software update. An authority that is removed has no court to go to. An authority that is kept cannot be forced out by users.

The European Union’s qualified trust service regime is the one place where a genuine legal supervisory structure exists over trust service providers, with supervisory bodies and a legally binding trusted list; that is chapter 33, “What a Signature Means in Law”, and it governs a different set of certificates from the ones your browser uses for TLS.

Hacking is the rarest failure mode#

Read the six incidents again and count. One is an intrusion into the authority’s own network. One is a stolen reseller password. Two are misconfiguration. One is process collapse at scale. One is deliberate dishonesty by the authority itself.

The plain version leaves you expecting attackers. The record says you should expect a migration script, an unaudited partner, and a compliance officer under quota pressure. Since 2017 the overwhelming majority of publicly reported misissuance has been of the boring kind: a wrong field, a bad serial number, an unvalidated name, caught by an automated certificate linter or a transparency log monitor rather than by an incident responder.

The public register does not stop the key being cut#

One more limit, stated plainly because it is the most common misunderstanding about the post-2013 world. Certificate Transparency does not prevent misissuance. It makes misissuance visible, usually within minutes, to anybody who is watching. Somebody still has to watch, and the domain owner is the party with the strongest incentive and the least tooling. Chapter 31 covers what CT does and does not do; here it is enough to say that every incident from 2015 onwards in this chapter was found in a log, and the log did not stop any of them from being issued.

The technical version#

The structural fact: unconstrained issuance#

RFC 5280, which defines the X.509 certificate profile the web uses, contains no mechanism by which a relying party learns which names a given certificate authority is entitled to issue for. A certification path is valid if each certificate is signed by the next one up, each is within its validity period, each carries the basic constraints and key usage bits appropriate to its role, and the chain terminates at a trust anchor the client has configured. Nothing in that algorithm asks whether this particular authority had any business issuing for this particular name.

There is one optional exception, the name constraints extension of RFC 5280 section 4.2.1.10, which lets a CA certificate carry permitted and excluded subtrees of names. It is optional, it is placed by the issuer rather than by the domain owner, and it is still rare in the public web PKI. Chapter 27 covers its validation rules.

The consequence is a fan-in that is worth drawing.

        one browser or OS trust store
                     |
  +---------+--------+--------+---------+
  |         |        |        |         |
root 1    root 2   root 3   ...      root 121
  |         |        |        |         |
 may       may      may      may       may
 sign      sign     sign     sign      sign
 for       for      for      for       for
 ANY       ANY      ANY      ANY       ANY
 name      name     name     name      name

A certificate for pay.hospital.example verifies if it
chains to ANY of them. The relying party cannot tell
which one the site owner actually chose.

The numbers give the shape of the problem in both eras. In 2010 the Electronic Frontier Foundation’s SSL Observatory, presented by Peter Eckersley and Jesse Burns, counted 1,482 CA certificates trusted by Windows or Firefox, carrying 1,167 distinct issuer strings and belonging to 651 organizations. Sixteen years of pruning later, the Common CA Database report “CA Certificates in Firefox” listed 121 root certificates as of 17 August 2026. The pruning is real and substantial. The structural property is unchanged: each of those 121 can issue for every name on the internet.

Comodo, March 2011: nine certificates from one reseller account#

The first incident that made the general public aware of the problem was small in volume and large in implication.

On 15 March 2011, between roughly six and eight in the evening, an attacker used a compromised user account belonging to one of Comodo’s registration authority partners to request certificates. Comodo’s own published report, “Report of incident on 15-MAR-2011”, dated 23 March 2011, states the mechanics plainly: one user account at one RA was compromised, the attacker created a new user identity under that compromised account, and nine certificates across seven distinct subject names were issued.

The ninth entry, with the subject “global trustee”, is the attacker signing their own work; it corresponds to no real service.

Comodo’s report records the source of the requests as several addresses but mainly Iranian, and names one specifically as 212.95.136.18, geolocated to Tehran and belonging to the ISP Pishgaman TOSE Ertebatat Tehran Network. It records that only one certificate is known to have reached the attacker and been tested, the first login.yahoo.com entry, and that when it was tested the OCSP responder — the service a browser asks whether a certificate is still valid — already answered “revoked”. Comodo’s conclusion, stated in the report, was that the targeting pattern and the exclusive interest in communications rather than money made a state-driven attack the likely explanation.

The response is the part worth studying, because it set the template.

Comodo notified the browser vendors before publishing, and the vendors shipped first. Mozilla hard-coded the certificate serial numbers into Firefox as a blocklist across two patches, covering ten certificates in total, and shipped them on 22 March 2011 in Firefox 4 and in updates to the 3.5 and 3.6 lines. Microsoft published Security Advisory 2524375, “Fraudulent Digital Certificates Could Allow Spoofing”, on 23 March 2011; the advisory records that Comodo notified Microsoft on 16 March 2011.

Mozilla’s follow-up post of 25 March 2011 contains a sentence that is unusually honest for a vendor statement and that shaped a decade of policy afterwards. Mozilla had agreed to keep the incident quiet while patches were prepared, and then wrote: “In hindsight, while it was made in good faith, this was the wrong decision. We should have informed web users more quickly about the threat and the potential mitigations as well as their side-effects.”

Within a fortnight Comodo disclosed that two further RA accounts had been compromised, with no further misissuance resulting. The systemic finding was not about Comodo’s cryptography. It was that a registration authority’s instruction was, in practice, an unconstrained issuance capability, and that an RA could cause issuance for any name at all.

DigiNotar, 2011: the failure of a whole authority#

DigiNotar B.V. was a Dutch certificate authority that also operated certificates under PKIoverheid, the Dutch government’s PKI. It was acquired by VASCO Data Security in January 2011. In September of the same year it ceased to exist.

The primary source is the Fox-IT investigation, commissioned by the Dutch government, published as an interim report on 5 September 2011 under the title “Operation Black Tulip” and completed as the final “Black Tulip” report in August 2012. The interim report’s own timeline is the clearest account available, and it is short enough to give whole.

Three things in that table deserve emphasis.

The first is 19 June. DigiNotar’s own daily audit procedure detected the incident on 19 June 2011, and 128 rogue certificates were spotted and revoked on 19 July, another 129 on 20 and 21 July, and 75 more on 27 July. The company knew. It did not tell the browser vendors, the Dutch government or the public. The rogue Google certificate created on 10 July was not found and revoked until 29 July, and even then no disclosure followed. The public learned on 27 August 2011, when an Iranian user posted on a Google support forum that Chrome was complaining about a certificate.

The second is the count. Fox-IT’s provisional result was that 531 fraudulent certificates were issued: 344 with a domain name in the common name field, and 187 whose common name was some form of “Root CA”, which the investigators believed were ordinary end-entity certificates cosplaying as authorities. The distribution of subjects is a political document as much as a technical one.

Certificates naming the Israeli intelligence service, the United Kingdom’s Secret Intelligence Service, the United States Central Intelligence Agency and several Iranian opposition sites sit alongside the mail providers. Fox-IT concluded from the target list and the traffic that the objective was interception of private communication in Iran.

The third is 4 August. Fox-IT analysed the OCSP responder logs — the record of every time a browser asked DigiNotar whether a given certificate was still valid — and found that requests for the rogue Google certificate rose sharply from 4 August and continued until revocation at 19:09 on 29 August. In the report’s words: “Around 300.000 unique requesting IPs to google.com have been identified. Of these IPs greater than 99% originated from Iran.” A sample of the non-Iranian addresses turned out to be Tor exit nodes, proxies and VPN servers rather than direct subscribers.

The report spells out what that meant for the people behind those addresses, and it is worth quoting because it is the clearest statement anywhere of what misissuance actually costs a human being: not only the mail itself but the login cookie could have been intercepted, and with the cookie the attacker could log into the mailbox directly, read stored mail, reach every other Google service, and then use password-reset mail to take over accounts on unrelated services.

The certificate had one property that made the whole investigation harder.

The rogue *.google.com certificate's serial number was
not present in DigiNotar's own issuance database.

Consequence: the CA could not enumerate what it had
issued, so "revoke the bad ones" was not a plan.

Fox-IT's answer, applied on 1 September 2011:
invert the OCSP default.

That inversion is worth writing out, because it is a genuinely clever piece of incident response and it inverts a specification default.

 # Normal OCSP responder behaviour (RFC 6960 / RFC 2560)
def status(serial):
    if serial in revoked_list:  return "revoked"
    if serial in issued_list:   return "good"
    return "good"      # unknown serial, still authorized

 # DigiNotar responder from 2011-09-01: whitelist mode
def status(serial):
    if serial in revoked_list:      return "revoked"
    if serial in known_good_list:   return "good"
    return "revoked"   # unknown serial is presumed rogue

Fox-IT’s findings on the state of the network are the ones every internal PKI review since has been measured against. All CA servers were members of a single Windows domain, so one compromised username and password gave administrative access to all of them; that password “was not very strong and could easily be brute-forced”; the public-facing web software was outdated and unpatched; no antivirus protection was present on the investigated servers; and no secure central network logging was in place. Malware found on the systems included Cain and Abel, a widely known password-cracking tool that ordinary antivirus software detects. A script left on the Public CA 2025 server, written in the CA vendor’s own scripting language, carried the signature phrase “Janam Fadaye Rahbar” — the same phrase left in the Comodo intrusion five months earlier.

The distrust was the fastest in the history of the web PKI, and it happened in two moves, which is the detail people forget.

Microsoft published Security Advisory 2607712 on 29 August 2011 and followed it with update 2616676. Mozilla shipped Firefox 6.0.1, which removed the DigiNotar root but preserved an exception for the Dutch government’s PKIoverheid certificates, because the Dutch government’s own CERT had assessed that those were issued through separate processes and had not been compromised. On 3 September 2011 the Dutch government withdrew that assessment and took over operational management of DigiNotar’s systems. Mozilla then shipped Firefox 6.0.2 and 3.6.22 on 6 September 2011 removing the exception, and stated explicitly: “This is not a temporary suspension, it is a complete removal from our trusted root program.”

DigiNotar filed a bankruptcy petition on 19 September 2011 and was declared bankrupt by the court of Haarlem; VASCO announced it on 20 September 2011. Time from public disclosure to corporate death: twenty-three days.

TURKTRUST, 2013: the intermediate issued by accident#

The 2011 incidents were attacks. The 2013 pair were not, and they exposed a different weakness: a certificate that says CA:TRUE is a completely different object from one that says CA:FALSE, and nothing about the ordering process forces anybody to notice which one they received.

The difference lives in one extension.

 # An ordinary server certificate
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
    TLS Web Server Authentication

 # An intermediate CA certificate
X509v3 Basic Constraints: critical
    CA:TRUE
X509v3 Key Usage: critical
    Certificate Sign, CRL Sign
 # and, in the absence of a nameConstraints extension,
 # no limit whatsoever on the names it may issue for

On 8 August 2011, TURKTRUST issued two certificates with the second shape when it meant to issue the first. Its own account, posted to the Mozilla security policy discussion list in January 2013, explains the cause: during a software migration, certificate profiles were exported from the production system to a test system, two extra profiles carrying CA extensions were created there for testing, and when profiles were later imported back into production the two faulty ones came with them. In TURKTRUST’s words, “The wrong profiles were only used on August 8, 2011 to issue those two faulty certificates which were certainly not intended to be sub-CA certificates.”

The two certificates went different ways. Microsoft Security Advisory 2798897 of 3 January 2013 names them: one issued to *.EGO.GOV.TR, the Ankara municipality transport authority, and one to e-islem.kktcmerkezbankasi.org. One was revoked before use at the customer’s own request. The other was installed on a Microsoft IIS server acting as a web mail server, and was subsequently exported and loaded into a Checkpoint firewall appliance, which used it to generate certificates on the fly for the sites employees visited.

On 24 December 2012 that appliance generated a certificate for *.google.com and presented it to a Chrome user. Chrome ships with pinned expectations for Google’s own domains — a hard-coded statement of which keys should appear for those names — and rejected it. Google’s blog post of 3 January 2013, “Enhancing digital certificate security”, records the response: Chrome’s revocation metadata was updated on 25 December to block the first intermediate and again on 26 December to block the second, and Google notified TURKTRUST, which revoked the remaining certificate on 26 December 2012.

Mozilla revoked trust in both intermediates and, additionally, suspended the inclusion of the newer TURKTRUST root added in December 2007 pending review; its fix shipped to all supported Firefox versions on 8 January 2013. Mozilla’s statement of the seriousness is precise and worth keeping: “at least one of the mis-issued intermediate certificates was used for man-in-the-middle (MITM) traffic management of domain names that the customer did not legitimately own or control.”

Sixteen months elapsed between issuance and discovery. Nothing in the system would have found those certificates. They were found because one company had independently hard-coded what its own certificates should look like, and happened to be looked at.

ANSSI, 2013: the interception appliance with a public root#

Eleven months later the same object appeared with a different origin.

On 3 December 2013 Google detected unauthorized certificates for several of its domains chaining to an intermediate certificate under the root operated by ANSSI, the French network and information security agency, which runs the IGC/A root in browser trust stores. Google’s post “Further improving digital certificate security”, dated 7 December 2013, records ANSSI’s finding: “the intermediate CA certificate was used in a commercial device, on a private network, to inspect encrypted traffic with the knowledge of the users on that network.”

That sentence contains the whole problem. Inspecting your own employees’ traffic on your own network, with their knowledge, is a legitimate and common corporate practice. Doing it with an intermediate that chains to a publicly trusted root is not, because the appliance’s certificates are indistinguishable from real ones to every browser on earth, not just the ones inside the building. Contemporary reporting attributed the network to the French Ministry of Finance; the browser response did not depend on whose network it was.

Google updated Chrome’s revocation metadata immediately to block the intermediate. Mozilla published “Revoking Trust in one ANSSI Certificate” on 9 December 2013 and did the same. Then, in an update to its post on 12 December 2013, Google announced the structural change: the ANSSI certificate authority would be limited, in a future version of Chrome, to a list of top-level domains covering France and French overseas territories — .fr, .gp, .gf, .mq, .re, .yt, .pm, .bl, .mf, .wf, .pf, .nc and .tf.

That is a name constraint, applied by the browser to a root rather than by an issuer to an intermediate, and it is the single most direct answer to the structural fact this chapter opened with. It is also rare. Mozilla applies the same technique to a small number of roots; the Turkish government’s Kamu SM root, for example, carries a constraint limiting it to names under .tr. The mechanism exists, it works, and it is applied to a handful of the 121 roots. The reason it is not applied more widely is commercial rather than technical: most commercial authorities sell to customers worldwide and would not accept a geographic constraint, and browsers have no leverage to impose one on an authority that has not misbehaved.

The CA/Browser Forum Baseline Requirements prohibit a publicly trusted authority from issuing an unconstrained subordinate certificate for use in a traffic-inspection device. The ANSSI case is what made that rule real rather than theoretical.

Symantec, 2015 to 2018: process collapse at the largest authority#

The Symantec case is the most important in this chapter, because it involved no attacker, produced the largest distrust ever executed, and established the procedure that all subsequent distrusts have followed.

It begins on 14 September 2015 at about 19:20 GMT, when Symantec’s Thawte-branded issuance infrastructure produced an Extended Validation pre-certificate for google.com and www.google.com. Google’s post “Improved Digital Certificate Security”, dated 18 September 2015, states that the certificate “was neither requested nor authorized by Google”. Symantec’s explanation was that the issuance occurred during an internal testing process.

The detection route matters more than the certificate. Chrome had required, since 1 January 2015, that Extended Validation certificates be logged to public Certificate Transparency logs in order to receive EV treatment. Symantec logged its test certificate because its process logged everything. Google was monitoring the logs. The gap between issuance and discovery was four days, in a world where the TURKTRUST intermediates had gone sixteen months. That single comparison is the argument for Certificate Transparency, and chapter 31 is the full account of the machinery.

What followed is a sequence of counts, each larger than the last, each produced only because somebody asked again.

Google’s second post, “Sustaining Digital Certificate Security”, dated 28 October 2015 and written by Ryan Sleevi, published the middle three figures and imposed the first sanction: from 1 June 2016, every certificate issued by Symantec had to be logged to Certificate Transparency or Chrome would not accept it. Google also required a post-mortem, a corrective action plan, a Point-in-Time Readiness Assessment and third-party audits against the WebTrust and Baseline Requirements criteria.

The 2017 escalation came from a different direction: not Symantec’s own issuance but its partners’. Sleevi’s post to the Chromium blink-dev list on 23 March 2017, “Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates”, identified four organizations that Symantec had permitted to cause issuance without adequate oversight or audit: CrossCert, Certisign, Certsuperior and Certisur. The post’s central sentence is the one that ended the negotiation: “an initial set of reportedly 127 certificates has expanded to include at least 30,000 certificates, issued over a period spanning several years.”

The proposal in that post was not immediate distrust. It was a set of escalating restrictions: reduce the maximum validity Chrome would accept from Symantec-issued certificates in stages down to nine months, and remove Extended Validation treatment for at least a year. The post also gave the scale of what was at stake, and both figures are worth having, because they explain the timetable that followed. In January 2015 Symantec-issued certificates represented more than 30 per cent of valid certificates by volume; from Mozilla Firefox telemetry, Symantec-issued certificates were responsible for 42 per cent of certificate validations, a figure Sleevi himself flagged as biased towards heavily trafficked sites and therefore overstating impact.

The settled plan was published on 11 September 2017 by Devon O’Brien, Ryan Sleevi and Andrew Whalley as “Chrome’s Plan to Distrust Symantec Certificates”. It is the canonical example of how a distrust of a large authority is sequenced.

Mozilla ran a parallel and slightly earlier schedule: Firefox 60, released on 9 May 2018, showed an untrusted connection error for Symantec certificates issued before 1 June 2016, and Firefox 63 in October 2018 completed the distrust. The work was tracked in Mozilla’s bug 1434300, “Distrust Symantec CAs affected by the distrust plan”.

The commercial ending arrived before the technical one. DigiCert agreed on 2 August 2017 to acquire Symantec’s website security and related PKI business, and completed the acquisition on 31 October 2017 for approximately 950 million US dollars in cash plus an equity stake of about 30 per cent in DigiCert. From 1 December 2017, certificates for Symantec’s brands were issued from DigiCert’s “Managed Partner Infrastructure”, and it was those certificates, not the old ones, that survived Chrome 70.

Here is the worked example, on real dates. It is a constructed site on a real timetable, which is the only part that has to be real.

Meera operates the payments page for a hospital group. In May 2016 she buys a two-year certificate from GeoTrust, one of Symantec’s brands, with a notBefore of 12 May 2016 and a notAfter of 12 May 2018. She does nothing wrong at any point. Her sequence:

1. On 11 September 2017 the plan is published. Her certificate was issued before 1 June 2016, so it is in the first group.
2. On 24 October 2017, Chrome 62 begins printing a deprecation warning in DevTools on her site. Nobody on her team opens DevTools.
3. On 17 April 2018, Chrome 66 reaches stable. Her payments page begins showing a full-page interstitial in Chrome, with the error string NET::ERR_CERT_SYMANTEC_LEGACY, twenty-five days before the certificate would have expired anyway.
4. Her replacement must come from the DigiCert Managed Partner Infrastructure, live since 1 December 2017, not from the old Symantec systems.
5. Had she instead bought in July 2017, she would have been in the second group, survived April 2018, and broken on 23 October 2018 with Chrome 70.

Two lessons from Meera’s five steps. The warning channel that browsers had — a DevTools message — reached almost nobody, which is why later distrusts leaned on direct notification through the certificate authorities and the Common CA Database. And the cut-off date that decided her fate, 1 June 2016, was the date the certificate claimed for itself, which is a field the authority controls. That observation is what the next case is about.

WoSign and StartCom, 2016: backdating, and the lie that logs caught#

The Symantec case was negligence. The WoSign case was dishonesty, which is why the sanction was faster and the recovery was never permitted.

WoSign was a Chinese certificate authority; StartCom was an Israeli one, well known for the free StartSSL certificates that were, before Let’s Encrypt, one of the few no-cost options available. Mozilla’s public issues list for the case runs to more than twenty separate findings, lettered rather than numbered. The ones that mattered fall into four groups.

The first is validation that was not validation. Mozilla’s Issue L records 72 certificates, issued between January and April 2015, where domain control was proven by demonstrating control of a service on a very high port number, above 50,000, which on shared hosting is something an ordinary tenant can do without controlling the domain. The best-known instance came from an independent researcher, Kyle Schrauger, who found that proving control of a subdomain was accepted as proving control of the parent: control of one university subdomain yielded a certificate for the university’s main domain, and control of a personal GitHub Pages subdomain yielded a certificate valid for github.com and github.io. He had not asked for those names in any meaningful sense. The system handed them over.

The second is basic certificate hygiene, at volume: 392 certificates issued in April 2015 with duplicate serial numbers, which the Baseline Requirements forbid because serial numbers must be unpredictable and unique; two intermediates sharing serial numbers with each other; and 1,132 SHA-1 certificates whose validity extended past 1 January 2017.

The third is the backdating, and it is the heart of the case. The industry had agreed that certificate authorities would stop issuing SHA-1 certificates after 31 December 2015, because SHA-1 was by then too weak to rely on. WoSign continued to issue them and set the notBefore field to December 2015 so that they appeared to predate the ban. Mozilla’s Issue S records approximately 67 such certificates, of which 62 carried notBefore dates falling on Sundays in December 2015 — an issuance pattern no real business produces — and for at least three of them backdating was demonstrated cryptographically rather than inferred.

That demonstration is the elegant part. A certificate’s notBefore field is whatever the issuing authority writes in it. But a certificate logged to a Certificate Transparency log receives a signed timestamp from the log operator, and the log operator’s signature is not something the authority can forge or move. A certificate claiming to have been issued in December 2015 that carries a log receipt from mid-2016 has told a checkable lie. Certificate Transparency was built to make misissuance visible; it turned out to also make the date on every certificate independently checkable, which is why every distrust designed after 2016 uses the log timestamp rather than the certificate’s own claim as the cut-off clock.

The fourth is disclosure. Mozilla’s Issue R records that WoSign completed full ownership of StartCom on 1 November 2015 and did not disclose it, although Mozilla policy required disclosure of exactly that. Mozilla’s decision document of 24 October 2016 states the aggravating factor without softening: the representatives “denied and continued to deny both of these allegations until sufficient data was collected to demonstrate that both allegations were correct.”

The three sanctions, in order, are a good illustration of three different distrust techniques applied to the same facts.

Apple acted first and most narrowly, blocking trust for the “WoSign CA Free SSL Certificate G2” intermediate while continuing to trust individual certificates already issued from it and published to public Certificate Transparency logs by 19 September 2016. That is the first appearance in the wild of a transparency log being used as the authoritative record of what existed before a cut-off — the direct ancestor of the mechanism Chrome uses today.

Mozilla’s decision, published on 24 October 2016, distrusted certificates with a notBefore date after 21 October 2016 chaining to the affected WoSign and StartCom roots, and required that any re-application be made with new root certificates carrying different subject names, tracked in Mozilla bugs 1311824 and 1311832. Google’s post of 31 October 2016 matched it: “Beginning with Chrome 56, certificates issued by WoSign and StartCom after October 21, 2016 00:00:00 UTC will not be trusted.”

StartCom announced the termination of its business on 16 November 2017 and stopped issuing certificates on 1 January 2018. Neither name returned to the trust stores.

What each incident changed#

The controls in the table below are the ones a working engineer meets today. Each has a chapter of its own; the point here is the causal chain, which is almost never taught.

Certificate Transparency, defined in RFC 6962 of June 2013 and updated by RFC 9162 in December 2021, is the direct descendant of the 2011 incidents. Chrome required it for Extended Validation certificates from 1 January 2015 and for all newly issued publicly trusted certificates issued after 30 April 2018. Chapter 31 is the full treatment.

CAA, the DNS record by which a domain owner names the authorities permitted to issue for it, was standardized as RFC 6844 in January 2013 and restated as RFC 8659 in November 2019. It sat almost unused for four years because checking it was optional. CA/Browser Forum Ballot 187, “Make CAA Checking Mandatory”, passed on 8 March 2017 with an effective date of 8 September 2017, and from that date a compliant authority must retrieve and honour the record before issuing. Chapter 28 covers the record syntax and the exceptions.

; The minimum useful CAA record set for a domain
example.in.  IN  CAA  0 issue "digicert.com"
example.in.  IN  CAA  0 issuewild ";"
example.in.  IN  CAA  0 iodef "mailto:security@example.in"

; Read as: only DigiCert may issue; nobody may issue a
; wildcard; report attempted violations to this address.
; Checked by the CA at issuance. NOT checked by browsers.

The last line of that block is the limitation people miss. CAA is a constraint on a well-behaved authority’s issuance process, verified by nobody at connection time. A dishonest or compromised authority that ignores the record produces a certificate that every browser accepts. CAA raises the cost of misissuance from an accident to a documented, auditable policy violation. It does not make misissuance impossible.

Name constraints are the one control that would genuinely bind a misbehaving authority, because they are enforced by the relying party during path validation, per RFC 5280 section 4.2.1.10. They are also the one control that is barely deployed on the public web. Chapter 27 covers the validation rules.

Certificate lifetimes are the industry’s admission that revocation does not work. The trajectory is worth stating exactly, with the caveat that these are maximums for publicly trusted TLS server certificates and that private PKI is unaffected.

The last three rows come from CA/Browser Forum ballot SC-081v3, which passed in April 2025. As of August 2026 the 200-day maximum is in force, having taken effect on 15 March 2026. The same ballot shortens the period for which domain validation evidence may be reused, to 200 days from 15 March 2026 and 100 days from 15 March 2027, which is the change that actually forces automation: holding a validated domain for a year and reissuing at will stops being possible. Chapter 28 covers the issuance side and chapter 30 the reasoning about revocation.

How a distrust is actually executed#

There are four mechanisms, they are not interchangeable, and choosing the wrong one either fails to contain the problem or breaks a large part of the web.

The first is the emergency blocklist. Chrome calls its version the CRLSet. Chromium’s own documentation states that “CRLSets are the primary means by which Chrome quickly blocks certificates in emergency situations”, and that online OCSP and CRL checks are not generally performed by Chrome at all. The CRLSet is delivered as a component update rather than a browser release, which is why it can be pushed in hours rather than in the six-week release cycle; this is how Google blocked the TURKTRUST intermediates on 25 and 26 December 2012 and the ANSSI intermediate in December 2013. Firefox has an equivalent called OneCRL, delivered through its remote settings channel. Both are implementation details of specific browsers rather than standards, and both are size-limited, so neither can hold every revoked certificate in the world.

 # Inspect what your Chrome has actually been given
chrome://components         # look for "CRLSet", note version

 # Fetch and dump the current CRLSet (agl/crlset-tools)
crlset fetch
crlset dump  crl-set  | head

 # Firefox equivalent
about:support               # remote settings / OneCRL state

The second mechanism is the dated cut-off, and it is the workhorse. Mozilla implements it in the NSS trust store as an attribute on the root’s trust object.

 # The shape of an NSS trust record, not a verbatim copy.
 # The real file, certdata.txt, encodes the date as an
 # octal-escaped UTCTime string such as "241111000000Z".

CKA_LABEL UTF8            "Some Root CA"
CKA_TRUST_SERVER_AUTH     CKT_NSS_TRUSTED_DELEGATOR
CKA_NSS_SERVER_DISTRUST_AFTER  <UTCTime, or CK_FALSE>
CKA_NSS_EMAIL_DISTRUST_AFTER   <UTCTime, or CK_FALSE>

 # Meaning: certificates chaining to this root whose
 # notBefore is later than the date are rejected for TLS.
 # Earlier certificates keep working until they expire.

Mozilla’s own description of the semantics is exact: “For certificates chaining up to those root certificates, Mozilla does not trust end-entity certificates that have a Valid-From date later than the specified distrust-after date.”

Chrome’s version of the same idea corrects the flaw the WoSign case exposed. Because notBefore is a field the issuing authority writes, an authority that is about to be sanctioned can backdate its way past a notBefore cut-off. Chrome therefore uses the earliest signed certificate timestamp — the receipt from a public transparency log, signed by an operator the authority does not control — as the clock. The constraint is called SCTNotAfter and it lives in the Chrome Root Store’s per-anchor constraints.

 # Chrome root store constraint, conceptual shape
trust_anchor {
  root: "Some Root CA"
  constraint {
    sct_not_after: 1753919999    # 2025-07-31 23:59:59Z
  }
}

 # Certificate is trusted if its EARLIEST SCT timestamp
 # is at or before sct_not_after. Otherwise it fails,
 # whatever the certificate's own notBefore field says.

The value in that block is the real one used for the Chunghwa Telecom and NetLock distrust announced by the Chrome Root Program on 30 May 2025: TLS certificates chaining to the affected roots whose earliest SCT was on or before 31 July 2025 at 23:59:59 UTC remained trusted, and everything logged later lost default trust in Chrome 139 and above from around 1 August 2025. The affected roots were Chunghwa Telecom’s ePKI Root Certification Authority and HiPKI Root CA - G1, and NetLock’s Arany class gold root. A command-line flag added in Chrome 128 lets administrators simulate the effect before it lands, and an explicit local or enterprise trust decision overrides the constraint, which matters for organizations that use the same certificates internally.

The immediately preceding use of the same mechanism was the Entrust distrust announced by the Chrome Root Program in June 2024, with an SCT cut-off of 11 November 2024, following what the programme described as a pattern of compliance failures and unmet commitments across a series of incident reports.

The third mechanism is outright root removal, and it is reserved for the case where nothing under the root can be trusted at all. DigiNotar in September 2011 is the only clean example in this chapter. Everything else has been executed as a cut-off followed, much later, by removal once the last legitimate certificate has expired.

The fourth is constraining rather than removing: the ANSSI and Kamu SM name constraints described earlier, and the more recent programme-level constraints that require a root used for TLS server authentication to be used only for that. Root removals of this scheduled, non-punitive kind are now routine housekeeping; several long-standing roots have published removal dates in 2026 and 2027 as authorities migrate customers onto newer, single-purpose hierarchies.

Here is the decision, drawn as browsers actually take it.

      misissuance or misconduct established
                       |
                       v
        Is the problem a specific cert or
        a specific intermediate?
              |                    |
             yes                   no
              |                    |
              v                    v
       push blocklist       Is the CA still
    (CRLSet / OneCRL)       issuing new certs?
       hours, surgical         |          |
                              yes         no
                               |          |
                               v          v
                     set a dated cut-off  let existing
                     notBefore (Mozilla)  certs expire,
                     or SCT (Chrome)      then remove
                               |
                               v
                     old certs keep working to expiry
                     new certs fail immediately
                               |
                               v
                     remove root when tail has expired

The user impact of each is different, and worth being precise about because it determines how much notice has to be given. A blocklist entry affects the handful of parties holding the blocked certificate; almost nobody notices. A dated cut-off affects nobody who already holds a certificate, and affects every new purchase from that authority immediately; the pain lands on the authority’s sales pipeline first and on subscribers only at renewal. A root removal breaks every site under it at once, presenting users with a full-page interstitial they cannot safely be trained to click through.

Chrome’s Symantec interstitial carried its own error string, NET::ERR_CERT_SYMANTEC_LEGACY, rather than the generic authority-invalid error, so that support desks could tell the two apart. It is no longer emitted by current Chrome; every certificate it applied to expired years ago.

The economics, and why sanctions are slow#

Two figures explain the entire shape of the Symantec timetable, and they are the figures Sleevi published in March 2017: more than 30 per cent of valid certificates by volume in January 2015, and 42 per cent of certificate validations by Firefox telemetry.

An authority at 42 per cent of validations cannot be removed on a Tuesday. Not because it deserves protection, but because the browser that did it would present a security warning on something close to half the encrypted web, and the predictable user response to a warning that appears on half the web is to learn to click through warnings. That is a worse security outcome than leaving the authority in place, and every root programme knows it.

So the sanction scales inversely with the offender’s size, which is exactly backwards from what a deterrence theory would want.

The industry’s answer to that asymmetry is not a better sanction. It is to make the sanction cheap by making certificates short-lived and automatically renewed. If every certificate is replaced by an automated client every few weeks, then a distrust announced with sixty days of notice costs subscribers a configuration change rather than a project. That is the real argument for the 47-day maximum arriving in March 2029, and it is why the same ballot cuts the reuse period for validation evidence: a manual process cannot survive it, which is the point.

What is still not fixed#

Five things, stated plainly, as of August 2026.

Any of the 121 roots in Firefox can still issue for any name. Name constraints would fix this and are applied to a small number of roots, all of them government or national authorities that accepted the constraint as a condition of inclusion. There is no mechanism by which a domain owner can bind their own name to a single authority in a way a browser enforces.

CAA is checked by the authority, not by the browser. It is a policy control on honest parties. Chapter 28 gives the syntax; the limitation is structural and has no proposed fix within the current architecture.

Certificate Transparency proves publication, not correctness. A misissued certificate that is properly logged is fully trusted until somebody reads the log and complains. The monitoring role is the weakest link, and it is unpaid.

Pinning, which would let a site declare its own expected authority to browsers, was tried as HTTP Public Key Pinning in RFC 7469 and abandoned, because a site that pinned incorrectly locked its own users out for the pin’s lifetime with no recovery path. Chapter 25 covers what replaced it. DANE, which places the same information in DNSSEC-signed DNS, is deployed for mail transport but not by web browsers.

And the failure mode nobody has a plan for is a root key compromise at a large authority. Every mechanism in this chapter assumes the authority’s own root key is intact and that only its processes have failed. A stolen root key would require immediate removal, which is the one action root programmes cannot take quickly against a large authority for the reasons in the previous section. This is not a hypothetical anybody has had to answer yet, and the honest position is that the industry’s readiness for it is untested.

The practical conclusion for anyone operating a service is unglamorous and worth acting on. Automate issuance so that replacing a certificate is a routine, tested operation rather than a project. Publish a CAA record so that misissuance against your name requires a documented policy violation. Watch the transparency logs for your own domains, because you are the only party with both the motive and the knowledge to spot a certificate you did not order. And be able to switch authorities, because at some point in the working life of any long-lived service, the authority you chose will be the subject of one of these posts.

35.98 Common wrong ideas#

Wrong: DigiNotar failed because it was hacked, so the lesson is that certificate authorities need better network security. Right: Network security was one of six distinct failure modes, and the rarest. Comodo in March 2011 was a stolen reseller password, TURKTRUST in 2011 was a profile copied between a test and a production system, ANSSI in 2013 was a customer misusing a correctly issued intermediate, Symantec from 2015 to 2017 was four unaudited partners and a validation process that had quietly stopped validating, and WoSign in 2016 was deliberate dishonesty by the authority itself. Only DigiNotar was an intrusion, and even there the decisive failures were a single Windows domain, a brute-forceable password and no antivirus, not an exotic attack.

Wrong: A misissued certificate gets revoked, so the damage stops when the authority notices. Right: Revocation is a statement the authority publishes, not an action taken on the client. Chrome does not perform online revocation checks in the normal case at all, both major browsers fall back to accepting a certificate when a check cannot be completed, and the pushed blocklists that do work are size-limited. Chapter 30 is the full account. Revocation is why browsers reached for dated cut-offs and 47-day lifetimes instead.

Wrong: Certificate Transparency prevents a certificate authority from issuing a certificate for your domain. Right: It makes the issuance visible within minutes to anybody reading the logs, and browsers refuse certificates that carry no log receipt, but nothing in the mechanism stops the certificate being created. Every incident from 2015 onwards in this chapter was found in a log and none was prevented by one. Somebody has to be watching, and for your own domain that somebody is you.

Wrong: A CAA record in your DNS stops other authorities from issuing certificates for your name. Right: CAA is a rule that a compliant authority must check before issuing, mandatory since 8 September 2017 under CA/Browser Forum Ballot 187. No browser checks it at connection time. A compromised or dishonest authority that ignores your record produces a certificate every browser accepts. What CAA gives you is that misissuance against your name becomes a documented, auditable policy violation rather than an accident.

Wrong: When browsers distrust a certificate authority they remove its root certificate. Right: Removal is the last step and usually happens years later. The normal action is a dated cut-off: Mozilla sets a distrust-after date and rejects certificates whose notBefore is later than it, while Chrome sets an SCTNotAfter constraint and rejects certificates whose earliest transparency log receipt is later than it. Certificates issued before the cut-off keep working until they expire, and only then is the root actually removed. DigiNotar in September 2011 is the one clean example of immediate removal in this chapter.

Wrong: The Symantec distrust was a punishment for a security breach. Right: There was no breach and no attacker. Symantec was sanctioned for issuing certificates without proper validation, for allowing four delegated partners to cause issuance without adequate oversight, and for reporting figures that grew by two orders of magnitude each time an outside party asked again: 23, then 164 plus 2,458, then 127, then at least 30,000.

Wrong: An authority can always backdate a certificate to escape a cut-off, because it writes the notBefore field itself. Right: It writes the field, but it does not write the transparency log’s signed timestamp, which is produced by an independent operator. WoSign’s SHA-1 certificates claimed December 2015 notBefore dates and carried log evidence from later; Mozilla’s Issue S records about 67 such certificates, 62 of them dated to Sundays. That is precisely why Chrome’s modern distrust constraint uses the log timestamp rather than the certificate’s own claim.

Wrong: An intermediate CA certificate is much the same as a server certificate with an extra flag set. Right: One flag, basicConstraints CA:TRUE, converts a certificate that identifies one server into an object that can mint certificates for every name on the internet, with no expiry on that power short of its own validity period and no name restriction unless a nameConstraints extension is present. TURKTRUST issued two of these by accident on 8 August 2011 and neither was noticed for sixteen months.

Wrong: Only small, obscure or foreign certificate authorities have failed. Right: The largest distrust in the history of the web PKI was executed against the largest authority in the market, which in January 2015 accounted for over 30 per cent of valid certificates and, by Firefox telemetry, 42 per cent of certificate validations. Size bought Symantec a longer timetable, not an exemption.

Wrong: If an authority misbehaves you can complain to whoever regulates it. Right: For the public web there is no regulator, no statute and no appeal. Four private root programmes — Mozilla, Apple, Microsoft and Google — each decide what ships in their own software, coordinating through the CA/Browser Forum and the Common CA Database. A distrust is a product decision enforced by a software update. The European Union’s supervisory regime for qualified trust service providers is a genuine legal structure, but it governs a different class of certificate; chapter 33 covers it.

35.99 Chapter summary in 20 lines#

1. Every certificate authority in a browser’s trust store may issue a certificate for any name in the world, and the relying party cannot tell which authority the site owner actually chose.
2. The EFF SSL Observatory counted 1,482 CA certificates from 651 organizations trusted by Windows or Firefox in 2010; the Common CA Database listed 121 roots in Firefox on 17 August 2026.
3. On 15 March 2011 an attacker used one compromised registration authority account to have Comodo issue nine certificates across seven names, including mail.google.com, login.yahoo.com and addons.mozilla.org.
4. Only one Comodo certificate was seen in use, and Comodo’s OCSP responder was already answering “revoked” when it was tested.
5. DigiNotar was compromised from 17 June 2011, issued 531 fraudulent certificates, and deleted its own records of many of them, so it could not enumerate what it had made.
6. Around 300,000 unique IP addresses, over 99 per cent of them in Iran, presented or checked the rogue Google certificate between 4 August and its revocation at 19:09 on 29 August 2011.
7. DigiNotar detected the intrusion by its own daily audit on 19 June 2011 and told nobody; the public learned on 27 August from a user’s forum post.
8. Mozilla removed the DigiNotar root in Firefox 6.0.1 with an exception for Dutch government certificates, then removed the exception in 6.0.2 and 3.6.22 on 6 September 2011; the company filed for bankruptcy on 19 September 2011.
9. On 8 August 2011 TURKTRUST issued two intermediate CA certificates by mistake, caused by test profiles being imported into a production system.
10. One of those intermediates ended up in a Checkpoint firewall appliance and generated a certificate for Google’s domains, which Chrome’s pinning rejected on 24 December 2012, sixteen months after issuance.
11. In December 2013 an intermediate under the French ANSSI root was found inside a traffic-inspection appliance on a private network, and Chrome responded by limiting that root to French and French-territory domains.
12. A name constraint applied to a root, as with ANSSI and the Turkish Kamu SM root, is the only control in this chapter that a misbehaving authority cannot simply ignore, and it is applied to very few roots.
13. Symantec’s Thawte infrastructure issued an unauthorized certificate for google.com on 14 September 2015, found within four days because Chrome had required Certificate Transparency for EV certificates since 1 January 2015.
14. The Symantec counts rose from 23 test certificates to 164 across 76 domains plus 2,458 for unregistered names, and then in March 2017 from a reported 127 partner misissuances to at least 30,000.
15. Chrome distrusted Symantec certificates issued before 1 June 2016 in Chrome 66 on 17 April 2018 and the remainder in Chrome 70 on 23 October 2018; Firefox 60 and 63 ran a parallel schedule.
16. WoSign backdated SHA-1 certificates to evade the 1 January 2016 deadline, accepted subdomain control as domain control, and concealed its acquisition of StartCom, and both names were distrusted in October 2016.
17. Transparency log timestamps proved the backdating, which is why Chrome’s modern distrust constraint uses the earliest signed certificate timestamp rather than the certificate’s own notBefore field.
18. Browsers withdraw trust in four ways: a pushed blocklist within hours, a dated cut-off that spares existing certificates, a name or purpose constraint on the root, and outright removal once the tail has expired.
19. The sanction lands on subscribers rather than on the authority, which is why a large authority receives a year of notice and a small one receives none, and why short certificate lifetimes are the industry’s real answer.
20. As of August 2026 the maximum certificate lifetime is 200 days, falling to 100 days on 15 March 2027 and 47 days on 15 March 2029 under CA/Browser Forum ballot SC-081v3.

*Chapter sources: Comodo, “Report of incident on 15-MAR-2011”, 23 March 2011, for the nine certificates, their serials, the seven subject names, the one certificate seen live, the Tehran source address 212.95.136.18 and Comodo’s own state-actor assessment; Mozilla’s security blog, “Comodo Certificate Issue - Follow Up”, 25 March 2011, for the hard-coded serial blocklist, the 22 March 2011 Firefox releases and Mozilla’s statement that withholding disclosure “was the wrong decision”; Microsoft Security Advisory 2524375, 23 March 2011, with its 16 March notification date; Fox-IT, "DigiNotar Certificate Authority breach

• Operation Black Tulip", interim report version 1.0 of 5 September 2011 by J.R. Prins, and the final Black Tulip report of August 2012, for the 6 June to 1 September 2011 timeline, the 128, 129 and 75 revocations of 19 to 27 July, the 531 fraudulent certificates of which 344 carried domain names and 187 carried “Root CA”, the per-common-name counts and unrecorded serials in annexes 5.1 and 5.2, the roughly 300,000 unique OCSP-requesting addresses with over 99 per cent in Iran, the whitelist inversion of 1 September 2011, the single Windows domain, brute-forceable password, absent antivirus and unpatched web software, and the “Janam Fadaye Rahbar” signature linking the intrusion to Comodo; Microsoft Security Advisory 2607712 of 29 August 2011 with update 2616676; Mozilla’s “DigiNotar Removal Follow Up”, 2 September 2011, for the Firefox 6.0.1 PKIoverheid exception and its withdrawal in 6.0.2 and 3.6.22 on 6 September 2011; VASCO’s bankruptcy announcement of 20 September 2011; Google’s Online Security Blog, “Enhancing digital certificate security”, 3 January 2013, and TURKTRUST’s own account on the mozilla.dev.security.policy list, January 2013, for the 8 August 2011 issuance, the test-to-production profile import and the Checkpoint appliance; Microsoft Security Advisory 2798897, 3 January 2013, naming both subordinate CAs; Mozilla’s “Revoking Trust in Two TURKTRUST Certificates”, 3 January 2013; Google’s “Further improving digital certificate security”, 7 December 2013 with its 12 December update listing the thirteen French top-level domains, and Mozilla’s “Revoking Trust in one ANSSI Certificate”, 9 December 2013; Google’s “Improved Digital Certificate Security”, 18 September 2015, and “Sustaining Digital Certificate Security”, Ryan Sleevi, 28 October 2015, for the 14 September 2015 Thawte pre-certificate and the 23, 164 over 76 domains and 2,458 figures; Sleevi’s blink-dev post “Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates”, 23 March 2017, for CrossCert, Certisign, Certsuperior and Certisur, the expansion from 127 to at least 30,000, and the over 30 per cent and 42 per cent market figures; “Chrome’s Plan to Distrust Symantec Certificates”, O’Brien, Sleevi and Whalley, 11 September 2017, for the Chrome 62, 66 and 70 dates and the 1 December 2017 Managed Partner Infrastructure cut-over; Mozilla bug 1434300 and the “Mozilla’s Plan for Symantec Roots” thread for Firefox 60 of 9 May 2018 and Firefox 63; DigiCert’s announcement of 2 August 2017 and the completion of the acquisition on 31 October 2017; the Mozilla wiki page “CA/WoSign Issues” for issues D, H, L, R and S, covering 1,132 long-lived SHA-1 certificates, 392 duplicate serials, 72 high-port validations, the undisclosed StartCom acquisition of 1 November 2015 and about 67 backdated certificates of which 62 carried Sunday dates; Mozilla’s “Distrusting New WoSign and StartCom Certificates”, 24 October 2016, with bugs 1311824 and 1311832; Apple’s “Blocking Trust for WoSign CA Free SSL Certificate G2”, 30 September 2016, with its 19 September CT cut-off; Google’s “Distrusting WoSign and StartCom Certificates”, 31 October 2016; RFC 5280 sections 4.2.1.9 and 4.2.1.10 and the path validation algorithm; RFC 6962 and RFC 9162; RFC 6844 and RFC 8659 with CA/Browser Forum Ballot 187, passed 8 March 2017 and effective 8 September 2017; RFC 6960 and the withdrawn RFC 7469; the CA/Browser Forum Baseline Requirements section 6.3.2 and relevant-dates table for the 825, 398, 200, 100 and 47 day ceilings under ballot SC-081v3 of April 2025; the Chromium Projects CRLSets page; the Mozilla wiki page “CA/Additional Trust Changes” for CKA_NSS_SERVER_DISTRUST_AFTER and the .tr constraint on the Kamu SM root; the Chrome Root Program’s Entrust distrust of June 2024 with its 11 November 2024 SCT cut-off and “Upcoming Changes to the Chrome Root Store” of 30 May 2025 for the Chunghwa Telecom and NetLock SCTNotAfter of 31 July 2025 enforced from Chrome 139; Eckersley and Burns, “An Observatory for the SSLiverse”, 2010; and the Common CA Database report “CA Certificates in Firefox”, read 17 August 2026, for the count of 121 included roots.*