Publication date (www.mozilla.org): September 12, 2023
Effective (compliance) date: September 1, 2023
For CAs capable of issuing email certificates, for audit periods ending after October 30, 2023, period-of-time audits must be performed in accordance WebTrust/ETSI criteria
For CAs capable of issuing TLS server certificates, compliance self-assessments must be submitted for “BR Audit Period End Dates” after December 31, 2023
Publication date (www.mozilla.org): April 29, 2022
Effective (compliance) date: June 1, 2022, except:
July 1, 2022: CAs SHALL NOT sign SHA-1 hashes over end entity certificates with an EKU extension containing the id-kp-emailProtection key purpose.
July 1, 2022: Name-constrained CA certificates that are technically capable of issuing working server or email certificates that were exempt from disclosure in previous versions of this policy MUST be disclosed in the CCADB.
October 1, 2022:
CA operators with intermediate CA certificates that are capable of issuing TLS certificates chaining up to root certificates in Mozilla's root store SHALL populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs.
CAs MUST be able to revoke a certificate presumed to exist, if revocation of the certificate is required under this policy, even if the final certificate does not actually exist, and MUST provide CRL and OCSP services and responses in accordance with the policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist.
New Section 6.1.1 - When a TLS server certificate is revoked for keyCompromise, privilegeWithdrawn, cessationOfOperation, affiliationChanged, or superseded, the CRLReason MUST be included in the reasonCode extension of the CRL entry corresponding to the end entity TLS certificate. If the certificate is revoked for a different or unspecified reason, then the reasonCode extension MUST NOT be provided in the CRL.
December 31, 2022: CA operators will need to maintain (in their online policy repository) all older (and available) versions of each CP and CPS (or CP/CPS), regardless of changes in ownership or control of the root CA, until the entire root CA certificate hierarchy operated in accordance with such documents is no longer trusted by the Mozilla root store.
July 1, 2023: CAs SHALL NOT sign SHA-1 hashes over certificates with an EKU extension containing the id-kp-ocspSigning key purpose; intermediate certificates that chain up to roots in Mozilla's program; OCSP responses; or CRLs.
Effective (compliance) date: January 1, 2020, except:
April 1, 2020: CPs and CPSes published after this date MUST be structured according to RFC 3647 and MUST:
Include at least every section and subsection defined in RFC 3647; and,
Only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and,
Contain no sections that are blank and have no subsections.
July 1, 2020: End-entity certificates MUST include an Extended Key Usage (EKU) extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.
Effective (compliance) date: August 13, 2018, except:
January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3
Effective (compliance) date: July 1, 2018, except:
January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3
The "Mozilla CCADB Policy" document is now part of the main Policy
Publication date: June 23, 2017
Compliance date: June 23, 2017, except:
Technical constraints for email intermediates, which is (erratum) November 15, 2017 for existing non-qualifying intermediates to cease issuing, and April 15 2018 for them to be revoked or audited
Using the Ten Blessed Methods for domain validation, which is July 21, 2017