DigiNotar: the certificate authority that ceased to exist

I have enough well-sourced material and four verified images. Writing the post now.

The email that broke a country's internet

On the morning of August 28, 2011, a man in Iran opened Gmail in Google Chrome and got a warning he was not supposed to see. His browser told him the encrypted connection to Google could not be trusted. He posted a screenshot to a Google support forum, puzzled, asking whether anyone else was seeing the same thing. That single post, from a user who went by "alibo," unravelled a fraud that had already been running for weeks and would, within a month, destroy a company, paralyse a national government's online services, and permanently change how the web decides who to trust. The company at the centre of it was DigiNotar, a small Dutch firm most people had never heard of. It issued the digital certificates that let browsers verify they are really talking to the website in the address bar and not an impostor. On September 20, 2011, exactly fifteen years ago today, DigiNotar filed for bankruptcy. It remains the clearest case ever of a certificate authority that was trusted by every major browser on Earth one week and erased from all of them the next.

What a certificate authority actually does

To see why one obscure Dutch company mattered so much, you need to understand the quiet machinery behind the padlock icon in your browser. When you connect to https://gmail.com, your browser and Google's server set up an encrypted channel so nobody in between can read the traffic. Encryption alone is not enough, though. You also need to know the server on the other end is genuinely Google and not an attacker who has slipped into the middle of the conversation. That guarantee comes from a digital certificate: a small signed file that says, in effect, "the holder of this cryptographic key is the legitimate operator of gmail.com." The signature comes from a certificate authority, or CA, a company your browser has been told to trust in advance. Browsers and operating systems ship with a built-in list of trusted CAs, called a root store. When a CA signs a certificate for a domain, every browser that trusts that CA will accept it without question. DigiNotar was one of a few hundred such CAs in the world, and its root was trusted by Windows, Firefox, Chrome, and macOS. Here is the structural flaw that DigiNotar would expose so vividly: any trusted CA can issue a valid certificate for any domain. There is no rule in the basic system that stops a Dutch notary's CA from signing a certificate for google.com. The whole edifice rests on the assumption that every CA, everywhere, behaves correctly all the time. As security researchers put it after the breach, the trust model offered no way to verify that assumption, and the security of the entire system was only ever as strong as its weakest CA.

A notary's business, a nation's plumbing

DigiNotar was founded in 1998 by Dick Batenburg, a Dutch notary in the town of Beverwijk, and it grew into exactly the kind of institution you would expect from that origin: careful, bureaucratic, trusted by the establishment. Its business was not flashy consumer sites but the certificates that underpin Dutch officialdom. Crucially, DigiNotar was one of the CAs authorised under PKIoverheid, the Dutch government's own public-key infrastructure. Its intermediate certificates sat beneath government roots and secured a long list of state services, including DigiD, the single login system that 17 million Dutch citizens use to file taxes, apply for benefits, and interact with municipalities. DigiNotar certificates also protected the tax authority and the national vehicle authority. When the company failed, it did not just take down a private business. It threatened to sever the trusted connections holding up a country's digital government. In January 2011, months before the breach, DigiNotar had been acquired by VASCO Data Security International, a US-listed authentication company. VASCO had bought a landmine and did not know it.

Six weeks inside the walls

The intruder got in early. According to the final Fox-IT investigation, commissioned by the Dutch government and code-named Operation Black Tulip, the first traces of the attack date to June 17, 2011. Over the following days the attacker compromised web servers in DigiNotar's external DMZ, the semi-exposed network zone facing the internet, and used them as staging posts. By July 1 the intruder had reached the Secure-net segment, where the certificate-signing servers lived. That should have been impossible, or at least very hard. It was neither. The Fox-IT investigators found a catalogue of failures so basic they are still used as a teaching example:

• All of the CA servers belonged to a single Windows domain, so one cracked credential opened everything. The administrator password could be brute-forced easily.
• There was no antivirus software on critical servers, and malware was later found running on them.
• Public-facing software was outdated and unpatched.
• There was no secure central logging. The log files sat on the very servers the attacker controlled, and investigators found they had been tampered with, which meant a clean log could not be taken as proof that nothing bad had happened. Between July 10 and July 20, the attacker used this access to sign fraudulent certificates in batches. On July 10 alone, 283 rogue certificates were signed, including the one that would matter most: a wildcard certificate for *****.google.com, valid for every subdomain Google operates. Fox-IT's final count reached at least 531 fraudulent certificates across 344 domains, a target list that reads like a paranoid's diary: Google, Yahoo, Mozilla, WordPress, Skype, Microsoft, the Tor Project, and the websites of intelligence agencies including the CIA, MI6, and Mossad.

