ca-incidents/README.md

Certificate Authority incidents

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).

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.

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.

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.

ANSSI

• December 3, 2013: Google finds fraudulent certificates for Google domains, signed by ANSSI. The certificates are used for MITM attacks. (source)

CNNIC

• 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)

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)
• March 23, 2011: Comodo is found issuing 9 fraudulent certificates for high-profile properties including Google and Skype. (source, source)
• 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)
• 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)
• 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, source)
• 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)
• August 3, 2016: A Comodo employee edits the "Comodo Group" Wikipedia article to include a poorly written advertisement. (source, source)

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)

DigiNotar

Now defunct.

• July 10, 2011: DigiNotar issues fraudulent wildcard certificate for Google that is later used in an MITM attack. (source)
• August 2011: It becomes clear that hundreds of fraudulent certificates were created. The total count of fraudulent certificates is at least 531. (source)
• 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)

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)

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)

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, source)

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)
• October 13, 2016: GlobalSign erroneously revokes an intermediary certificate, leading to certificate validation errors for many (major and smaller) customers, on otherwise valid certificates. (source)

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, source)

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. The issue is fixed in about 3 hours, and publicly disclosed (with fraudulent certificates revoked) within 15 hours. (source)
• 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)
• 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)

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)

StartCom

Now owned by WoSign, and has been quietly operating under WoSign for an unknown length of time, prior to public disclosure.

• December 2008: StartCom's founder, Eddy Nigg, obtains a fraudulent certificate from Comodo for mozilla.com. While this was allegedly for the purpose of demonstrating an issue with Comodo, Nigg subsequently uses the certificate on a public-facing web server, and threatens the release of its private key. (source)
• April 2014: StartCom refuses to revoke certificates that were (potentially) compromised through HeartBleed, thereby violating CA requirements. (source, source)
• May 2014 (and ongoing?): StartCom issues multiple certificates that are shorter than the required 2048 bits, thereby violating CA requirements. This is allegedly due to a software bug, but StartCom has failed to provide further details or clear remediation. (source)
• June 2014: StartCom issues at least ~30 certificates with duplicate serial numbers, and fails to timely respond to a report about this from Mozilla. (source)
• October 2015: StartCom's OCSP server experiences severe delays in confirming newly issued certificates, leading to certificate validation errors in Firefox for otherwise valid certificates. (source, source)
• October 2015: StartCom fails to verify that the RSA public key exponent for a certificate equals 3 or higher, thereby violating CA requirements. (source)
• April 2016: StartCom issues 7 certificates that are missing a localityName and stateOrProvinceName, thereby violating CA requirements. (source)
• May 2016: StartCom issues certificates using the disallowed secp256k1 curve, thereby violating CA requirements. (source)
• 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)
• 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)
• 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, source)
• 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)
• 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)

Trustwave

• February 2012: Trustwave is found to have issued subordinate certificates to customers for the purpose of executing MITM attacks. (source)

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)

Verisign

The CA part of VeriSign 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)
• 2010: Verisign is compromised, and undisclosed information is obtained by the attackers. (source)

WoSign

• March 2015: WoSign is found to have issued over a thousand SHA1 certificates since January, that have a validity beyond January 1st, 2017. While not forbidden by CA requirements at the time, it was already strongly recommend against for security reasons. (source)
• March 2015: WoSign issues two certificates that are identical in every sense, including their serial number, except for their notBefore (ie. validity start) dates. (source)
• April 2015: WoSign issues 392 certificates with duplicate serial numbers. (source)
• April 2015: WoSign violates a large number of CA requirements, and is found not to follow their own Certification Practice Statement. (source) (source)
• 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, source)
• 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, source, source, source)
• August 2015: WoSign leaks SMTP credentials of their live support system, due to a misconfigured PHP instance that displays a full stacktrace. (source)
• November 2015: WoSign issues two certificates that use an unapproved cryptographic algorithm, and that appear to be duplicates of other certificates, including their serial number. (source)
• January 2016: WoSign is caught backdating at least 60 certificates by a month, thus preventing browsers from blocking these certificates for the use of SHA1 after January 1st, 2016. (source)
• June 2016: A certificate for alicdn.com that was issued by WoSign appears to be fraudulent. (source)
• July 2016: WoSign is involved in issuance of backdated SHA1 certificates in StartCom's StartEncrypt API, signed by WoSign rather than StartCom. The incident was not reported to Mozilla as it should have been. (source)
• July 2016: WoSign is reported to have acquired StartCom in November of 2015, the evidence of which is published at letsphish.org. (source, full WARC archive in sources/wosign-acquisition, source)
• 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, source)