@ -14,6 +14,14 @@ With some regularity, Certificate Authorities issue domain-validated certificate
Of course, cases where eg. an Extended Validation certificate is incorrectly issued will still be listed, as these constitute a failure of the Certificate Authority to appropriately verify the identity of the applicant.
## Incidents that are out of scope
The following types of incidents are __not__ listed here, as they do not indicate an issue with a Certificate Authority's trustworthiness:
* Issuance of domain-validated certificates to malicious sites (see above)
* Certificates that are misused after having been fraudulently obtained from a legitimate third party ("stolen certificates")
* Infrastructure downtime that is not related to a compromise
## Contributing
If you're aware of an incident that is not listed here, feel free to open a pull request. Please make sure to include a clear source describing the incident, preferably in English.
@ -70,6 +78,12 @@ This list is sorted alphabetically by the names of the Certificate Authorities.
* __December 2015:__ The Kazakh government announces that it will require each citizen to install a custom Certificate Authority root, that will allow MITM attacks by the government. It's unclear what organization is tasked with maintaining the CA. ([source](http://www.slate.com/blogs/future_tense/2015/12/14/kazakhstan_wants_citizens_to_download_a_mandatory_national_security_certificate.html), [source](https://bugzilla.mozilla.org/show_bug.cgi?id=1229827))
### Let's Encrypt
* __December 7, 2015:__ A bug in Let's Encrypt's issuance software leads to potentially incorrect issuance of certificates to domains that disallow this through a [CAA DNS record](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization). The issue is fixed in about 3 hours, and publicly disclosed (with fraudulent certificates revoked) within 15 hours. ([source](https://community.letsencrypt.org/t/caa-check-incident-december-7-2015/9633))
* __May 16, 2016:__ A bug in Let's Encrypt's build tooling leads to an accidental disclosure of GitHub API keys, allowing anybody viewing Travis builds to push (malicious) code to the repository. Upon being reported, the key is invalidated, and the repository is audited for unauthorized changes (of which there turn out to be none). ([source](https://community.letsencrypt.org/t/github-api-key-leak-may-16-2016/16032))
* __June 11, 2016:__ A bug in Let's Encrypt's mass-mailing software leads to an accidental disclosure of subscriber e-mail addresses while sending out an e-mail concerning updates to the Subscriber Agreement - every recipient receives the actual message, plus the e-mail addresses of all those before them. After 7618 e-mails, the e-mail script was terminated, and the bug was fixed. ([source](https://community.letsencrypt.org/t/email-address-disclosures-june-11-2016/17025))
### National Informatics Centre (India)
* __July 8, 2014:__ Google announces that it has detected fraudulently certificates for various Google domains, issued by the National Informatics Centre of India. The certificates were likely used for an MITM attack. ([source](https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html))
@ -98,6 +112,7 @@ This list is sorted alphabetically by the names of the Certificate Authorities.
### Verisign (CA is now owned by Symantec)
* __March 2003:__ VeriSign is found to have issued a fraudulent code signing certificate in the name of Microsoft Corporation. This allows an attacker to pretend that their software was verified and signed by Microsoft. ([source](https://technet.microsoft.com/en-us/library/security/ms01-017.aspx))
* __2010:__ Verisign is compromised, and undisclosed information is obtained by the attackers. ([source](http://www.reuters.com/article/us-hacking-verisign-idUSTRE8110Z820120202))
Sven Slootweg