What the certificate was for

A stolen *.google.com certificate is not, on its own, a way into anyone's account. It is the master key for a specific kind of attack: the man-in-the-middle, or MITM. Imagine every Gmail user in a country. Their traffic to Google flows through a handful of internet service providers. If someone can sit at that chokepoint and redirect the connections, they can pose as Google. Normally the impersonation collapses instantly, because the attacker cannot produce a Google certificate that browsers will accept. The fraudulent DigiNotar wildcard removed that obstacle. Armed with it, an attacker positioned inside the network could intercept a user's login, present a certificate that browsers considered perfectly valid, decrypt everything, read the username and password, and then quietly pass the traffic on to the real Google so the victim noticed nothing. That is exactly what happened, and the evidence for its scale is unusually precise. Every time a browser encountered the fake certificate, it tried to check whether the certificate had been revoked by querying DigiNotar's OCSP server (the Online Certificate Status Protocol, the mechanism browsers use to ask "is this certificate still good?"). Those queries left a log. When Fox-IT analysed it, they found roughly 300,000 unique IP addresses had checked the fraudulent Google certificate, and more than 99 percent of them were in Iran. Sixty percent of the traffic came from just four Iranian internet providers. The small remainder that fell outside Iran traced mostly to Tor exit nodes, VPNs, and proxies, in other words, to Iranians trying to evade exactly this kind of surveillance. The active interception ran for most of August 2011. Around 300,000 people, going about their ordinary online lives, had their Gmail silently opened by whoever held that certificate.

Why one browser saw what everyone missed

The attack was invisible by design, and DigiNotar's tampered logs meant the company itself did not sound the alarm. What caught it was a feature almost nobody knew existed, built into Chrome for reasons unrelated to DigiNotar. Google had recently added certificate pinning to Chrome. For its own most sensitive domains, Google hard-coded into the browser a short list of certificate authorities allowed to vouch for them. Any certificate for a Google login page signed by a CA outside that list would be rejected, no matter how technically valid it looked. DigiNotar was not on Google's list, because Google had never authorised it to issue Google certificates and had no reason to expect it would. So when Iranian users on Chrome hit the man-in-the-middle, their browsers noticed the Google certificate was signed by a CA that had no business signing for Google, and refused. That is the warning "alibo" screenshotted. Users on browsers without pinning, which in 2011 was almost all of them, saw nothing wrong at all. On August 29, Google confirmed publicly that it had detected attempted man-in-the-middle attacks against Iranian users using fraudulent DigiNotar certificates, and that Chrome users had been protected because the browser detected the bad certificate. This is worth dwelling on, because it punctures a comfortable misconception. Many people still believe that a padlock in the address bar, or a certificate that the browser accepts without complaint, means the connection is safe and the site is genuine. DigiNotar is the proof that it does not, by itself, mean that. Every one of those 300,000 intercepted connections would have shown a valid certificate, issued by a trusted authority, with no error, if the victim had been using almost any browser other than Chrome. A technically perfect certificate can be a complete fraud. Trust flows from the CA, and a CA can be compromised.

The collapse

Once the fraud was public, events moved with startling speed. On August 29, Mozilla and Microsoft began stripping DigiNotar out of their trusted root stores. Apple followed with Security Update 2011-005 on September 9 for the Mac, though iOS users waited until mid-October. Removal from the root stores was a death sentence: a CA that no browser trusts has no product left to sell. For the Dutch government the removal created its own emergency, because pulling DigiNotar's roots also invalidated the government certificates chained beneath them. On September 3, the government took operational control of DigiNotar's systems. Interior Minister Piet Hein Donner held a late-night press conference and admitted the state could not guarantee the security of its own websites, warning that a citizen "could not be sure that he is on the site where he wanted to be." For a short, surreal period, the official advice was that people should fall back on pen and paper for dealings with the government while replacement certificates were sourced from other providers. The interim Fox-IT report was published by the Dutch state on September 5. DigiNotar filed for bankruptcy on September 20. A company that had existed for thirteen years was gone in roughly three weeks, killed not by the breach itself but by the loss of the only thing a certificate authority sells: the trust of the browsers.

