This directory contains a number of certificates and public keys which are considered blocked within Chromium-based products.
When applicable, additional information and the full certificate or key are included.
Entries are recorded in cert_verify_proc_blocklist.inc. The filename is the SHA-256 hash of the DER-encoded certificate, which can be obtained via:
openssl x509 -in path/to/cert.pem -outform DER | openssl dgst -sha256
The entries in the cert_verify_proc_blocklist.inc file can be generated via:
openssl x509 -in path/to/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c | awk '{print "0x" $2}' | sed 's/:/, 0x/g'
google.com.bd certificates from Comodo.
For details, see https://groups.google.com/g/mozilla.dev.security.policy/c/dSeD3dgnpzk/m/iAUwcFioAQAJ
As a result of a long-standing pattern of misissuances and incomplete or insufficient remediations, trust in TLS server certificates from Camerfirma was fully removed.
For details, see https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html
As a result of misissuance of a sub-CA certificate, CNNIC end-entity certificates were temporarily allowlisted, and then trust in the root fully removed.
For details, see https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html, https://blog.mozilla.org/security/2011/03/25/comodo-certificate-issue-follow-up/, and https://technet.microsoft.com/en-us/library/security/2524375.aspx.
As the result of a compromise of a partner RA of Comodo, nine certificates were misissued, for a variety of online services.
SPKI for an intermediate under the DCSSI root (French government) that was used to misissue gstatic.com certificates.
For details, see https://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html and https://en.wikipedia.org/wiki/DigiNotar.
As a result of a complete CA compromise, the following certificates (and their associated public keypairs) are revoked.
For details, see https://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html and https://technet.microsoft.com/en-us/library/security/2982792.aspx
An unknown number of misissued certificates were issued by a sub-CA of India CCA, the India NIC. Due to the scope of the misissuance, the sub-CA was wholly revoked, and India CCA was constrained to a subset of India's ccTLD namespace.
google.lk certificate from Sectigo. https://crt.sh/?id=4037732415
A precert that appeared in the CT logs for (www.)google.com, issued by Thawte. See https://crt.sh/?id=9314698.
google.tg certificates from Let's Encrypt. https://crt.sh/?id=245397170 and others.
Another incident in August 2019.
To coincide with the release of M111, the Chrome Root Program announced a distrust of the CA Owner “TrustCor”.
For details, see https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/PKpJf5W6AQAJ
For details, see https://www.trustwave.com/Resources/SpiderLabs-Blog/Clarifying-The-Trustwave-CA-Policy-Update/ and https://bugzilla.mozilla.org/show_bug.cgi?id=724929
Two certificates were issued by Trustwave for use in enterprise Man-in-the-Middle. The following public key was used for both certificates, and is revoked.
For details, see https://googleonlinesecurity.blogspot.com/2013/01/enhancing-digital-certificate-security.html and https://web.archive.org/web/20130326152502/http://turktrust.com.tr/kamuoyu-aciklamasi.2.html
As a result of a software configuration issue, two certificates were misissued by Turktrust that failed to properly set the basicConstraints extension. Because these certificates can be used to issue additional certificates, they have been revoked.
For details, see https://blog.torproject.org/blog/security-vulnerability-found-cyberoam-dpi-devices-cve-2012-3372
Device manufacturer Cyberoam used the same private key for all devices by default, which subsequently leaked and is included below. The associated public key is blocked.
For details, see http://www.dell.com/support/article/us/en/19/SLN300321 and http://en.community.dell.com/dell-blogs/direct2dell/b/direct2dell/archive/2015/11/23/response-to-concerns-regarding-edellroot-certificate
The private keys for both the eDellRoot and DSDTestProvider certificates were trivially extracted, and thus their associated public keys are blocked.
For details, see https://www.mitel.com/support/security-advisories/mitel-product-security-advisory-17-0001
Certain Mitel products shipped with extractable private keys, the public certs for which users were encouraged to install as anchors.
Certs with disclosed private keys from Sennheiser HeadSetup software.
For details, see https://blog.pivotal.io/labs/labs/sslip-io-a-valid-ssl-certificate-for-every-ip-address
A subscriber of Comodo's acquired a wildcard certificate for sslip.io, and then subsequently published the private key, as a means for developers to avoid having to acquire certificates.
As the private key could be used to intercept all communications to this domain, the associated public key was blocked.
For details, see https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html
A user of xs4all was able to register a reserved email address that can be used to cause certificate issuance, as described in the CA/Browser Forum's Baseline Requirements, and then subsequently published the private key.
For details, see https://www.eff.org/deeplinks/2015/02/how-remove-superfish-adware-your-lenovo-computer
Superfish software with an associated root certificate came preinstalled on Lenovo computers. The software used a single root certificate across all computers, and the private key was trivially extracted; thus the associated public key was blocked.
For details, see https://bugzilla.mozilla.org/show_bug.cgi?id=1242758 and https://bugzilla.mozilla.org/show_bug.cgi?id=1224104
These two intermediates were retired by DigiCert, and blocked for robustness at their request.
X.509v1 CA cert issued by E-GUVEN. Removed from some but not all root stores.
The following keys were reported as used by Hacking Team to compromise users, and are blocked for robustness.
“Lost” intermediate from Japan Certification Services. See https://bugzilla.mozilla.org/show_bug.cgi?id=1314464, https://crt.sh/?id=6320.
For details, see https://technet.microsoft.com/en-us/library/security/3046310.aspx
A user of live.fi was able to register a reserved email address that can be used to cause certificate issuance, as described in the CA/Browser Forum's Baseline Requirements. This was not intended by Microsoft, the operators of live.fi, but conformed to the Baseline Requirements. It was blocked for robustness.
https://bugzilla.mozilla.org/show_bug.cgi?id=1423400
For details, see https://security.googleblog.com/2019/08/protecting-chrome-users-in-kazakhstan.html
For details, see https://bugzilla.mozilla.org/show_bug.cgi?id=1188582
This intermediate certificate was retired by SECOM, and blocked for robustness at their request.
For details, see https://bugzilla.mozilla.org/show_bug.cgi?id=966060
These three intermediate certificates were retired by Symantec, and blocked for robustness at their request.
For details, see https://bugzilla.mozilla.org/show_bug.cgi?id=1076940
This intermediate certificate was retired by T-Systems, and blocked for robustness at their request.
For details, see https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html