DigiNotar Certificate Authority Breach (2011)

DigiNotar was a certificate authority accredited under the Dutch government's PKIoverheid program and included in the trust stores of Mozilla, Microsoft, Apple and Google. Its cryptographic material was authoritative for issuing certificates that browsers and operating systems trusted by default.

Because a CA sits at the top of the web's trust chain, a breach that lets attackers issue certificates is qualitatively different from a normal enterprise breach. It allows undetectable interception of encrypted traffic to any target for which a certificate is issued.

June to July 2011. Attackers, later self-identified as the ComodoHacker, gained access to DigiNotar's CA infrastructure. Segmentation between administrative networks and CA signing systems was insufficient to contain them.

10 July 2011. A rogue *.google.com certificate was issued from a DigiNotar CA.

Late July onwards. Attackers issued more than 500 fraudulent certificates for a wide range of domains, including CIA.gov, MI6.gov.uk and multiple social media, email and update services.

27 August 2011. Google users in Iran reported certificate warnings; the fraudulent *.google.com certificate was actively used to intercept traffic in Iran.

29 August 2011. DigiNotar publicly acknowledged the breach after initial private notification to the Dutch government.

Early September 2011. Mozilla, Microsoft, Google and Apple removed DigiNotar roots from their trust stores.

20 September 2011. DigiNotar's parent company filed for bankruptcy. The Dutch government assumed emergency operation of PKIoverheid services previously issued by DigiNotar.

In plain English: attackers got into DigiNotar's network, reached the systems that produced digital certificates, and used them to sign certificates for websites they did not own.

• Public-facing systems with weak patching created the initial foothold.
• Weak segmentation between corporate IT and CA signing infrastructure allowed lateral movement to sensitive systems.
• Administrative credentials on CA infrastructure were re-used and inadequately protected.
• Fraudulent certificates were issued without effective out-of-band approval controls.
• DigiNotar's incident-response processes did not immediately trigger revocation and public notification.

DigiNotar was a supplier every internet user unknowingly depended on. That is the essence of a trust-chain vendor.

• Root trust concentration. A single commercial CA's compromise affected every user of every browser.
• Opaque operational controls. Downstream relying parties had no visibility into CA internal segmentation or issuance approval workflows.
• Delayed disclosure. Weeks passed between initial compromise and browser-level revocation.
• Regulatory blind spots. National accreditation did not translate into operational assurance.
• Absence of certificate transparency. There was no public log allowing detection of rogue issuance in real time.

• DigiNotar bankrupt within weeks of disclosure.
• Dutch government emergency response to replace certificates issued for critical national infrastructure.
• Estimated 300,000 Iranian internet users targeted through active man-in-the-middle interception.
• Long-term acceleration of Certificate Transparency (CT) standards and browser distrust workflows.
• Structural changes in how commercial CAs are audited under WebTrust and CA/Browser Forum baseline requirements.

DigiNotar directly catalysed Certificate Transparency, first proposed by Google engineers in 2012 and now required by every major browser. Public CT logs make rogue certificate issuance detectable by anyone monitoring for a domain.

The case also permanently shifted the browser vendor community's view of CA governance. Trust removal is no longer a theoretical sanction; it is an operational tool that has since been used against multiple CAs including CNNIC, WoSign and Symantec's CA business.

DigiNotar was not a small vendor operated by hobbyists. It was a licensed, audited, government-accredited CA with contractual customers across Dutch national infrastructure. The lesson is not that CAs vary in quality; it is that accreditation and audit reports are point-in-time and cannot themselves prevent operational compromise.

1. Include CA vendors in the TPRM inventory as trust-chain suppliers.
2. Monitor Certificate Transparency logs for unauthorized issuance of certificates for your domains.
3. Deploy CAA DNS records to constrain which CAs may issue certificates for your domains.
4. Diversify CA usage across independent providers for critical services.
5. Require CA vendors to attest to segmentation between corporate IT and signing infrastructure.
6. Track CA revocation risk as a board-visible operational metric.
7. Maintain a documented CA-switching playbook to be exercised at least annually.
8. Assess governance controls, not only WebTrust attestation dates.

"A certificate authority does not fail like a normal vendor — when it fails, the padlock lies for everyone."