DigiNotar 2011
The CA That Died in Six Weeks
A hacker breach, 531 fake certificates, 300,000 Iranians surveilled, and bankruptcy in 42 days.
Quick Facts
| CA | DigiNotar |
| Year | 2011 |
| Attack Type | External breach via unpatched web server |
| Rogue Certificates | 531+ certificates including *.google.com |
| Human Impact | ~300,000 Iranians surveilled |
| Time to Distrust | 3 days after public disclosure |
| Outcome | Bankrupt in 24 days |
| The Lesson | Security failures kill CAs. Browsers will pull the trigger. |
The 30-Second Version
How It Was Discovered
August 27, 2011 - An Iranian Gmail user named "alibo" posted on Google's product forum:
"I got this error today while I was trying to open my Gmail..."
— "alibo", Google Product Forums, August 2011
He included a screenshot showing Chrome warning about an invalid certificate for Google - issued by DigiNotar.
Chrome Was The Only Browser That Caught This
Google had implemented "certificate pinning" for their own domains - a new security feature that expected Google certificates to come from specific CAs. DigiNotar wasn't on that list.
Within 48 Hours
- •Google confirmed the certificate was fraudulent
- •Mozilla and Microsoft announced they would distrust DigiNotar
- •DigiNotar finally admitted to a breach they'd known about for 41 days
The Attack Timeline
| Date | Event |
|---|---|
| June 17, 2011 | Attacker breaches DigiNotar via unpatched web server |
| July 10, 2011 | First rogue certificate issued (*.google.com) |
| July 19, 2011 | DigiNotar discovers breach internally |
| July 19 - Aug 27 | DigiNotar attempts to contain breach quietly - tells no one |
| Aug 27, 2011 | "alibo" posts on Gmail forum - breach becomes public |
| Aug 29, 2011 | Google/Mozilla announce distrust |
| Aug 30, 2011 | DigiNotar admits to breach (41 days after discovery) |
| Sep 3, 2011 | Dutch government takes control of DigiNotar |
| Sep 6, 2011 | Dutch government severs ties - tells citizens to use "pen and paper" |
| Sep 20, 2011 | DigiNotar files for bankruptcy |
24 days
From public disclosure to bankruptcy
63 days
From breach discovery to bankruptcy
How The Breach Happened
The Attack Chain
"Pr0d@dm1n"What DigiNotar Had
- ✓HSMs (Hardware Security Modules)
- ✓Biometric access controls
- ✓Physical security (mantraps)
- ✓Network segmentation (supposedly)
What DigiNotar Failed At
- ✗Patching public-facing web servers
- ✗Strong passwords ("Pr0d@dm1n")
- ✗Real network segmentation
- ✗HSM key management
- ✗Log monitoring
- ✗Incident disclosure (41 days silent)
The HSM Problem
HSMs are supposed to protect private keys. But DigiNotar left their HSM keys in an "activated" state - meaning anyone with domain access could sign certificates without additional authentication.
"No records could be provided by DigiNotar regarding if and when smartcards were used to activate private keys"
— Fox-IT Investigation Report
CRLs (Certificate Revocation Lists) were being automatically signed during the intrusion - proving the keys were unlocked and ready to use.
The Scope: 531 Rogue Certificates
All eight CA servers were compromised. The attacker issued certificates for:
| Category | Domains |
|---|---|
| *.google.com, gmail.com, login.yahoo.com | |
| Social | facebook.com, twitter.com |
| Tech | microsoft.com, windowsupdate.com, mozilla.org, addons.mozilla.org |
| Privacy | torproject.org, *.wordpress.com, skype.com |
| Intelligence | cia.gov, mossad.gov.il, sis.gov.uk (MI6) |
| Other CAs | thawte.com, verisign.com, comodo.com |
Why Windows Update?
Could potentially push malicious "updates" to millions of computers.
Why Intelligence Agencies?
Intercept traffic from Iranians trying to contact Western intelligence services.
The Iranian Connection
Evidence Pointing to State-Sponsored Attack
300,000 OCSP Requests from Iranian IPs
DigiNotar logs showed massive certificate validation queries from Iran for the rogue Google certificate.
ISP-Level Interception Required
The MITM attack only works if you can redirect traffic. This requires ISP cooperation or control - something only a government can do.
Target Selection
Gmail (dissidents), Tor (anonymity), intelligence agencies (informants)
Attacker Signature
Same fingerprint as the Comodo breach earlier in 2011. That attacker claimed to be a 21-year-old Iranian.
How The MITM Attack Worked
The user sees a valid HTTPS connection (green padlock). The government sees everything.
Chrome users were the only ones who got warnings - certificate pinning saved them.
The Human Cost
A Dutch MP stated that DigiNotar's delayed reporting "had put lives at risk."
Security researcher Mikko Hyppönen: "activists may have died as a consequence."
If the Iranian government identified dissidents through intercepted Gmail, those individuals faced imprisonment, torture, or death.
The Collapse
Why Browsers Had to Act
Once a CA is compromised, every certificate they've ever issued becomes suspect. There's no way to know which certificates are legitimate and which are fraudulent.
The only option: complete distrust.
Browser Responses
| Browser | Action | Date |
|---|---|---|
| Chrome | Blocked DigiNotar | Aug 29 |
| Firefox | Emergency update removing DigiNotar | Aug 30 |
| Microsoft | Revoked DigiNotar trust | Aug 29 |
| Apple | Revoked in security update | Sep 9 |
Dutch Government Chaos
DigiNotar was the CA for the Dutch government's PKIoverheid (government PKI). When browsers distrusted DigiNotar, government services broke.
September 6, 2011
Government announces citizens should use "pen and paper" for official communications while new certificates are deployed.
Bankruptcy
September 20, 2011
Parent company VASCO announces DigiNotar has filed for bankruptcy.
"The company has adopted the position that there is no realistic prospect for economic recovery of DigiNotar's enterprise."
The Lessons
1.HSMs Are Not Magic
DigiNotar had HSMs. The keys were still compromised because:
- Keys were left in activated state
- No audit trail of key usage
- Network access = HSM access
HSMs protect against physical theft. They don't protect against authorized (or seemingly authorized) access.
2.Network Segmentation Must Be Real
DigiNotar's public web server was on the same Windows domain as their CA servers. One compromised server = all servers compromised.
CA infrastructure must be genuinely isolated, not just "on a different VLAN."
3.Patch Everything, Especially Public-Facing Systems
The breach started with an unpatched DotNetNuke installation. A known vulnerability with available patches.
Your security is only as strong as your weakest public-facing system.
4.Incident Response Includes Disclosure
DigiNotar knew about the breach for 41 days. They tried to handle it quietly. When the truth came out, trust was completely destroyed.
Delayed disclosure multiplies the damage. Transparency is mandatory.
5.Browser Vendors Will Pull the Trigger
Before DigiNotar, some questioned whether browsers would actually distrust a major CA. DigiNotar proved they would - and quickly.
No CA is too big to fail. Browser trust can be revoked.
The Legacy
DigiNotar's breach directly led to:
| Change | Description |
|---|---|
| Certificate Transparency | Public logs of all issued certificates, making rogue certs detectable |
| Certificate Pinning | Browsers hardcode expected CAs for major sites |
| HPKP | HTTP Public Key Pinning - site operators could pin their own certificates (later deprecated) |
| Stricter CA Audits | WebTrust and ETSI audits became more rigorous |
| Baseline Requirements | CA/Browser Forum formalized minimum security standards |
Chrome's certificate pinning caught this attack. That feature only existed because Google engineers were paranoid about exactly this scenario. DigiNotar validated their paranoia.
DigiNotar vs. Other CA Failures
| DigiNotar (2011) | Symantec (2017) | Entrust (2024) | |
|---|---|---|---|
| Cause | External breach | Internal failures | Compliance refusal |
| Disclosure | 41 days hidden | Gradual discovery | Argued publicly |
| Human Impact | ~300K surveilled, possible deaths | Business disruption | Business disruption |
| Time to Distrust | 3 days | 2+ years (gradual) | 5 months |
| Outcome | Bankrupt in 24 days | Sold to DigiCert | CA sold to Sectigo |
| Legacy | CT, pinning, audit reform | Industry consolidation | "Rules apply to everyone" |
FAQ
Why didn't antivirus or security tools catch this?
The fraudulent certificates were technically valid - properly signed by a trusted CA. That's the whole point. Security tools trusted DigiNotar, so they trusted the certificates.
Could this happen today?
Certificate Transparency makes it much harder. Any certificate issued is logged publicly, so rogue certificates would be detected quickly. But a sophisticated attacker with CA access could still cause damage before detection.
Was anyone prosecuted?
The attacker was never caught. Dutch prosecutors investigated DigiNotar for criminal negligence but filed no charges. The investigation pointed to Iran, but no individuals were identified.
What happened to the Dutch government services?
Significant disruption for weeks. New certificates had to be issued from a different CA. At one point, citizens were told to use "pen and paper" for government interactions.
How many people were actually surveilled?
Unknown. The 300,000 figure comes from OCSP validation requests - meaning 300,000 Iranian connections validated the fake Google certificate. How many were actively monitored is unclear.