This page is a snapshot of a previous version of Mozilla's CA Certificate Policy. Click here to view Mozilla's Current CA Certificate Policy.
Mozilla CA Certificate Policy (Version 1.1)
When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products the Mozilla Foundation and its wholly-owned subsidiary the Mozilla Corporation include with such software a default set of X.509v3 certificates for various Certification Authorities (CAs). The certificates included by default have their "trust bits" set for various purposes, so that the software in question can use the CA certificates to verify certificates for SSL servers, S/MIME email users, and digitally-signed code objects without having to ask users for further permission or information.
This is the official Mozilla Foundation policy for CA certificates that the Mozilla Foundation and Mozilla Corporation distribute with our software products:
- We will determine which CA certificates are included in software products distributed through mozilla.org, based on the benefits and risks of such inclusion to typical users of those products.
- We will make such decisions through a public process, based on objective and verifiable criteria as described below.
- We will not charge any fees to have a CA's certificate(s) distributed with our software products.
We reserve the right to not include a particular CA certificate
in our software products, to discontinue including a particular CA
certificate in our products, or to modify the "trust
bits" for a particular CA certificate included in our products, at
any time and for any reason.
This includes (but is not limited to) cases where we believe
that including a CA certificate (or setting its "trust bits" in a
particular way) would cause undue risks to users' security, for
example, with CAs that
- knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates; or
- knowingly issue certificates that appear to be intended for fraudulent use.
This also includes (but again is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) might cause technical problems with the operation of our software, for example, with CAs that issue certificates that have
- ASN.1 DER encoding errors;
- invalid public keys (e.g., DSA certificates with 2048-bit primes, or RSA certificates with public exponent equal to 1);
- duplicate issuer names and serial numbers;
- incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer's issuer name and serial number); or
- cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.
- We will consider adding certificates for additional CAs to the default certificate set upon request.
- We require that all CAs whose certificates are distributed with
our software products:
- provide some service relevant to typical users of our software products;
- publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement);
- prior to issuing certificates, verify certificate signing requests in a manner that we deem acceptable for the stated purpose(s) of the certificates;
- otherwise operate in accordance with published criteria that we deem acceptable; and
- provide attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA's internal operations.
- We consider verification of certificate signing requests to be
acceptable if it meets or exceeds the following requirements:
- for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf;
- for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
- for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;
- for certificates to be used for and marked as Extended Validation, the CA complies with <a href="http://www.cabforum.org/EV_Certificate_Guidelines.pdf">Guidelines for the Issuance and Management of Extended Validation Certificates</a> (as modified by the <a href="http://www.cabforum.org/erratum.html">erratum</a> published by the CAB Forum), and has its compliance attested to in accordance with the requirements of Section J of that document.
- We consider the criteria for CA operations published in any of
the following documents to be acceptable:
- Annex B, "(Normative) Certification Authority Control Objectives", of ANSI X9.79-1:2001, <a href="http://www.x9.org/standards/search/details?standard_key=3f63731c02c1074686aa37e0c1b43e72556d008f">Part 1: PKI Practices and Policy Framework</a>;
- Clause 7, "Requirements on CA practice", in ETSI TS 101 456 V1.2.1 (2002-04) or later version, <a href="http://pda.etsi.org/pda/home.asp?wki_id=vRB.0b.A2uoprrwvH-WyI">Policy requirements for certification authorities issuing qualified certificates</a> (as applicable to either the "QCP public" or "QCP public + SSCD" certificate policies);
- Clause 7, "Requirements on CA practice", in ETSI TS 102 042 V1.1.1 (2002-04) or later version, <a href="http://pda.etsi.org/pda/home.asp?wki_id=tmTZH@WhLn_.'0,.QCFnV">Policy requirements for certification authorities issuing public key certificates</a> (as applicable to any of the "NCP", "NCP+", or "LCP" certificate policies);
- "WebTrust Principles and Criteria for Certification Authorities" in <a href="http://ftp.webtrust.org/webtrust_public/tpafile7-8-03fortheweb.doc">AICPA/CICA WebTrust Program for Certification Authorities, Version 1.0</a>; or
- "WebTrust for Certification Authorities—Extended Validation Audit Criteria" in <a href="http://www.cabforum.org/WebTrustAuditGuidelines.pdf">WebTrust for Certification Authorities—Extended Validation Audit Criteria</a> (in conjunction with "WebTrust Principles and Criteria for Certification Authorities").
- By "competent party" we mean a person or other entity who is
authorized to perform audits according to the stated criteria (e.g.,
by the organization responsible for the criteria or by a relevant
government agency) or for whom there is sufficient public
information available to determine that the party is competent to
judge the CA's conformance to the stated criteria. In the latter
case the "public information" referred to should include information
regarding the party's
- knowledge of CA-related technical issues such as public key cryptography and related standards;
- experience in performing security-related audits, evaluations, or risk analyses; and
- honesty and objectivity.
- By "independent party" we mean a person or other entity who is
not affiliated with the CA as an employee or director and
for whom at least one of the following statements is true:
- the party is not financially compensated by the CA;
- the nature and amount of the party's financial compensation by the CA is publicly disclosed; or
- the party is bound by law, government regulation, and/or a professional code of ethics to render an honest and objective judgement regarding the CA.
- We reserve the right to designate our own representative(s) to act as the competent independent party or parties described above, should that prove to be necessary and appropriate.
- The burden is on the CA to prove that it has met the above requirements. However the CA may request a preliminary determination from us regarding the acceptability of the criteria and/or the competent independent party or parties by which it proposes to meet the requirements of this policy.
- In addition to the requirements outlined above, we also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces). We reserve the right to make this a requirement in the future, and to not include a particular CA certificate in our software products, to discontinue including a particular CA certificate, or to modify the "trust bits" for a particular CA certificate, based on the CA's practices in this regard.
- To request that its certificate(s) be added to the default set a
CA should submit a formal request by submitting a <a
report</a> into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the
The request should include the following:
- the certificate data (or links to the data) for the CA certificate(s) requested for inclusion;
- for each CA certificate requested for inclusion, whether or
not the CA issues certificates for each of the following
purposes within the CA hierarchy associated with the CA
- SSL-enabled servers,
- digitally-signed and/or encrypted email, or
- digitally-signed executable code objects;
- for each CA certificate requested for inclusion, whether the CA issues Extended Validation certificates within the CA hierarchy associated with the CA certificate and, if so, the EV policy OID associated with the CA certificate;
- a Certificate Policy and Certification Practice Statement (or links to a CP and CPS) or equivalent disclosure document(s) for the CA or CAs in question; and
- information as to how the CA has fulfilled the requirements stated above regarding its verification of certificate signing requests and its conformance to a set of acceptable operational criteria.
We will reject requests where the CA does not provide such information within a reasonable period of time after submitting itsrequest.
- We will appoint a CA certificate "module owner" to evaluate CA requests on our behalf and make decisions regarding all matters relating to CA certificates included in our products. CAs or others objecting to a particular decision may appeal to mozilla.org staff, who will make a final decision.
- We reserve the right to change this policy in the future. We will do so only after consulting with the public Mozilla community, in order to ensure that all views are taken into account.
This policy applies only to software products distributed by the Mozilla Foundation and the Mozilla Corporation; other entities distributing such software are free to adopt their own policies. In particular, under the terms of the relevant Mozilla license(s) distributors of such software are permitted to add or delete CA certificates in the versions that they distribute, and are also permitted to modify the values of the "trust bits" on CA certificates in the default CA certificate set. As with other software modifications, by making such changes a distributor may affect its ability to use Mozilla trademarks in connection with its versions of the software; see the <a href="http://www.mozilla.org/foundation/trademarks">Mozilla trademark policy</a> for more information.
Please contact the Mozilla Foundation at <a href="mailto:email@example.com">firstname.lastname@example.org</a> for more information about this policy and answers to related questions.