Timeline of PKI Security Failures

Explore the timeline of publicly-disclosed certificate authority failures.

2001 - VeriSign

An attacker posing as a Microsoft employee convinces VeriSign to issue two unauthorized code signing certificates for Microsoft.

Root cause: Insufficient validation of the request by VeriSign.

2008 - Thawte

Mike Zusman registers the email address sslcertificates@live.com and uses it to obtain a rogue SSL certificate from Thawte for Microsoft's live.com.

Root cause: Thawte allowed domain validation emails to be sent to an email address (sslcertificates@live.com) that wasn't commonly reserved as an administrative address.

2008 - StartCom

Mike Zusman exploits a flaw in StartCom's web interface to obtain certificates for domains without proper authorization.

Root cause: The StartCom web interface was blindly trusting user input, allowing domain validation emails to be sent to arbitrary email addresses at unrelated domains.

2008 - Comodo

Eddy Nigg discovers that Certstar, a Comodo reseller, was not performing domain control validation of any kind and exploits this to obtain a rogue certificate for www.mozilla.com.

Root cause: Comodo was trusting resellers to perform domain control validation, which is a critical certificate authority function, instead of doing it themselves.

2009 - Null prefix attack

Moxie Marlinspike gets a certificate from ipsCA for a DNS name containing a null character. Although ipsCA correctly validates the DNS name as belonging to Moxie's domain, the null character tricks some clients into thinking the certificate belongs to www.paypal.com, enabling impersonation of PayPal.

Root cause: TLS clients were only comparing DNS names up to the first null character instead of in their entirety. ipsCA was allowing null characters in DNS names despite this being a violation of X.509 standards.

Cert Spotter detects null prefix attacks and alerts the owner of the domain being targeted.

2011 - Comodo

An attacker by the alias "Comodohacker" compromises several Comodo resellers and obtains rogue certificates for www.google.com, mail.google.com, addons.mozilla.org, login.live.com, login.yahoo.com, and login.skype.com.

Root cause: Comodo was trusting resellers to perform domain control validation, which is a critical certificate authority function, instead of doing it themselves.

2011 - DigiNotar

An unknown attacker completely compromises DigiNotar and after obtaining full administrative access to all critical CA systems, issues rogue certificates for numerous domains. Over 500 fake certificates are detected, but the full extent of the breach remains unknown. A rogue wildcard certificate for google.com is used for mass interception of traffic from Iranian citizens.

Root cause: Insufficient network segmentation and generally poor security practices allowed the attacker to completely compromise DigiNotar after exploiting a vulnerability in a publicly-facing web server running out-of-date software.

2011 - TurkTrust

TurkTrust accidentally issues two intermediate CA certificates to subscribers. These intermediate certificates can be used to forge certificates for any domain on the Internet. Sixteen months later, one of them is used to forge a certificate for google.com.

Root cause: TurkTrust mistakenly applied a security policy from their test environment to their production environment, causing unconstrained intermediate CA certificates to be issued instead of regular end-entity certificates.

2014 - NICCA

The National Informatics Centre (NIC) of India, a subordinate CA of the Indian Controller of Certifying Authorities (India CCA), issues rogue certificates for Google and Yahoo domains. NIC claims that their issuance process was compromised and that only four certificates were misissued. However, Google is aware of misissued certificates not reported by NIC, so it can only be assumed that the scope of the breach is unknown.

Root cause: Compromise of certificate authority, with unknown scope.

2015 - CNNIC

CNNIC, in violation of their certificate practice statement, willfully issues an unconstrained intermediate CA certificate to MCS Holdings, an organization with no certificate practice statement or technical infrastructure whatsoever to operate a certificate authority. MCS Holdings uses the intermediate CA to forge certificates for Google and likely other domains.

Root cause: CNNIC violated their certificate practice statement and failed to properly oversee the practices of their subordinate certificate authorities.

CNNIC has been distrusted by web browsers and Google will require that they log all certificates to Certificate Transparency logs before they are trusted again.

2015 - WoSign

A researcher discovers that WoSign will perform domain control validation via unprivileged TCP ports and uses this to obtain an unauthorized certificate for a university. Despite being informed of the misissuance, WoSign fails to notify web browsers and the incident is not noted in WoSign's annual audit. It will not be publicly disclosed until a year later.

Root cause: WoSign was allowing unprivileged TCP ports (1024 and above) to be used for domain control validation. Since non-administrative users are typically allowed to accept connections on unprivileged TCP ports, this allowed users to obtain certificates for domains they did not administer.

WoSign has announced that all certificates they issue will be logged to Certificate Transparency logs.

2015 - WoSign

Stephen Schrauger discovers that WoSign will issue certificates for base domains even if the applicant only controls a sub-domain. Schrauger accidentally discovers this when he receives a certificate for www.ucf.edu despite only administering med.ucf.edu. As a proof of concept, Schrauger obtains two unauthorized certificates for GitHub. Although WoSign is informed of the unauthorized GitHub certificates, they fail to discover the unauthorized www.ucf.edu certificate or report the incident to web browsers. The incident is not noted in WoSign's annual audit and will not be publicly disclosed until a year later.

Root cause: WoSign was allowing control of a sub-domain to be used to prove control of a base domain.

WoSign has announced that all certificates they issue will be logged to Certificate Transparency logs.

2015 - Let's Encrypt

SSLMate founder Andrew Ayer discovers that ACME, the automated issuance protocol used by Let's Encrypt, suffers from a cryptographic flaw that would allow attackers to fraudulently obtain certificates for domains they don't control. The flaw had gone undetected during a formal security audit. Fortunately, the flaw is discovered and fixed before Let's Encrypt goes live.

Root cause: ACME was misusing digital signatures by assuming a nonexistent security property.

Let's Encrypt voluntarily logs all certificates they issue to Certificate Transparency logs.

2015 - Symantec

Over a period of several years, Symantec willfully issues over 100 test certificates for 76 different domains without the authorization of the domain owners. This is discovered when Google's Certificate Transparency log monitor detects an unauthorized certificate for google.com in Certificate Transparency logs.

Root cause: Symantec was willfully disregarding industry regulations by issuing trusted certificates without proper authorization.

Google now requires that all certificates issued by Symantec be logged to Certificate Transparency logs.

2015 - Symantec

Andrew Ayer discovers that Symantec is not properly extracting administrative email addresses from whois records, allowing attackers to fraudulently obtain certificates from Symantec for domains whose whois emails contain special characters such as plus. Symantec fixes the vulnerability and it is not believed to have been exploited.

Root cause: Symantec was unrobustly parsing domain whois records and failing to consider special characters such as + as valid characters for an email address.

2016 - StartCom

Thijs Alkemade discovers that StartCom's brand new automated issuance API suffers from numerous flaws, including flaws that had previously been discovered and fixed by other CAs, that would allow attackers to obtain certificates for domains they don't control.

Root cause: StartCom ignored developments in the standards community and instead chose to design their own, insecure automated issuance API.

StartCom has announced that all certificates they issue will be logged to Certificate Transparency logs.

2016 - Comodo

Matthew Bryant discovers that Comodo's domain validation emails are susceptible to dangling markup injection, allowing attackers to obtain unauthorized certificates if the domain administrator opens the validation email in an email client that supports HTML. Comodo fixes the vulnerability and it is not believed to have been exploited.

Root cause: Comodo was not properly sanitizing attacker-controlled input when emailing out domain control validation emails.

Start Monitoring with Cert Spotter Today

Better visibility means better uptime and security. Cert Spotter gives you the visibility you need for your certificates.

Click to sign up