Changes

Section 6.3.2 of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] states: "Subscriber Certificates issued on or after 1 September 2020 ... '''MUST SHOULD NOT have a Validity Period greater than 398 397 daysand '''. Subscriber Certificates issued after 1 March 2018, but prior to 1 September 2020, MUST NOT have a Validity Period greater than 825 398 days. Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST NOT have a Validity Period greater than 39 months'''."

[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] requires CAs to conform to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements (BRs)] in the issuance and management of publicly trusted SSL 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 restricts the email addresses that may be used to authenticate the subscriber to information listed in the "registrant", "technical", or "administrative" WHOIS records (BR 3.2.2.4.2) and a selected whitelist of local 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).

This is forbidden by section 6.1.7 of the Baseline Requirements.

CAs must never generate the key pairs for signer or SSL TLS server certificates. CAs may only generate the key pairs for S/MIME certificates. Distribution or transfer of certificates in PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then:

This is forbidden by Section 7.1.4.2.1 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements], which says:* As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA "CAs SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 certificates with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. === Issuing SSL Certificates for .int Domains === It has come to our attention that some Certification Authorities may have mistakenly issued SSL certificates to non-existent .int domain names. This appears to have happened because the .int domain may have been confused with internal domain names, and not all of the CAs and RAs may be aware that .int is an ICANN approved TLD. In any case, CAs should be no longer issuing certificates for Internal Names."

CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 25606960, 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 25606960, 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.

Domain and Email validation are core requirements of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] and should always be incorporated into the issuing CA's procedures. Delegating this function to 3rd third parties is not permitted.

Some CAs root CA operators authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. In considering a root certificate for inclusion in NSS, Mozilla must also will evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. If Mozilla accepts and This evaluation includes a CA's root certificate, then we have to assume that we also accept any review of their future sub-CAs and their sub-CAs. Therefore, the selection criteria for a CA's sub-CAs and their sub-CAs will be a critical decision factorapproval 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ 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 SSL TLS server certificate or email certificate issuance.

More information on our disclosure requirements [https://wiki.mozilla.org/CA:SubordinateCA_checklist#Non-disclosable_Intermediate_Certificates is availablehere].

During the root inclusion/change process, CAs must provide a clear description of the 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 [https://wiki.mozilla.org/CA:SubordinateCA_checklist Subordinate CA Checklist].

After inclusion, CAs must disclose their internally and externally operated subordinate CAs in the [https://wikiwww.mozillaccadb.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F Common CA Databasepolicy 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 [https://www.ccadb.org/cas/intermediates CCADB].

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 very generic, e.g., "Secure Server CA"; this makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.

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

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.