DigiNotar: The 2011 Hack That Broke Trust in HTTPS Certificates
A Dutch certificate authority was hacked in 2011 and fake certificates were issued for Google and others. See how it unfolded and what it means for SSL today.
When your browser shows a padlock, it is trusting a chain of organisations called certificate authorities that vouch for the identity of websites. In 2011, one of those authorities, a Dutch company called DigiNotar, was compromised, and attackers issued fraudulent certificates for domains including google.com. The episode showed how much depends on a few trusted parties and ended with the company going out of business.
How a certificate authority works
A certificate authority, or CA, issues digital certificates that bind a domain name to a cryptographic key. Browsers and operating systems ship with a list of CAs they trust. If a trusted CA signs a certificate for a domain, the browser accepts it without complaint. That is convenient, but it also means that a compromised CA can issue a convincing certificate for any website it likes.
What happened
DigiNotar's systems were breached in June and July 2011. The attackers issued a large number of fraudulent certificates, including one for the wildcard domain *.google.com on 10 July. The company discovered the intrusion and revoked some certificates, but did not make the incident public at the time and did not revoke all of the fraudulent ones.
The problem came to light on 28 August 2011, when an Iranian Gmail user posted a warning on a Google support forum after Chrome showed a security error. Chrome contained a feature that pinned the expected certificates for Google's sites, so it refused the fake one. Google, Microsoft, Mozilla and Apple then removed DigiNotar from their trusted lists.
Who was affected
The fake Google certificate was used to intercept connections, mostly it seems from users in Iran. The Dutch security firm Fox-IT, hired to investigate, reported that more than 300,000 unique IP addresses had requested the fraudulent certificate's status, with the vast majority of them from Iran. Fox-IT concluded that the company's network had been poorly segmented and that its security was weaker than it should have been. Over 500 fraudulent certificates were identified in the end.
The incident was especially serious because DigiNotar also issued certificates used by Dutch government services. The Dutch government took operational control of the company in September 2011 and moved services to other providers. DigiNotar was declared bankrupt later that month.
What changed afterwards
DigiNotar sped up a set of reforms to the certificate system:
- Certificate Transparency. Google developed a system of public logs so certificates issued for a domain can be seen and audited. It is now widely used.
- CAA records. A DNS record that lets a domain owner state which CAs may issue certificates for the domain.
- Stricter CA audits. Browser vendors tightened requirements and became more willing to distrust CAs that fail them.
- Certificate pinning and HSTS. Stronger ways for sites to tell browsers what to expect.
Does this make HTTPS pointless?
No. The DigiNotar case shows that the system can fail, and then that it can be repaired because browsers acted quickly. Encrypting connections still protects against the large majority of everyday threats, such as snooping on public Wi-Fi. The need is to choose reputable CAs and to benefit from the monitoring that now exists.
Spotting the problem as a visitor
The Iranian user who raised the alarm did something simple and valuable: they paid attention to a browser warning. Modern browsers show full-page warnings when a certificate does not match what they expect, and these warnings exist precisely for situations like this. The habit of not clicking through such warnings is one of the most useful security habits an ordinary user can have.
It is also worth noting how the trust model has been strengthened since. Browsers now require publicly trusted CAs to log the certificates they issue in public Certificate Transparency logs, so a rogue certificate for your domain can be detected by anyone watching. Several services let domain owners subscribe to alerts when a new certificate appears for their domain, which is a straightforward form of monitoring that costs nothing.
The DigiNotar story is a reminder that security of a service rests on the weakest link in its supply chain. Your padlock depends on your certificate authority, your DNS and your hosting provider, so choose each with care and keep records of who controls what.
What a man-in-the-middle attack looks like
To use a fake certificate, an attacker has to sit between the visitor and the real website, for example by controlling a network or tampering with DNS answers. The visitor's browser then sees a certificate that appears valid, so it encrypts the connection to the attacker, who can read everything and pass it on to the real site. Because the visitor sees the usual padlock, nothing seems wrong. That is why the attack was so dangerous for people trying to read email privately under a government that wanted to watch them.
The practical lesson for site owners
Use HTTPS on every page, use certificates from an established authority, renew them automatically and consider adding a CAA record to your DNS so that only your chosen CA can issue for your domain. Keep an eye on certificate transparency logs if your domain is high-value, since they can reveal unexpected certificates.
Free certificates are included with our hosting plans; read about them on our SSL page, and see our security overview for how encryption fits with the other layers.