Who did it, and why that is still unsettled

Attribution is the part of the story that resists a clean ending, and it is worth being honest about the uncertainty rather than picking the tidiest version. Days after the breach became public, a figure calling himself Comodohacker claimed responsibility in a Pastebin post, using the same account that had claimed an earlier 2011 breach of another certificate authority, Comodo. He described himself as a 21-year-old Iranian, said his motives were political, and framed the attack partly as revenge for the Dutch army's failure to prevent the 1995 Srebrenica massacre, in which Dutch peacekeepers were present. He also claimed to have compromised four more certificate authorities, including GlobalSign. Investigators found Persian phrases embedded in some of the certificates, and judged that the same person was likely behind both the Comodo and DigiNotar intrusions, given the matching style. But a lone-hacker story sits uneasily against the shape of the attack. The fraudulent certificates were used in a nationwide interception that only a party with control over Iran's internet infrastructure could realistically have carried out, and that targeted, above all, ordinary Iranians using tools to reach Google. Fox-IT's own analysis, and later assessments by security firms, held that state involvement was the most plausible explanation, whatever the technical break-in owed to an individual. Cryptographer Bruce Schneier and others floated still other theories. The most defensible reading is the layered one: the hands-on compromise may well have been the work of a skilled individual, but the surveillance operation the certificates enabled bears the fingerprints of a state. No one has ever been prosecuted, and the full truth has never been established in public.

What DigiNotar changed

The lasting significance of DigiNotar is not the company's death but what the industry built so that the next compromise would be caught in hours rather than weeks. The central lesson was that the web had no way to know what certificates existed. A CA could issue a certificate for google.com and, unless someone happened to encounter it in the wild, no one, not Google, not the browsers, not the public, would ever find out. The answer was Certificate Transparency, proposed at Google in 2012 by engineers Ben Laurie and Adam Langley and published as RFC 6962 in 2013. The idea is deceptively simple: every certificate a CA issues must be recorded in a public, append-only, cryptographically verifiable log. Anyone can watch those logs. Google can now see, within minutes, if any CA anywhere signs a certificate for a Google domain that Google did not request. Chrome began requiring newly issued certificates to appear in these logs in 2018, and domain owners routinely monitor them today. The broader trust model tightened too. Certificate lifetimes have been steadily cut, from the five years once permitted toward a few hundred days and shrinking, so that a mistakenly issued certificate expires sooner and revocation matters less. The pinning mechanism that saved Chrome's users was generalised into a web standard and then, after it proved dangerous to operators who could lock themselves out, quietly retired in favour of transparency logs. The industry stopped assuming CAs were trustworthy and started demanding they be auditable. What has not changed is the underlying architecture. Your browser still trusts a few hundred certificate authorities, and any one of them can still, in principle, sign a certificate for any site you visit. Certificate Transparency does not prevent a bad certificate from being issued. It only guarantees that issuing one leaves a permanent, public trace. That is a real improvement, and it is also a bet: that watching is enough, that daylight deters and exposes what rules alone could not. DigiNotar is the reason the lights are on. Whether watching is genuinely enough is a question the system answers freshly every time a CA misbehaves, and it has misbehaved several times since. The next time you see that padlock, it is worth remembering that it is not a promise. It is an invitation to trust a chain of institutions you will never meet, backstopped now by the hope that if any of them lies, someone, somewhere, is reading the logs.

Sources

1. Fox-IT / ENISA, Operation Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach (2011/2012)
2. Google Online Security Blog, An update on attempted man-in-the-middle attacks (2011)
3. Threatpost, Final Report on DigiNotar Hack Shows Total Compromise of CA Servers (2012)
4. IEEE Spectrum, DigiNotar Certificate Authority Breach Crashes e-Government in the Netherlands (2011)
5. Wikipedia, DigiNotar (accessed 2026)
6. The Register, Claimed DigiNotar hacker: I have access to four more CAs (2011)
7. Threatpost, Comodo Hacker Claims Credit for DigiNotar Attack (2011)
8. The Tor Project, The DigiNotar Debacle, and what you should do about it (2011)
9. Cloudflare Blog, Introducing Certificate Transparency and Nimbus (2018)
10. Slate, How the 2011 hack of DigiNotar changed the internet's infrastructure (2016)
11. Princeton CITP, DigiNotar Hack Highlights the Critical Failures of our SSL Web Security Model (2011)