This repository aims to provide a comprehensive overview of past incidents that (SSL/TLS) Certificate Authorities have been involved in. These may be security issues, privacy issues, or basically any other kind of incident that might cause one to distrust a Certificate Authority.
This *includes* incidents that are not directly related to a company's SSL/TLS certificate issuance, but that occurred within the same organization. The reason for this is that these kind of incidents often result from poor internal policies regarding security, and it is very likely that such policies also affect the part of the organization that handles certificate issuance.
## Why?
Because there should be full transparency about these kind of issues - to *everybody*, not just browser vendors - and CAs often do not appear willing to provide this kind of transparency, sometimes going so far as to threaten with lawsuits (like WoSign [did recently](http://www.percya.com/2016/09/wosigns-secret-purchase-of-startcom.html)).
## Regarding issuance to malware sites
With some regularity, Certificate Authorities issue domain-validated certificates to websites that distribute malware, attempt to phish users, or otherwise behave maliciously. These incidents are __not__ listed here, because issuing a DV certificate to a malware site is a completely valid thing to do. A DV certificate only certifies that the client is talking to the real server for a domain, and that there are no parties inbetween that can meddle with the connection - it explicitly *does not* certify that the domain in question is trustworthy.
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.
## 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.
## The incidents
This list is sorted alphabetically by the names of the Certificate Authorities. If the CA is part of a larger organization with a different name, the CA name is what will be used for sorting purposes, but the name of the overarching organization will be listed behind it.
* __December 3, 2013:__ Google finds fraudulent certificates for Google domains, signed by ANSSI. The certificates are used for MITM attacks. ([source](https://security.googleblog.com/2013/12/further-improving-digital-certificate.html))
* __March 3, 2015:__ An intermediate CA operating under CNNIC (named MCS Holdings) is found issuing fraudulent certificates for various Google domains, for the purpose of MITM attacks. This delegation should have never occurred, as MCS Holdings was not fit to hold this kind of authority. ([source](http://arstechnica.com/security/2015/03/google-warns-of-unauthorized-tls-certificates-trusted-by-almost-all-oses/))
### Comodo
* __May 16, 2009:__ Comodo is found issuing issuing certificates to malware sites. While this in and of itself is not a problem (see the explanation at the top of this page), Comodo allegedly asked the reporter to "keep quiet" about these issuances. ([source](https://web.archive.org/web/20111204031606/http://msmvps.com/blogs/hostsnews/archive/2009/05/16/1692519.aspx))
* __March 23, 2011:__ Comodo is found issuing 9 fraudulent certificates for high-profile properties including Google and Skype. ([source](https://en.wikipedia.org/wiki/Comodo_Group#Certificate_hacking), [source](https://technet.microsoft.com/library/security/2524375))
* __February 2015:__ Comodo is found to be involved in PrivDog, an advertisement blocking application. PrivDog used an MITM approach to scan and modify traffic, but turned out to essentially break certificate validation *entirely*, in a way that is reminiscent of the Lenovo/Superfish incident. ([source](http://www.pcworld.com/article/2887632/secure-advertising-tool-privdog-compromises-https-security.html))
* __January 22, 2016:__ Chromodo, Comodo's customized Chromium browser, is found to disable the same origin policy, creating a critical security issue. The installation and workings of the browser also resemble common malware practices. ([source](https://bugs.chromium.org/p/project-zero/issues/detail?id=704))
* __June 23, 2016:__ Comodo attempts to file three different trademarks relating to the term "Let's Encrypt" (which is the name of a competing, non-profit, free certificate provider). Its CEO then tried to argue that Let's Encrypt "copied" Comodo's "90 days free" business model - despite Comodo's "free" certificates being non-renewable trial certificates, whereas Let's Encrypt certificates are truly free and renewable. ([source](https://letsencrypt.org//2016/06/23/defending-our-brand.html), [source](https://forums.comodo.com/general-discussion-off-topic-anything-and-everything/shame-on-you-comodo-t115958.0.html;msg837411#msg837411))
* __July 25, 2016:__ Comodo is found to allow UI redressing attacks in their domain validation e-mails, allowing an attacker to obtain a fraudulent certificate for a target of choice. ([source](https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html))
* __August 3, 2016:__ A Comodo employee edits the "Comodo Group" Wikipedia article to include a poorly written advertisement. ([source](https://en.wikipedia.org/w/index.php?title=Comodo_Group&diff=732876656&oldid=732361423), [source](https://in.linkedin.com/in/gopichakara))
### Digicert Malaysia
* __November 2011:__ Digicert Malaysia is blacklisted by Microsoft, Google and Mozilla after issuing 22 certificates with serious security deficiencies. Their intermediate CA certificate is also revoked by Entrust. ([source](http://www.theregister.co.uk/2011/11/03/certificate_authority_banished/))
### DigiNotar (now defunct)
* __July 10, 2011:__ DigiNotar issues fraudulent wildcard certificate for Google that is later used in an MITM attack. ([source](https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates))
* __August 2011:__ It becomes clear that hundreds of fraudulent certificates were created. The total count of fraudulent certificates is at least 531. ([source](https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates))
* __September 3, 2011:__ The Dutch government withdraws their earlier statement that the intermediate CA for Dutch government services was not affected, after an investigation by Fox-IT. ([source](https://en.wikipedia.org/wiki/DigiNotar#Steps_taken_by_the_Dutch_government))
### Entrust
* __November 2011:__ Entrust is involved in the Digicert Malaysia incident (see above), and has apparently failed to audit the intermediary CA. They revoke Digicert Malaysia's intermediate certificate after the incident becomes public. ([source](https://web.archive.org/web/20111105175853/http://www.entrust.net/advisories/malaysia.htm))
### Gemnet (owned by KPN)
* __December 2011:__ Gemnet is compromised through an unsecured and passwordless public instance of PHPMyAdmin. It is unclear whether fraudulent certificates were issued, or whether confidential information was leaked. ([source](http://webwereld.nl/security/55479-weer-certificatenleverancier-overheid-gehackt))
### Getronics / KPN Corporate Market (owned by KPN)
* __November 2011:__ Evidence surfaces that Getronics was compromised 4 years earlier, but Getronics claims that no production servers were affected. ([source](http://webwereld.nl/security/55191-kpn-stopt-uitgifte-certificaten-na-mogelijke-hack), [source](https://web.archive.org/web/20111106203252/http://www.kpn.com/corporate/overkpn/Newsroom/nieuwsbericht/KPN-stopt-uit-voorzorg-uitgifte-nieuwe-veiligheidscertificaten.htm))
### GlobalSign
* __September 2011:__ A webserver at GlobalSign is compromised. GlobalSign notes that there was no evidence of fraudulent certificate issuance, and that the issuance systems were airgapped and thus not affected. ([source](https://en.wikipedia.org/wiki/GlobalSign#2011_hacking_incident))
### Kazakh Government
* __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))
### 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))
### StartCom (now likely owned by WoSign)
* __April 2014:__ StartCom refuses to revoke certificates that were (potentially) compromised through HeartBleed. ([source](https://en.wikipedia.org/wiki/StartCom#Response_to_Heartbleed))
* __June 18, 2016:__ StartCom launches a service named "StartEncrypt", which is essentially a clone of Let's Encrypt - however, it requires the installation of a binary, with no ability to inspect the source code. (source: see `sources/startencrypt.txt`)
* __June 30, 2016:__ StartEncrypt is found to have numerous vulnerabilities, including multiple critical vulnerabilities that resulted in the possibility of misissuance for high-profile domains such as `google.com`, `facebook.com`, `live.com`, `paypal.com`, and `dropbox.com`. ([source](https://www.computest.nl/blog/startencrypt-considered-harmful-today/))
* __July 2016:__ StartCom, in its StartEncrypt API, allows issuance of SHA1 certificates, in violation of CA requirements. The certificates are also backdated to December 20, 2015, and signed by WoSign rather than StartCom. The incident was not reported to Mozilla as it should have been. ([source](https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/8leLkhpoCgAJ))
* __July 2016:__ It is reported that WoSign has quietly acquired StartCom, but is trying to keep this under wraps (see the WoSign section for details).
### Symantec
* __December 2015:__ Symantec announces the discontinuation of one of their root certificates, that was obtained in the VeriSign acquisition. However, the root certificate will not *actually* be discontinued, it will just no longer be used for *publicly* issued certificates - and Symantec intends to use it for "unspecified purposes". Consequently, the root certificate is blacklisted in all Google products. ([source](http://www.pcworld.com/article/3014712/security/google-to-revoke-trust-in-a-symantec-root-certificate.html), [source](https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&id=ALERT1941&actp=LIST&viewlocale=en_US))
* __May 26, 2016:__ Symantec is found to have provided an intermediate CA to Blue Coat, a company that develops MITM solutions and devices that are used by governments to violate human rights. ([source](https://twitter.com/filosottile/status/735940720931012608))
* __June 13, 2016:__ Symantec announces a deal to purchase Blue Coat. Given that the purpose of TLS is to *prevent* MITM attacks, this makes their position as a CA extremely dubious. ([source](http://www.theregister.co.uk/2016/06/14/symantec_blue_coat_analysis/))
### Trustwave
* __February 2012:__ Trustwave is found to have issued subordinate certificates to customers for the purpose of executing MITM attacks. ([source](https://groups.google.com/d/msg/mozilla.dev.security.policy/ehwhvERfjLk/XyHxrYkxdnsJ))
### TÜRKTRUST
* __Late 2011:__ TÜRKTRUST hands out subordinate certificates to the Turkish government and a Turkish bank and fails to disclose the existence of these certificates, allowing these organizations to issue their own (CA-validated) certificates. One of these certificates was used to issue a certificate for `gmail.com`. ([source](https://freedom-to-tinker.com/blog/sjs/turktrust-certificate-authority-errors-demonstrate-the-risk-of-subordinate-certificates/))
### Verisign (CA is now owned by Symantec)
* __2010:__ Verisign is compromised, and undisclosed information is obtained by the attackers. ([source](http://www.reuters.com/article/us-hacking-verisign-idUSTRE8110Z820120202))
### WoSign
* __April 23, 2015:__ WoSign incorrectly issues a certificate for a university system by allowing the applicant to verify their ownership on a high port - while not in violation of CA requirements at the time, this is widely understood to be a bad idea. The incident was not reported to Mozilla as it should have been. ([source](https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/8leLkhpoCgAJ))
* __June 2015:__ WoSign incorrectly issues certificates for the base domains `www.ucf.edu`, `github.com`, `github.io`, and `www.github.io`, after an applicant verified their control of a *subdomain*. All of these certificates appear to have *not* been revoked at the time of writing (September 2016). The incident was, again, not reported to Mozilla as it should have been. ([source](https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com), [source](https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/8leLkhpoCgAJ), [source](http://www.percya.com/2016/08/chinese-ca-wosign-faces-revocation.html))
* __August 2015:__ WoSign leaks SMTP credentials of their live support system, due to a misconfigured PHP instance that displays a full stacktrace. ([source](https://www.lowendtalk.com/discussion/comment/1242533/#Comment_1242533))
* __July 2016:__ WoSign is reported to have acquired StartCom, the evidence of which is published at letsphish.org. ([source](https://archive.is/8bSp6), full WARC archive in `sources/wosign-acquisition`)
* __September 2016:__ WoSign threatens the author of letsphish.org with legal action, despite his publication being based on public information. They also attempt to prevent the information from spreading further by claiming that any third-party distribution will result in more penalties for the original author. ([source](http://www.percya.com/2016/09/wosigns-secret-purchase-of-startcom.html), [source](https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/HpXF7QgMDQAJ))
