We have been alerted about applications that use the root store provided by Mozilla for purposes other than what Mozilla’s root store is curated for. We provide a root store to be used for server authentication (TLS) and for digitally signed and encrypted email (S/MIME). Applications that use Mozilla’s root store for a purpose other than that have a critical security vulnerability. With the goal of improving the security ecosystem on the internet, below we clarify the correct and incorrect use of Mozilla’s root store, and provide tools for correct use.

Background on Root Stores: Mozilla provides a root store (curated list of root certificates) to enable Certificate Authorities (CAs) to issue trusted TLS certificates which in turn enables secure browsing and encryption on the internet. The root store provided by Mozilla is intended to be used for server authentication (TLS) and for digitally signed and encrypted email (S/MIME). The root store is built into Firefox and Network Security Services (NSS). The NSS cryptographic library is a set of libraries designed to support cross-platform development of security-enabled client and server applications; it is open source and therefore has become the de-facto standard for many Linux-powered operating systems. While NSS includes Mozilla’s root store by default, it also provides the ability for developers to use their own root store, enabling application developers to provide a list of root certificates that is curated for use cases other than TLS and S/MIME.

Misuse of Root Stores: We have been alerted that some applications are using root stores provided by Mozilla or an operating system (e.g. Linux) for purposes other than what the root store is curated for. An application that uses a root store for a purpose other than what the store was created for has a critical security vulnerability. This is no different than failing to validate a certificate at all.

There are different procedures, controls, and audit criteria for different types of certificates. For example, when a CA issues a certificate for S/MIME, it ensures that the email address in the certificate is controlled by the certificate subscriber. Likewise, when a CA issues a certificate for TLS, it ensures that the domain names in the certificate are controlled by the certificate subscriber. For a CA who has only been evaluated in terms of their issuance of S/MIME certificates there is no indication that they follow the correct procedures for issuance of TLS certificates (i.e. that they properly validate who controls the domain names in the certificate). Similarly, for a CA who has only been evaluated in terms of their issuance of TLS certificates there is no indication that they follow the correct procedures for issuance of Code Signing certificates.

Additionally, some application developers directly parse a file in Mozilla’s source code management system called certdata.txt, in which Mozilla’s root store is maintained in a form that is convenient for NSS to build from. The problem with the scripts that directly parse this file is that some of the certificates in this file are not trusted but rather explicitly distrusted, so scripts that do not take the trust records into account may be trusting root certificates, such as the DigiNotar certificates, which Mozilla explicitly distrusts.

Correctly using Root Stores: Curating a root store is a costly ongoing responsibility, so the Common CA Database (CCADB) Resources tab provides lists of root certificates that are being curated for the purposes of Code Signing, Email (S/MIME), and Server Authentication (SSL/TLS). The Code Signing root certificate list is based on the data that Microsoft maintains in the CCADB for their root store. The Email (S/MIME) and Server Authentication (SSL/TLS) root certificate lists are based on the data that Mozilla maintains in the CCADB for Mozilla’s root store (aka the NSS root store). These lists of certificates may be used for their intended purposes; specifically Code Signing, S/MIME, or TLS. If you choose to use one of these lists, be sure to read the data usage terms and to update the list in your applications frequently.

We recommend that you use the certificate lists provided on the CCADB Resources page rather than directly parsing the certdata.txt file. Application developers who continue to parse the certdata.txt file should use a script that correctly takes the trust records into account.

It is important to note that decisions that a root store operator makes with regards to inclusion or exclusion of CA certificates in its root store are directly tied to the capabilities and behaviors of the software they are distributing. Additionally, a security change could be made wholly or partly in the software instead of the root store. On a best-efforts basis, Mozilla maintains a list of the additional things users of Mozilla’s root store might need to consider.

Application developers must pay attention to which Root Store to use: We strongly encourage application developers to ensure that the list of root certificates that they are using in their applications have been curated for their use case. Additionally, application developers should only use the Mozilla/NSS root store for TLS or S/MIME by using the links provided on the CCADB Resources page that list the certificates in the Mozilla/NSS root store according to the trust bits (key usage) they are curated for.

Choosing to rely on a root store also means understanding and accepting the policies for that root store. Concretely, that means respecting both the trust flags on root certificates and decisions to add or remove root certificates. In particular, Mozilla removes root certificates when they are determined to be no longer trustworthy for TLS or S/MIME. If a removal causes an application to break, then it is either correct on the basis that the root certificate should no longer be used for TLS or S/MIME, or it is a fault in that application not using the root store correctly. Significant root removals are usually announced in Mozilla’s Security Blog (e.g. DigiNotar, CNNIC, WoSign).

Mozilla is committed to maintaining our own root store because doing so is vital to the security of our products and the web in general. It gives us the ability to set policies, determine which CAs meet them, and to take action when a CA fails to do so.