CA/Forbidden or Problematic Practices

This page contains comments about various CA practices that have been the subject of discussion in past CA evaluations. Some of these practices are addressed by the Mozilla Root Store Policy and are forbidden. They are listed here because they are things CAs often get wrong. Others, we do not necessarily consider security risks, but we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Additional practices may be addressed in future versions of the policy.

Forbidden Practices

Long-lived Certificates

Section 6.3.2 of the CA/Browser Forum's Baseline Requirements states: "Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days."

Non-Standard Email Address Prefixes for Domain Ownership Validation

Mozilla's Root Store Policy requires CAs to conform to the CA/Browser Forum Baseline Requirements (BRs) in the issuance and management of publicly trusted TLS server certificates. This includes the BR restrictions on the use of email as a way of validating that the certificate subscriber owns or controls the domain name to be included in the certificate. CAs are expected to conform to BR section 3.2.2.4, which allows email to the "Domain Contact", defined as the "Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar." (BR § 3.2.2.4.2); a selected whitelist of constructed addresses, which are limited to local-parts of "admin", "administrator", "webmaster", "hostmaster", and "postmaster" followed by the "at" sign ("@") and the domain name in question (read BR § 3.2.2.4.4 for specifics); or using email addresses found in DNS (BR § 3.2.2.4.13 and BR § 3.2.2.4.14).

A CA that authorizes certificate subscribers by contacting any other email addresses may be found non-compliant with Mozilla's Root Store Policy and in violation of the Baseline Requirements, and may have action taken against it. CAs are also reminded that Mozilla's Root Store Policy and the Baseline Requirements extend to any CA certificates that are technically capable of issuing TLS server certificates, and subordinate CAs that fail to follow these requirements put the root CA in jeopardy of removal from Mozilla's root store.

Issuing End Entity Certificates Directly From Roots

This is forbidden by section 6.1.7 of the Baseline Requirements.

Distributing Generated Private Keys in PKCS#12 Files

Section 5.2 of Mozilla's Root Store Policy states: "CA operators MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage, unless the certificate is being issued to the CA itself."

In other words, CAs must note generate key pairs for TLS server certificates, except for their own use (e.g. certificates for the test websites required by BR section 2.2). CAs may only generate the key pairs for S/MIME certificates. Distribution or transfer of S/MIME certificates in unprotected PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then:

• The storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal)
• The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the storage.

Certificates Referencing Local Names or Private IP Addresses

A Subject Alternative Name (SAN) with an internal or local name or with a reserved or private IP address is forbidden by section 7.1.4.2.1 of the Baseline Requirements.

OCSP Responses Signed by a Certificate Under a Different Root

CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 6960, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.

RFC 6960, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.

For a detailed explanation about why an OCSP responder should not use a self-signed OCSP responder certificate and depend on Trusted Responder Mode within the Firefox browser, see: Details about OCSP Trusted Responder Mode.

Please test your OCSP responder within the Firefox browser by enforcing OCSP as per our CA Recommended Practices for OCSP.

Issuance of SHA-1 Certificates

Issuance of SHA-1 subordinate CA certificates, end entity certificates, or OCSP responder certificates is forbidden by section 5.1 of Mozilla's Root Store Policy and section 7.1.3.2.1 of the Baseline Requirements. Other uses of SHA-1 are also being phased out. See MRSP § 5.1.3.

Delegation of Domain / Email Validation to Third Parties

Section 1.3.2 of the Baseline Requirements forbids delegating domain validation to third parties.

Section 2.2 of Mozilla's Root Store Policy says: "The CA operator SHALL NOT delegate validation of the domain portion of an email address."

Domain and Email validation are core requirements of Mozilla's Root Store Policy and should always be incorporated into the issuing CA's procedures. Delegating this function to third parties is not permitted.

Potentially Problematic Practices

Allowing External Entities to Operate Subordinate CAs

Some root CA operators authorize external entities to operate their own CAs as subordinate CAs under the root. In considering a root certificate for inclusion in NSS, Mozilla will evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. This evaluation includes a review of the CA's approval criteria, as well as the documentation and auditing-of-operations requirements that the operator of the root CA places on such relationships.

In order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent policy that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of TLS server certificate or email certificate issuance.

Section 8.4 of the Mozilla Root Store Policy requires that externally operated CAs undergo public discussion unless they meet one of the enumerated exceptions (e.g. they are already in the root store with the ability to issue the same type of certificate that they were already approved for). See MRSP § 8.4 and Process for non-Technically-Constrained Subordinate CAs for details.

During the root inclusion/change process, CAs must provide a clear description of any subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with CA/Browser Forum and Mozilla's CA Certificate Policy requirements as per the Subordinate CA Checklist.

CAs must disclose their internally and externally operated subordinate CAs in the CCADB, and maintain annual updates to the corresponding CP/CPS documents and audit statements. If CP/CPS or audit documents for a particular subordinate CA are different than that of the root CA, then such different documents also need to be reflected in the CCADB.

Generic Names for CAs

In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases, CA names are too generic, e.g. "Secure Server CA", which makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.

Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA.

Additionally, the issuer and subject information in the root certificate should provide clear indication about who owns or operates the CA. Generic issuer and subject information inhibits the users' ability to establish a chain of trust, and to pursue complaints when appropriate. For instance, the following issuer information would be totally unacceptable in a root certificate to be included in NSS.

• CN = Root CA
• O = admin

There is no information in this issuer that can be linked back to any particular CA operator. There is no distinguishable company name or brand name. All information in this issuer is too generic to do a search on and hope to find the responsible CA operator. (Moreover, it lacks the two‐letter ISO 3166‐1 country code, which is required by section 7.1.4.3 of the Baseline Requirements.)

Important: Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable for the O not to identify the CA operator and a generic term such as "Admin" will mislead users, who rely on the issuer details, when they hover their mouse over the lock icon in the address bar.

Also, please refer to sections 7.1.4.1 Name Encoding and 7.1.4.3 Subject Information - Root Certificates and Subordinate CA Certificates in the Baseline Requirements.

Lack of Communication With End Users

CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA. See Baseline Requirements, section 4.9.3, "The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports. The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS."

Backdating the notBefore Date

Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline, prohibition, or code-enforced restriction is not.

Issuer Encoding in CRL

The encoding of the Issuer field in the CRL should be byte-for-byte equivalent with the encoding of the Issuer in the certificate; that is, using the exact same string types and field contents. The specs (RFC 2459, RFC 3280, RFC 5280) permit them to mismatch, but that causes compatibility issues with various clients -- in such cases client software might not find the entry for the revoked certificate in the CRL.