https://wiki.mozilla.org/api.php?action=feedcontributions&user=Kathleen+Wilson&feedformat=atomMozillaWiki - User contributions [en]2024-03-28T19:16:58ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Modules/Activities&diff=1250100Modules/Activities2024-02-29T21:23:59Z<p>Kathleen Wilson: Moved myself to Emeritus</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Governance<br />
|description=Policies and process for how we distribute authority and govern ourselves; including:<br />
* Development and Implementation of new policies as appropriate for delegation of authority and responsibility<br />
* Management of the source tree<br />
* Balancing different constituencies of the Mozilla project<br />
* Maintaining the Mozilla identity as we take on new activities<br />
<br />
[http://www.mozilla.org/about/roles.html#ultimate-decision-makers Ultimate authority] within the project rests with the owner and peer(s) of this module, and project decisions can be escalated to here.<br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=<br />
|peersemeritus=Brendan Eich<br />
|group=governance<br />
|url=https://wiki.mozilla.org/GovernanceIssues<br />
|components=mozilla.org::Governance<br />
}}<br />
<br />
===Governance Sub Modules===<br />
<br />
{{Module<br />
|name=Module Ownership System<br />
|description=Healthy operation of the module ownership system, including topics such as:<br />
* Filling vacant roles where appropriate<br />
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not<br />
* Creating and staffing new modules where new parts of the project evolve.<br />
* Figuring out what to do if a module isn't getting enough attention<br />
* Resolving conflicts among module owners <br />
|owner= [mailto:mitchell@mozilla.org Mitchell Baker]<br />
|ownersemeritus=Brendan Eich<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Commit Access Management<br />
|description= Governance structure for the work of implementing, managing and enforcing Mozilla's commit access systems and policies.<br />
|owner=[mailto:glob@mozilla.com glob]<br />
|peers=[mailto:mconnor@mozilla.com Mike Connor], [mailto:mhristova@mozilla.com Mira Hristova], [mailto:jdirks@mozilla.com James Dirks]<br />
|ownersemeritus=Mitchell Baker, Josh Matthews<br />
|peersemeritus=Marcia Knous, Jonathan Lin<br />
|group=<br />
|url=http://www.mozilla.org/hacking/committer/<br />
|components=mozilla.org::Repository Account Requests<br />
}}<br />
<br />
{{Module<br />
|name=Security Policy<br />
|description=Policies for handling security issues in Mozilla code<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:security@mozilla.org Tom Ritter]<br />
|peersemeritus= Al Billings<br />
|group=dev-security<br />
|url=http://www.mozilla.org/security/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Mozilla CA Certificate Policy<br />
|description=Definition and enforcement of policies governing Certification Authorities, their root certificates included in Mozilla software products, and intermediate and end-entity certificates within those CA hierarchies.<br />
|owner= [mailto:bwilson@mozilla.com Ben Wilson]<br />
|peers= <br />
|ownersemeritus=Frank Hecker, Wayne Thayer, Kathleen Wilson<br />
|peersemeritus= Johnathan Nightingale, Sid Stamm, Richard Barnes, Gervase Markham, Wayne Thayer, Kathleen Wilson<br />
|group=dev-security-policy<br />
|url=http://www.mozilla.org/projects/security/certs/policy/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Code Review Policy<br />
|description=<br />
|owner=[mailto:tlmc@mozilla.com Firefox Technical Leadership Module Committee]<br />
|peers=<br />
|peersemeritus=Brendan Eich<br />
|group=<br />
|url=http://www.mozilla.org/hacking/reviewers.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Performance Regression Policy<br />
|description=<br />
|owner=[mailto:tlmc@mozilla.com Firefox Technical Leadership Module Committee]<br />
|peers=<br />
|group=<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Planet Mozilla<br />
|description=Content and policy for planet.mozilla.org, including topics such as:<br />
* which blogs are syndicated to planet.mozilla.org<br />
* which content from syndicated blogs is included<br />
* other planet.mozilla.org policy issues <br />
|owner=<br />
|peers=[mailto:asa@mozilla.org Asa Dotzler]<br />
|group=<br />
|url=<br />
|components=Websites::planet.mozilla.org<br />
|ownersemeritus=Robert Accettura, Mike Hoye<br />
|peersemeritus=Reed Loden<br />
}}<br />
<br />
{{Module<br />
|name=Mozilla Public License<br />
|description=Maintenance and development of the MPL<br />
* changes in the legal landscape which could /should be reflected<br />
* changes in FLOSS development practices which could / should be reflected <br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=[mailto:handerson@mozilla.com Harvey Anderson], [mailto:MeekerH@gtlaw.com Heather Meeker], [mailto:villalu@gtlaw.com Luis Villa]<br />
|peersemeritus=Gervase Markham<br />
|group=governance-mpl-update<br />
|url=<br />
|components=mozilla.org::Licensing<br />
}}<br />
<br />
{{Module<br />
|name=CA Certificates<br />
|description=Determine which root certificates should be included in Mozilla software products, which trust bits should be set on them, and which of them should be enabled for EV treatment. Evaluate requests from Certification Authorities (CAs) for inclusion or removal of root certificates, and for updating trust bit settings or enabling EV treatment for already included root certificates.<br />
|owner=[mailto:bwilson@mozilla.com Ben Wilson]<br />
|peers=<br />
|ownersemeritus=Frank Hecker, Kathleen Wilson<br />
|peersemeritus= Johnathan Nightingale, Sid Stamm, Richard Barnes, Gervase Markham, Wayne Thayer, Ryan Sleevi, Kathleen Wilson<br />
|group=dev-security-policy <br />
|url=http://www.mozilla.org/projects/security/certs/policy/<br />
|components=mozilla.org::CA Certificates<br />
}}<br />
<br />
{{Module<br />
|name=Participation Metrics<br />
|description=Develop, monitor and analyze metrics relating to participation in the Mozilla project, including such things as:<br />
* determining which questions are most important to ask (how many people do X?)<br />
* determining what data is relevant to answer these questions<br />
* designing and operating a system to generate the requested data<br />
* analyzing the resulting metrics<br />
* notifying appropriate people when participation starts to change significantly<br />
* assisting various groups to understand and use the metrics to strengthen participation<br />
* produce periodic report/analysis of participation metrics <br />
|owner=[mailto:ppapadeas@mozilla.com Pierros Papadeas]<br />
|peers=[mailto:dboswell@mozilla.com David Boswell], [mailto:asa@mozilla.com Asa Dotzler], [mailto:deinspanjer@mozilla.com Daniel Einspanjer], [mailto:aelliott@mozilla.com Annie Elliott], [mailto:david@eaves.ca David Eaves], [mailto:michelle@mozillafoundation.org Michelle Thorne], [mailto:ryan@mozillafoundation.org Ryan Merkley]<br />
|group=<br />
|url=https://wiki.mozilla.org/Contribute/Dashboards<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Internet Public Policy<br />
|description=Mozilla activities related to Public Policy issues that affect the health of the Internet. Our working definition of Public Policy is taken from Wikipedia: "courses of action, regulatory measures, laws, and funding priorities concerning a given topic promulgated by a governmental entity or its representatives." <br />
This includes topics such as:<br />
*determining if Mozilla should take an official position on a particular public policy issue<br />
*determining what that position is <br />
*determining how mozilla communicates our position <br />
**global, multi-regional, regional or local action<br />
**direct action, or support of action by other aligned groups<br />
**public campaigns or opinion pieces or educational activities, dialog with policy makers, other techniques TBD<br />
*strengthening local community capabilities to address public policy issues <br />
|owner=[mailto:handerson@mozilla.com Harvey Anderson]<br />
|peers=[mailto:mitchell@mozilla.org Mitchell Baker], [mailto:afowler@mozilla.com Alex Fowler], [mailto:mark@mozillafoundation.org Mark Surman]<br />
|url=https://wiki.mozilla.org/Netpolicy<br />
|group=https://mail.mozilla.org/listinfo/netpolicy<br />
|components=<br />
|notes=Area Expert Advisors: Katharina Borchert, Andrew Bridges, Hanno Kaiser, Andrew McLaughlin, Danny Weitzner, Gene Kimmelman, and Ronaldo Lemos<br />
}}<br />
Area Expert Advisors are people with particular expertise who have agreed to assist Mozilla with their area-specific expertise. The Area Expert Advisors are different from peers. A peer is someone to whom the module owner has delegated some of her/his authority and a peer is expected to provide leadership for Mozilla within our specific context. Area Expert Advisors are advisors to Mozilla. They may become peers, but they need not. <br />
<br />
(It's a new thing to have a group such as "MoCo Desktop IT services" as a<br />
"peer." We're trying this based on the idea that anyone in the Desktop IT group<br />
should be able to resolve problems and make fixes to the systems.)<br />
<br />
===Other===<br />
<br />
{{Module<br />
|name=Tree Sheriffs<br />
|description=Tree Sheriffs aid developers to easily, quickly, and seamlessly land their code in the proper location(s) and ensure that code does not break our automated tests. In the service of this objective, the Sheriffs work closely with the larger engineering organization to create and enforce landing policies that increase productivity while maintaining an efficient and robust automated testing system. Beyond the policy role, they have also become shepherds of automation quality by monitoring intermittent failures, performing uplifts and merges, and identifying poorly performing automation machines. <br />
|owner=[mailto:rvandermeulen@mozilla.com Ryan VanderMeulen] (:RyanVM)<br />
|peers=[mailto:shengst@mozilla.com Sebastian Hengst] (:Aryx)<br />
|ownersemeritus=Ed Morley<br />
|peersemeritus=Carsten Book, Wes Kocher<br />
|group=https://mail.mozilla.org/listinfo/sheriffs<br />
|url=https://wiki.mozilla.org/Sheriffing<br />
}}</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/CCADB_Dashboard&diff=1249310CA/CCADB Dashboard2024-01-03T18:30:07Z<p>Kathleen Wilson: The previous bugzilla query stopped working for Enhancement Requests</p>
<hr />
<div>= Dashboard for Common CA Database Updates =<br />
<br />
== CCADB API Access==<br />
Requests for API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert<br />
<br />
To file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB API Access Request], use:<br />
<br /><br />
Product: CA Program <br />
<br /><br />
Component: Common CA Database <br />
<br /><br />
Whiteboard: [ccadb-api] <br />
<br /><br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"status_whiteboard":"ccadb-api",<br />
"include_fields": "whiteboard, id, summary, last_change_time",<br />
"order": "id"<br />
}<br />
</bugzilla><br />
<br />
== Bugs ==<br />
Bugs that unintentionally remove pre-existing functionality or negatively impact CCADB users should have priority over Enhancements, and should be set to P1. Low impact bugs will start at P4 and be considered with ERs. If it's a low LOE bug (less than 4 hours of work) it can go from P4 to P1 without prioritization/design.<br />
<br />
To file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB Bug], use:<br />
<br /><br />
Product: CA Program <br />
<br /><br />
Component: Common CA Database <br />
<br /><br />
Whiteboard: [ccadb-bug] <br />
<br /><br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"whiteboard":"ccadb-bug",<br />
"include_fields": "priority, id, summary, last_change_time",<br />
"order": "priority ASC"<br />
}<br />
</bugzilla><br />
<br />
== Enhancement Requests ==<br />
The Priority values are used as follows:<br />
* P1 - Development in progress<br />
* P2 - Design in progress or complete<br />
* P3 - Prioritized, design document started<br />
* P4 or not set - To be prioritized and scheduled later<br />
<br />
'''Important''': Do not enter a value into the Whiteboard field to file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB Enhancement Request].<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"include_fields": "priority, id, summary,whiteboard, last_change_time",<br />
"order": "priority ASC"<br />
}<br />
</bugzilla><br />
<br />
== Closed ==<br />
A historical view of past CCADB updates (from May 2021 onward) may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_CCADB_Updates</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA&diff=1249074CA2023-11-27T21:41:59Z<p>Kathleen Wilson: removing reference to TLS Observatory tool, because the information it provides can be wrong</p>
<hr />
<div>__NOTOC__<br />
= Mozilla's CA Certificate Program =<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root [https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates certificates] in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS Network Security Services (NSS),] a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of products. The program is overseen by the module owner and peers of the [[Modules/Activities#CA_Certificates|CA Certificates Module]]; the policy itself is overseen by the module owner and peers of the [[Modules/Activities#Mozilla_CA_Certificate_Policy|CA Certificate Policy Module]].<br />
<br />
== Policy ==<br />
<br />
* [https://www.mozilla.org/projects/security/certs/policy/ Root Store Policy] (current stable version: 2.9)<br />
* [[CA/Communications | CA Communications]] and their responses. Such communications may also set policy in advance of it being included in the Root Store Policy.<br />
* [[CA/Root_Store_Policy_Archive|Root Store Policy Archive]]<br />
* [[CA/Updating_Root_Store_Policy|Process for updating the Root Store Policy]]<br />
** [https://github.com/mozilla/pkipolicy/issues Root Store Policy Issue Tracker]<br />
** [https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Latest draft of Root Store Policy] (will become the next version)<br />
* [[CA/Transition_SMIME_BRs|Transition to S/MIME BRs]]<br />
<br />
== Lists of CAs and Certificates ==<br />
* [https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms Data Usage Terms]<br />
* [[CA/Included_CAs|Included CAs]] (in the Root Program and in Firefox)<br />
* [[CA/Included_Certificates|Included CA Certificates]]<br />
* [[CA/Intermediate_Certificates|Intermediate Certificates]]<br />
* [[CA/Removed_Certificates|Removed CA Certificates]]<br />
* [[NSS:Release_Versions|NSS Release Versions]] - shows in which version of Mozilla products each root certificate was first available<br />
* [[CA/Additional_Trust_Changes| Additional Trust Policies ]] - describes trust policies enforced by PSM in Firefox and Thunderbird, but not represented in the NSS root store.<br />
<br />
== Program Administration ==<br />
<br />
Most information relating to the administration of our program is stored either in [https://bugzilla.mozilla.org/ Bugzilla] or in the [https://ccadb.org/ Common CA Database].<br />
<br />
* [[CA/Dashboard|Certificate Change Request Dashboard]] - tracks applications and trust changes through the process in Bugzilla<br />
** [[CA/Prioritization|Certificate Change Prioritization]] <br />
* [[CA/Certificate_Change_Requests|Certificate Change Requests]] as tracked in the CCADB<br />
* [[CA/Incident_Dashboard|Incident and Compliance Dashboard]]<br />
* [[CA/CCADB_Dashboard|CCADB Dashboard]]<br />
* [[CA/Bug_Triage|Bugzilla Bug Triage Process]]<br />
* [[CA/Email_templates|Email Templates used by CCADB]]<br />
<br />
====crt.sh====<br />
<br />
* [https://crt.sh/mozilla-disclosures Disclosure status of all certificates known to CT]<br />
* [https://crt.sh/?cablint=issues Problematic certificates issued in the past week known to CT]<br />
<br />
== Information for CAs ==<br />
* [https://ccadb.org/cas/ CCADB Login]<br />
* [[CA/Audit_Statements|Audit_Statements]]<br />
* [[CA/Responding_To_An_Incident|Responding to an Incident]] (such as a misissuance)<br />
* [[CA/Vulnerability_Disclosure|Disclosing a Vulnerability or Security Incident]]<br />
* [[CA/Application_Process|Application Process for Mozilla's Root Program]]<br />
** [[CA/Quantifying_Value|Quantifying Value: Information Expected of New Applicants]]<br />
** [[CA/Compliance_Self-Assessment|Compliance Self Assessment]]<br />
*** [[CA/CPS_Review|Previous reviews of CP/CPS documents]]<br />
** [[CA/Information_Checklist|CA Information Checklist]]<br />
** [[CA/Subordinate_CA_Checklist|Subordinate CA Information Checklist]]<br />
* [[CA/External_Sub_CAs|Approval Process for Externally Operated Subordinate CAs]] <br />
* [[CA/Certificate_Change_Process|Change or Remove an Included Root Certificate]]<br />
* [[CA/Root_CA_Lifecycles|Root CA Lifecycles]]<br />
* [[CA/Required_or_Recommended_Practices|Required or Recommended CA Practices]]<br />
* [[CA/Root_Inclusion_Considerations|Root Inclusion Considerations]] -- This page is intended to be used as a tool for identifying when a CA Operator's root inclusion request should be denied, or when a CA's root certificate should be removed from Mozilla's root store. <br />
** [[CA/Forbidden_or_Problematic_Practices|Forbidden or Problematic CA Practices]]<br />
** [[CA/Maintenance_and_Enforcement|Maintenance and Enforcement]]<br />
* [[SecurityEngineering/Certificate_Verification|How Firefox Performs Certificate Verification]] and path construction <br />
* [[CA/EV_Processing_for_CAs | How Firefox Processes EV Certificates]]<br />
* Revocation<br />
** [[CA/Revocation_Checking_in_Firefox|How Firefox Performs Revocation Checking]]<br />
** [[CA/Revocation_Reasons|Revocation Reasons for TLS Server Certificates]]<br />
* [[PSM:EV_Testing_Easy_Version|EV Readiness Test]]<br />
<br />
* [https://github.com/digicert/pkilint PKI Lint Tool for TLS & S/MIME] - source code download<br />
* [https://github.com/certlint/certlint BR Lint Certificate Test] - source code download<br />
* [https://github.com/zmap/zlint ZLint - Certificate Test of Mozilla's and others' requirements] - source code download<br />
* [https://github.com/kroeckx/x509lint X.509 Lint Certificate Test] - source code download<br />
* [[CA:TestErrors|Common Test Errors]]<br />
<br />
== Information for Auditors ==<br />
* [[CA/Audit_Statements#Auditor_Qualifications|Auditor Qualifications]]<br />
* [[CA/Auditor_Compliance|Auditor Compliance Dashboard]]<br />
* [[CA/BR_Audit_Guidance|Guidance on doing Baseline Requirements audits]]<br />
* [[CA/Auditor_Mistakes|Mistakes we have seen auditors make]] and their consequences<br />
<br />
== Information for the Public ==<br />
* [https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ Why Does Mozilla Maintain Our Own Root Certificate Store?]<br />
* [https://blog.mozilla.org/security/2019/04/15/common-ca-database-ccadb/ What is the Common CA Database (CCADB)?]<br />
* [[CA/FAQ|FAQ About Certificates and CAs]]<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/ProblemReportingMechanismsReport List of CA problem reporting mechanisms (email, etc.)] (use this to report a certificate problem directly to the CA)<br />
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance Report an Incident to Mozilla] (be sure to click the "Security" checkbox if it is a [https://www.mozilla.org/en-US/security/#For_Developers security-sensitive incident])<br />
* [[CA/Terminology|Glossary of CA and Certificate Terminology]]<br />
* [[CA/Changing_Trust_Settings|Changing Certificate Trust Settings in Firefox]]<br />
** [[CA/Changing_Trust_Settings#Trusting_an_Additional_Root_Certificate|Manually import a root certificate into Firefox]]<br />
* [https://certviewer-dot-ccadb-231121.appspot.com/certviewer Certificate Viewer] -- can also be installed/run locally (see [https://github.com/mozilla/CCADB-Tools/tree/master/certViewer ReadMe])<br />
* [https://www.ssllabs.com/ssltest/analyze.html Qualys SSL Server Quality Checker]<br />
* [https://observatory.mozilla.org/ Mozilla SSL Server Quality Checker]<br />
* [[CA/Revocation_Checking_in_Firefox|How Firefox performs revocation checking]]<br />
* [https://certificate.revocationcheck.com/ Certificate Revocation Checker] (also checks CRL and OCSP server quality and compliance)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/CAAIdentifiersReport List of CAA Identifiers] (used to restrict issuance of certificates to specific CAs via a [https://tools.ietf.org/html/rfc6844 DNS Certification Authority Authorization Resource Record])<br />
* [[CA/AddRootToFirefox|How to install your own root certificate in Firefox]]<br />
<br />
== Discussion Forums ==<br />
<br />
The following public forums are relevant to CA evaluation and related issues. <br />
<br />
===== CCADB =====<br />
* '''[https://groups.google.com/a/ccadb.org/g/public CCADB Public mailing list''' is used to conduct a six-week public discussion of CA root inclusion requests and to discuss important lessons learned from CA incident reports. See https://www.ccadb.org/cas/public-group for more information.<br />
<br />
===== MDSP =====<br />
* '''[https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla's dev-security-policy (MDSP)] mailing list''' is used for discussions of Mozilla policies related to security in general and CAs in particular, and for wider discussions about the WebPKI. If you are a regular participant in MDSP, then please add your name to the [[CA/Policy_Participants|Policy Participants]] page.<br />
<br />
===== Other MDSP Mail Archives =====<br />
* '''New MDSP Messages''' (since August 2021)<br />
<br />
(HTML): https://www.mail-archive.com/dev-security-policy@mozilla.org/<br />
<br />
(RSS): https://www.mail-archive.com/dev-security-policy@mozilla.org/maillist.xml<br />
<br />
* '''Old MDSP Messages''' (until April 2021)<br />
<br />
(HTML): https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/<br />
<br />
(RSS): https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/maillist.xml<br />
<br />
===== Other Forums =====<br />
* [https://groups.google.com/a/mozilla.org/g/dev-tech-crypto Mozilla's dev-tech-crypto] mailing list is used for discussions of the [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] cryptographic library used in Firefox and other Mozilla-based products, as well as the [https://www.mozilla.org/projects/security/pki/psm/ PSM] module that implements higher-level security protocols for Firefox.<br />
* For other discussions of Mozilla security issues:<br />
** [https://discourse.mozilla.org/c/security/ Mozilla's Security Web forum] is a place to discuss information security work in the open source space, where Mozilla is empowering users to build and curate a Healthy Internet.<br />
** [https://discourse.mozilla.org/tags/c/firefox-development/privacy-and-security Mozilla's privacy-and-security forum] is a place to discuss issues and questions specific to privacy and security.<br />
** [https://chat.mozilla.org/#/room/#security:mozilla.org chat on Matrix] may also be used</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA&diff=1249073CA2023-11-27T21:40:25Z<p>Kathleen Wilson: added clarification</p>
<hr />
<div>__NOTOC__<br />
= Mozilla's CA Certificate Program =<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root [https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates certificates] in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS Network Security Services (NSS),] a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of products. The program is overseen by the module owner and peers of the [[Modules/Activities#CA_Certificates|CA Certificates Module]]; the policy itself is overseen by the module owner and peers of the [[Modules/Activities#Mozilla_CA_Certificate_Policy|CA Certificate Policy Module]].<br />
<br />
== Policy ==<br />
<br />
* [https://www.mozilla.org/projects/security/certs/policy/ Root Store Policy] (current stable version: 2.9)<br />
* [[CA/Communications | CA Communications]] and their responses. Such communications may also set policy in advance of it being included in the Root Store Policy.<br />
* [[CA/Root_Store_Policy_Archive|Root Store Policy Archive]]<br />
* [[CA/Updating_Root_Store_Policy|Process for updating the Root Store Policy]]<br />
** [https://github.com/mozilla/pkipolicy/issues Root Store Policy Issue Tracker]<br />
** [https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Latest draft of Root Store Policy] (will become the next version)<br />
* [[CA/Transition_SMIME_BRs|Transition to S/MIME BRs]]<br />
<br />
== Lists of CAs and Certificates ==<br />
* [https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms Data Usage Terms]<br />
* [[CA/Included_CAs|Included CAs]] (in the Root Program and in Firefox)<br />
* [[CA/Included_Certificates|Included CA Certificates]]<br />
* [[CA/Intermediate_Certificates|Intermediate Certificates]]<br />
* [[CA/Removed_Certificates|Removed CA Certificates]]<br />
* [[NSS:Release_Versions|NSS Release Versions]] - shows in which version of Mozilla products each root certificate was first available<br />
* [[CA/Additional_Trust_Changes| Additional Trust Policies ]] - describes trust policies enforced by PSM in Firefox and Thunderbird, but not represented in the NSS root store.<br />
<br />
== Program Administration ==<br />
<br />
Most information relating to the administration of our program is stored either in [https://bugzilla.mozilla.org/ Bugzilla] or in the [https://ccadb.org/ Common CA Database].<br />
<br />
* [[CA/Dashboard|Certificate Change Request Dashboard]] - tracks applications and trust changes through the process in Bugzilla<br />
** [[CA/Prioritization|Certificate Change Prioritization]] <br />
* [[CA/Certificate_Change_Requests|Certificate Change Requests]] as tracked in the CCADB<br />
* [[CA/Incident_Dashboard|Incident and Compliance Dashboard]]<br />
* [[CA/CCADB_Dashboard|CCADB Dashboard]]<br />
* [[CA/Bug_Triage|Bugzilla Bug Triage Process]]<br />
* [[CA/Email_templates|Email Templates used by CCADB]]<br />
<br />
====crt.sh====<br />
<br />
* [https://crt.sh/mozilla-disclosures Disclosure status of all certificates known to CT]<br />
* [https://crt.sh/?cablint=issues Problematic certificates issued in the past week known to CT]<br />
<br />
== Information for CAs ==<br />
* [https://ccadb.org/cas/ CCADB Login]<br />
* [[CA/Audit_Statements|Audit_Statements]]<br />
* [[CA/Responding_To_An_Incident|Responding to an Incident]] (such as a misissuance)<br />
* [[CA/Vulnerability_Disclosure|Disclosing a Vulnerability or Security Incident]]<br />
* [[CA/Application_Process|Application Process for Mozilla's Root Program]]<br />
** [[CA/Quantifying_Value|Quantifying Value: Information Expected of New Applicants]]<br />
** [[CA/Compliance_Self-Assessment|Compliance Self Assessment]]<br />
*** [[CA/CPS_Review|Previous reviews of CP/CPS documents]]<br />
** [[CA/Information_Checklist|CA Information Checklist]]<br />
** [[CA/Subordinate_CA_Checklist|Subordinate CA Information Checklist]]<br />
* [[CA/External_Sub_CAs|Approval Process for Externally Operated Subordinate CAs]] <br />
* [[CA/Certificate_Change_Process|Change or Remove an Included Root Certificate]]<br />
* [[CA/Root_CA_Lifecycles|Root CA Lifecycles]]<br />
* [[CA/Required_or_Recommended_Practices|Required or Recommended CA Practices]]<br />
* [[CA/Root_Inclusion_Considerations|Root Inclusion Considerations]] -- This page is intended to be used as a tool for identifying when a CA Operator's root inclusion request should be denied, or when a CA's root certificate should be removed from Mozilla's root store. <br />
** [[CA/Forbidden_or_Problematic_Practices|Forbidden or Problematic CA Practices]]<br />
** [[CA/Maintenance_and_Enforcement|Maintenance and Enforcement]]<br />
* [[SecurityEngineering/Certificate_Verification|How Firefox Performs Certificate Verification]] and path construction <br />
* [[CA/EV_Processing_for_CAs | How Firefox Processes EV Certificates]]<br />
* Revocation<br />
** [[CA/Revocation_Checking_in_Firefox|How Firefox Performs Revocation Checking]]<br />
** [[CA/Revocation_Reasons|Revocation Reasons for TLS Server Certificates]]<br />
* [[PSM:EV_Testing_Easy_Version|EV Readiness Test]]<br />
<br />
* [https://github.com/digicert/pkilint PKI Lint Tool for TLS & S/MIME] - source code download<br />
* [https://github.com/certlint/certlint BR Lint Certificate Test] - source code download<br />
* [https://github.com/zmap/zlint ZLint - Certificate Test of Mozilla's and others' requirements] - source code download<br />
* [https://github.com/kroeckx/x509lint X.509 Lint Certificate Test] - source code download<br />
* [[CA:TestErrors|Common Test Errors]]<br />
<br />
== Information for Auditors ==<br />
* [[CA/Audit_Statements#Auditor_Qualifications|Auditor Qualifications]]<br />
* [[CA/Auditor_Compliance|Auditor Compliance Dashboard]]<br />
* [[CA/BR_Audit_Guidance|Guidance on doing Baseline Requirements audits]]<br />
* [[CA/Auditor_Mistakes|Mistakes we have seen auditors make]] and their consequences<br />
<br />
== Information for the Public ==<br />
* [https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ Why Does Mozilla Maintain Our Own Root Certificate Store?]<br />
* [https://blog.mozilla.org/security/2019/04/15/common-ca-database-ccadb/ What is the Common CA Database (CCADB)?]<br />
* [[CA/FAQ|FAQ About Certificates and CAs]]<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/ProblemReportingMechanismsReport List of CA problem reporting mechanisms (email, etc.)] (use this to report a certificate problem directly to the CA)<br />
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance Report an Incident to Mozilla] (be sure to click the "Security" checkbox if it is a [https://www.mozilla.org/en-US/security/#For_Developers security-sensitive incident])<br />
* [[CA/Terminology|Glossary of CA and Certificate Terminology]]<br />
* [[CA/Changing_Trust_Settings|Changing Certificate Trust Settings in Firefox]]<br />
** [[CA/Changing_Trust_Settings#Trusting_an_Additional_Root_Certificate|Manually import a root certificate into Firefox]]<br />
* [https://certviewer-dot-ccadb-231121.appspot.com/certviewer Certificate Viewer] -- current tool -- can also be installed/run locally (see [https://github.com/mozilla/CCADB-Tools/tree/master/certViewer ReadMe])<br />
** [https://tls-observatory.services.mozilla.com/static/certsplainer.html TLS Observatory Certificate Explainer (no longer maintained, some of its information is outdated)]<br />
* [https://www.ssllabs.com/ssltest/analyze.html Qualys SSL Server Quality Checker]<br />
* [https://observatory.mozilla.org/ Mozilla SSL Server Quality Checker]<br />
* [[CA/Revocation_Checking_in_Firefox|How Firefox performs revocation checking]]<br />
* [https://certificate.revocationcheck.com/ Certificate Revocation Checker] (also checks CRL and OCSP server quality and compliance)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/CAAIdentifiersReport List of CAA Identifiers] (used to restrict issuance of certificates to specific CAs via a [https://tools.ietf.org/html/rfc6844 DNS Certification Authority Authorization Resource Record])<br />
* [[CA/AddRootToFirefox|How to install your own root certificate in Firefox]]<br />
<br />
== Discussion Forums ==<br />
<br />
The following public forums are relevant to CA evaluation and related issues. <br />
<br />
===== CCADB =====<br />
* '''[https://groups.google.com/a/ccadb.org/g/public CCADB Public mailing list''' is used to conduct a six-week public discussion of CA root inclusion requests and to discuss important lessons learned from CA incident reports. See https://www.ccadb.org/cas/public-group for more information.<br />
<br />
===== MDSP =====<br />
* '''[https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla's dev-security-policy (MDSP)] mailing list''' is used for discussions of Mozilla policies related to security in general and CAs in particular, and for wider discussions about the WebPKI. If you are a regular participant in MDSP, then please add your name to the [[CA/Policy_Participants|Policy Participants]] page.<br />
<br />
===== Other MDSP Mail Archives =====<br />
* '''New MDSP Messages''' (since August 2021)<br />
<br />
(HTML): https://www.mail-archive.com/dev-security-policy@mozilla.org/<br />
<br />
(RSS): https://www.mail-archive.com/dev-security-policy@mozilla.org/maillist.xml<br />
<br />
* '''Old MDSP Messages''' (until April 2021)<br />
<br />
(HTML): https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/<br />
<br />
(RSS): https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/maillist.xml<br />
<br />
===== Other Forums =====<br />
* [https://groups.google.com/a/mozilla.org/g/dev-tech-crypto Mozilla's dev-tech-crypto] mailing list is used for discussions of the [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] cryptographic library used in Firefox and other Mozilla-based products, as well as the [https://www.mozilla.org/projects/security/pki/psm/ PSM] module that implements higher-level security protocols for Firefox.<br />
* For other discussions of Mozilla security issues:<br />
** [https://discourse.mozilla.org/c/security/ Mozilla's Security Web forum] is a place to discuss information security work in the open source space, where Mozilla is empowering users to build and curate a Healthy Internet.<br />
** [https://discourse.mozilla.org/tags/c/firefox-development/privacy-and-security Mozilla's privacy-and-security forum] is a place to discuss issues and questions specific to privacy and security.<br />
** [https://chat.mozilla.org/#/room/#security:mozilla.org chat on Matrix] may also be used</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA&diff=1249072CA2023-11-27T21:39:20Z<p>Kathleen Wilson: Replacing Certificate Explainer with Certificate Viewer</p>
<hr />
<div>__NOTOC__<br />
= Mozilla's CA Certificate Program =<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root [https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates certificates] in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS Network Security Services (NSS),] a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of products. The program is overseen by the module owner and peers of the [[Modules/Activities#CA_Certificates|CA Certificates Module]]; the policy itself is overseen by the module owner and peers of the [[Modules/Activities#Mozilla_CA_Certificate_Policy|CA Certificate Policy Module]].<br />
<br />
== Policy ==<br />
<br />
* [https://www.mozilla.org/projects/security/certs/policy/ Root Store Policy] (current stable version: 2.9)<br />
* [[CA/Communications | CA Communications]] and their responses. Such communications may also set policy in advance of it being included in the Root Store Policy.<br />
* [[CA/Root_Store_Policy_Archive|Root Store Policy Archive]]<br />
* [[CA/Updating_Root_Store_Policy|Process for updating the Root Store Policy]]<br />
** [https://github.com/mozilla/pkipolicy/issues Root Store Policy Issue Tracker]<br />
** [https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Latest draft of Root Store Policy] (will become the next version)<br />
* [[CA/Transition_SMIME_BRs|Transition to S/MIME BRs]]<br />
<br />
== Lists of CAs and Certificates ==<br />
* [https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms Data Usage Terms]<br />
* [[CA/Included_CAs|Included CAs]] (in the Root Program and in Firefox)<br />
* [[CA/Included_Certificates|Included CA Certificates]]<br />
* [[CA/Intermediate_Certificates|Intermediate Certificates]]<br />
* [[CA/Removed_Certificates|Removed CA Certificates]]<br />
* [[NSS:Release_Versions|NSS Release Versions]] - shows in which version of Mozilla products each root certificate was first available<br />
* [[CA/Additional_Trust_Changes| Additional Trust Policies ]] - describes trust policies enforced by PSM in Firefox and Thunderbird, but not represented in the NSS root store.<br />
<br />
== Program Administration ==<br />
<br />
Most information relating to the administration of our program is stored either in [https://bugzilla.mozilla.org/ Bugzilla] or in the [https://ccadb.org/ Common CA Database].<br />
<br />
* [[CA/Dashboard|Certificate Change Request Dashboard]] - tracks applications and trust changes through the process in Bugzilla<br />
** [[CA/Prioritization|Certificate Change Prioritization]] <br />
* [[CA/Certificate_Change_Requests|Certificate Change Requests]] as tracked in the CCADB<br />
* [[CA/Incident_Dashboard|Incident and Compliance Dashboard]]<br />
* [[CA/CCADB_Dashboard|CCADB Dashboard]]<br />
* [[CA/Bug_Triage|Bugzilla Bug Triage Process]]<br />
* [[CA/Email_templates|Email Templates used by CCADB]]<br />
<br />
====crt.sh====<br />
<br />
* [https://crt.sh/mozilla-disclosures Disclosure status of all certificates known to CT]<br />
* [https://crt.sh/?cablint=issues Problematic certificates issued in the past week known to CT]<br />
<br />
== Information for CAs ==<br />
* [https://ccadb.org/cas/ CCADB Login]<br />
* [[CA/Audit_Statements|Audit_Statements]]<br />
* [[CA/Responding_To_An_Incident|Responding to an Incident]] (such as a misissuance)<br />
* [[CA/Vulnerability_Disclosure|Disclosing a Vulnerability or Security Incident]]<br />
* [[CA/Application_Process|Application Process for Mozilla's Root Program]]<br />
** [[CA/Quantifying_Value|Quantifying Value: Information Expected of New Applicants]]<br />
** [[CA/Compliance_Self-Assessment|Compliance Self Assessment]]<br />
*** [[CA/CPS_Review|Previous reviews of CP/CPS documents]]<br />
** [[CA/Information_Checklist|CA Information Checklist]]<br />
** [[CA/Subordinate_CA_Checklist|Subordinate CA Information Checklist]]<br />
* [[CA/External_Sub_CAs|Approval Process for Externally Operated Subordinate CAs]] <br />
* [[CA/Certificate_Change_Process|Change or Remove an Included Root Certificate]]<br />
* [[CA/Root_CA_Lifecycles|Root CA Lifecycles]]<br />
* [[CA/Required_or_Recommended_Practices|Required or Recommended CA Practices]]<br />
* [[CA/Root_Inclusion_Considerations|Root Inclusion Considerations]] -- This page is intended to be used as a tool for identifying when a CA Operator's root inclusion request should be denied, or when a CA's root certificate should be removed from Mozilla's root store. <br />
** [[CA/Forbidden_or_Problematic_Practices|Forbidden or Problematic CA Practices]]<br />
** [[CA/Maintenance_and_Enforcement|Maintenance and Enforcement]]<br />
* [[SecurityEngineering/Certificate_Verification|How Firefox Performs Certificate Verification]] and path construction <br />
* [[CA/EV_Processing_for_CAs | How Firefox Processes EV Certificates]]<br />
* Revocation<br />
** [[CA/Revocation_Checking_in_Firefox|How Firefox Performs Revocation Checking]]<br />
** [[CA/Revocation_Reasons|Revocation Reasons for TLS Server Certificates]]<br />
* [[PSM:EV_Testing_Easy_Version|EV Readiness Test]]<br />
<br />
* [https://github.com/digicert/pkilint PKI Lint Tool for TLS & S/MIME] - source code download<br />
* [https://github.com/certlint/certlint BR Lint Certificate Test] - source code download<br />
* [https://github.com/zmap/zlint ZLint - Certificate Test of Mozilla's and others' requirements] - source code download<br />
* [https://github.com/kroeckx/x509lint X.509 Lint Certificate Test] - source code download<br />
* [[CA:TestErrors|Common Test Errors]]<br />
<br />
== Information for Auditors ==<br />
* [[CA/Audit_Statements#Auditor_Qualifications|Auditor Qualifications]]<br />
* [[CA/Auditor_Compliance|Auditor Compliance Dashboard]]<br />
* [[CA/BR_Audit_Guidance|Guidance on doing Baseline Requirements audits]]<br />
* [[CA/Auditor_Mistakes|Mistakes we have seen auditors make]] and their consequences<br />
<br />
== Information for the Public ==<br />
* [https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ Why Does Mozilla Maintain Our Own Root Certificate Store?]<br />
* [https://blog.mozilla.org/security/2019/04/15/common-ca-database-ccadb/ What is the Common CA Database (CCADB)?]<br />
* [[CA/FAQ|FAQ About Certificates and CAs]]<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/ProblemReportingMechanismsReport List of CA problem reporting mechanisms (email, etc.)] (use this to report a certificate problem directly to the CA)<br />
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance Report an Incident to Mozilla] (be sure to click the "Security" checkbox if it is a [https://www.mozilla.org/en-US/security/#For_Developers security-sensitive incident])<br />
* [[CA/Terminology|Glossary of CA and Certificate Terminology]]<br />
* [[CA/Changing_Trust_Settings|Changing Certificate Trust Settings in Firefox]]<br />
** [[CA/Changing_Trust_Settings#Trusting_an_Additional_Root_Certificate|Manually import a root certificate into Firefox]]<br />
* [https://certviewer-dot-ccadb-231121.appspot.com/certviewer Certificate Viewer] -- current tool -- can also be installed/run locally (see [https://github.com/mozilla/CCADB-Tools/tree/master/certViewer ReadMe])<br />
** [https://tls-observatory.services.mozilla.com/static/certsplainer.html TLS Observatory Certificate Explainer (no longer maintained)]<br />
* [https://www.ssllabs.com/ssltest/analyze.html Qualys SSL Server Quality Checker]<br />
* [https://observatory.mozilla.org/ Mozilla SSL Server Quality Checker]<br />
* [[CA/Revocation_Checking_in_Firefox|How Firefox performs revocation checking]]<br />
* [https://certificate.revocationcheck.com/ Certificate Revocation Checker] (also checks CRL and OCSP server quality and compliance)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/CAAIdentifiersReport List of CAA Identifiers] (used to restrict issuance of certificates to specific CAs via a [https://tools.ietf.org/html/rfc6844 DNS Certification Authority Authorization Resource Record])<br />
* [[CA/AddRootToFirefox|How to install your own root certificate in Firefox]]<br />
<br />
== Discussion Forums ==<br />
<br />
The following public forums are relevant to CA evaluation and related issues. <br />
<br />
===== CCADB =====<br />
* '''[https://groups.google.com/a/ccadb.org/g/public CCADB Public mailing list''' is used to conduct a six-week public discussion of CA root inclusion requests and to discuss important lessons learned from CA incident reports. See https://www.ccadb.org/cas/public-group for more information.<br />
<br />
===== MDSP =====<br />
* '''[https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla's dev-security-policy (MDSP)] mailing list''' is used for discussions of Mozilla policies related to security in general and CAs in particular, and for wider discussions about the WebPKI. If you are a regular participant in MDSP, then please add your name to the [[CA/Policy_Participants|Policy Participants]] page.<br />
<br />
===== Other MDSP Mail Archives =====<br />
* '''New MDSP Messages''' (since August 2021)<br />
<br />
(HTML): https://www.mail-archive.com/dev-security-policy@mozilla.org/<br />
<br />
(RSS): https://www.mail-archive.com/dev-security-policy@mozilla.org/maillist.xml<br />
<br />
* '''Old MDSP Messages''' (until April 2021)<br />
<br />
(HTML): https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/<br />
<br />
(RSS): https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/maillist.xml<br />
<br />
===== Other Forums =====<br />
* [https://groups.google.com/a/mozilla.org/g/dev-tech-crypto Mozilla's dev-tech-crypto] mailing list is used for discussions of the [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] cryptographic library used in Firefox and other Mozilla-based products, as well as the [https://www.mozilla.org/projects/security/pki/psm/ PSM] module that implements higher-level security protocols for Firefox.<br />
* For other discussions of Mozilla security issues:<br />
** [https://discourse.mozilla.org/c/security/ Mozilla's Security Web forum] is a place to discuss information security work in the open source space, where Mozilla is empowering users to build and curate a Healthy Internet.<br />
** [https://discourse.mozilla.org/tags/c/firefox-development/privacy-and-security Mozilla's privacy-and-security forum] is a place to discuss issues and questions specific to privacy and security.<br />
** [https://chat.mozilla.org/#/room/#security:mozilla.org chat on Matrix] may also be used</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=PSM:EV_Testing_Easy_Version&diff=1248901PSM:EV Testing Easy Version2023-11-09T16:53:43Z<p>Kathleen Wilson: added note that the tool can be run locally for debugging</p>
<hr />
<div>This page is for [[CA:FAQ#What_are_CAs.3F | Certificate Authorities (CAs)]] who request to have a root certificate enabled for [https://cabforum.org/extended-validation Extended Validation (EV) treatment], and need to test that their CA hierarchy is ready for EV treatment.<br />
<br />
Before requesting EV treatment, CAs should understand how [[CA/EV_Processing_for_CAs | Firefox processes EV certificates]] and ensure that they are using the CA/Browser Forum EV OID (2.23.140.1.1), which Mozilla requires.<br />
<br />
To request that your root certificate be included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] and [https://hg.mozilla.org/mozilla-central/file/tip/security/certverifier/ExtendedValidation.cpp enabled for EV treatment], see [[CA/Application_Process|Mozilla's application process]].<br />
<br />
This page explains how you can test that your certificates and OCSP infrastructure are working correctly according to the expectations of Mozilla, Firefox, and the NSS library; and conforms to the SSL protocol specifications (as interpreted by Mozilla/NSS software.)<br />
<br />
= EV-Readiness Check =<br />
To test your CA hierarchy to see if it is ready to request EV treatment:<br />
# Browse to <br />
#* [https://github.com/mozilla/CCADB-Tools/tree/master/evReadiness NEW]: https://evready-dot-ccadb-231121.appspot.com/evready <br />
#* [https://github.com/mozilla/tls-observatory OLD]: https://tls-observatory.services.mozilla.com/static/ev-checker.html<br />
# Enter the URL to the test website for the EV certificate<br />
#* Example: https://observatory.mozilla.org<br />
# Enter the EV Policy OID<br />
#* Example: 2.23.140.1.1<br />
# Enter the PEM data for the root certificate, or use the "Browse..." button to select the PEM file for the root certificate (ending of file may be .pem or .cert)<br />
#* Begin with: -----BEGIN CERTIFICATE-----<br />
#* End with: -----END CERTIFICATE-----<br />
#* [https://crt.sh/?d=853428 Example PEM Data] - open with a plain text editor like TextEdit<br />
#* [http://ccadb.org/cas/fields#pem-data Help with getting PEM]<br />
# Click on "Submit"<br />
<br />
== Success == <br />
A successful result says: "Status: Success!"<br />
Any other text indicates a failure.<br />
<br />
== Test Failure? ==<br />
<br />
The purpose of this test is to make sure you have set up EV according to the [https://www.cabforum.org/documents.html EV Guidelines], so make sure you have not taken short-cuts like issuing the test cert directly from the root. <br />
* If you get ''Error: Could not initiate scan'', then wait for 3 minutes before trying again. <br />
* If you get ''SEC_ERROR_BAD_DATA'', then the program does not like the format of the data you entered. For instance, if you have extra spaces or characters before or after the TLS Server URL, EV Policy OID, or in the Root Certificate PEM.<br />
* The EV test only uses the root certificate it is given. So, if you are using an intermediate certificate that has been cross-signed with another root certificate, you may see different results when browsing to the site in Firefox, as opposed to the results provided by the EV Test. <br />
* OCSP must work without error for the intermediate certificates.<br />
* The EV Policy OID in the end-entity and intermediate certificates must match the EV Policy OID.<br />
** SEC_ERROR_POLICY_VALIDATION_FAILED error may mean that the intermediate certificate being sent by the server doesn't have a certificate policies extension<br />
** SEC_ERROR_EXTENSION_NOT_FOUND may mean that the certificate being sent by the server doesn't contain the specified policy OID.<br />
* If the test website cannot be reached by the server hosting the tool, check to see if you have a firewall preventing access. <br />
* Still failing? Try testing with https://certificate.revocationcheck.com/ because frequently resolving the errors listed on that page will resolve problems with EV testing.<br />
<br />
== About the Testing Tool ==<br />
The code for the Testing Tool is here: https://github.com/mozilla/CCADB-Tools/tree/master/evReady<br />
<br />
The Testing Tool...<br />
* Can be run on your local computer for debugging, see https://github.com/mozilla/CCADB-Tools/blob/master/evReady/README.md<br />
* Runs a program on a remote computer rather than the user's browser, so it should work with any browser/version. <br />
* Does not interact with the user's profile, so the user does not need to import the root certificate in order to run the tool. The web server must serve up the intermediate cert(s) along with the end-entity cert.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=PSM:EV_Testing_Easy_Version&diff=1248900PSM:EV Testing Easy Version2023-11-09T16:51:30Z<p>Kathleen Wilson: renamed evReadiness folder in GitHub to evReady</p>
<hr />
<div>This page is for [[CA:FAQ#What_are_CAs.3F | Certificate Authorities (CAs)]] who request to have a root certificate enabled for [https://cabforum.org/extended-validation Extended Validation (EV) treatment], and need to test that their CA hierarchy is ready for EV treatment.<br />
<br />
Before requesting EV treatment, CAs should understand how [[CA/EV_Processing_for_CAs | Firefox processes EV certificates]] and ensure that they are using the CA/Browser Forum EV OID (2.23.140.1.1), which Mozilla requires.<br />
<br />
To request that your root certificate be included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] and [https://hg.mozilla.org/mozilla-central/file/tip/security/certverifier/ExtendedValidation.cpp enabled for EV treatment], see [[CA/Application_Process|Mozilla's application process]].<br />
<br />
This page explains how you can test that your certificates and OCSP infrastructure are working correctly according to the expectations of Mozilla, Firefox, and the NSS library; and conforms to the SSL protocol specifications (as interpreted by Mozilla/NSS software.)<br />
<br />
= EV-Readiness Check =<br />
To test your CA hierarchy to see if it is ready to request EV treatment:<br />
# Browse to <br />
#* [https://github.com/mozilla/CCADB-Tools/tree/master/evReadiness NEW]: https://evready-dot-ccadb-231121.appspot.com/evready <br />
#* [https://github.com/mozilla/tls-observatory OLD]: https://tls-observatory.services.mozilla.com/static/ev-checker.html<br />
# Enter the URL to the test website for the EV certificate<br />
#* Example: https://observatory.mozilla.org<br />
# Enter the EV Policy OID<br />
#* Example: 2.23.140.1.1<br />
# Enter the PEM data for the root certificate, or use the "Browse..." button to select the PEM file for the root certificate (ending of file may be .pem or .cert)<br />
#* Begin with: -----BEGIN CERTIFICATE-----<br />
#* End with: -----END CERTIFICATE-----<br />
#* [https://crt.sh/?d=853428 Example PEM Data] - open with a plain text editor like TextEdit<br />
#* [http://ccadb.org/cas/fields#pem-data Help with getting PEM]<br />
# Click on "Submit"<br />
<br />
== Success == <br />
A successful result says: "Status: Success!"<br />
Any other text indicates a failure.<br />
<br />
== Test Failure? ==<br />
<br />
The purpose of this test is to make sure you have set up EV according to the [https://www.cabforum.org/documents.html EV Guidelines], so make sure you have not taken short-cuts like issuing the test cert directly from the root. <br />
* If you get ''Error: Could not initiate scan'', then wait for 3 minutes before trying again. <br />
* If you get ''SEC_ERROR_BAD_DATA'', then the program does not like the format of the data you entered. For instance, if you have extra spaces or characters before or after the TLS Server URL, EV Policy OID, or in the Root Certificate PEM.<br />
* The EV test only uses the root certificate it is given. So, if you are using an intermediate certificate that has been cross-signed with another root certificate, you may see different results when browsing to the site in Firefox, as opposed to the results provided by the EV Test. <br />
* OCSP must work without error for the intermediate certificates.<br />
* The EV Policy OID in the end-entity and intermediate certificates must match the EV Policy OID.<br />
** SEC_ERROR_POLICY_VALIDATION_FAILED error may mean that the intermediate certificate being sent by the server doesn't have a certificate policies extension<br />
** SEC_ERROR_EXTENSION_NOT_FOUND may mean that the certificate being sent by the server doesn't contain the specified policy OID.<br />
* If the test website cannot be reached by the server hosting the tool, check to see if you have a firewall preventing access. <br />
* Still failing? Try testing with https://certificate.revocationcheck.com/ because frequently resolving the errors listed on that page will resolve problems with EV testing.<br />
<br />
== About the Testing Tool ==<br />
The code for the Testing Tool is here: https://github.com/mozilla/CCADB-Tools/tree/master/evReady<br />
<br />
The Testing Tool...<br />
* Runs a program on a remote computer rather than the user's browser, so it should work with any browser/version. <br />
<br />
* Does not interact with the user's profile, so the user does not need to import the root certificate in order to run the tool. The web server must serve up the intermediate cert(s) along with the end-entity cert.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1248777CA/Incident Dashboard2023-10-30T22:29:12Z<p>Kathleen Wilson: added creation-time column</p>
<hr />
<div>= Open CA Bugs in Bugzilla =<br />
<br />
== Open CA Compliance Bugs ==<br />
A CA compliance bug relates to a concern about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and is determined to not be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern]. A CA's response to CA compliance bug includes providing an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] in the bug.<br />
<br />
Anyone may create a CA Compliance bug as follows:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other<br />
* Whiteboard = [ca-compliance] <br />
** If the issue is due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][covid-19] <br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "delayed-revocation",<br />
"o4": "nowordssubstr",<br />
"v4": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts ASC"<br />
}<br />
</bugzilla><br />
<br />
== Audit Delays ==<br />
The compliance bug's whiteboard field is tagged with [audit-delay] whenever a CA is unable to deliver audit statements to Mozilla [[CA/Audit_Statements|when they are due]]. Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], with the following whiteboard tags as described [https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay here].<br />
*Whiteboard = [ca-compliance][audit-delay]<br />
*For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts DESC"<br />
}<br />
</bugzilla><br />
<br />
== Revocation Delays ==<br />
The compliance bug's whiteboard field is tagged with [delayed-revocation-ca] or [delayed-revocation-leaf] whenever a CA fails to abide by Mozilla's requirement to revoke certificates in a timely fashion. As discussed in [[CA/Responding_To_An_Incident#Revocation]], Mozilla recognizes that there may be *exceptional* situations that cause a CA to not abide by the Baseline Requirements, which should be accompanied by an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]].<br />
<br />
Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], and will be categorized appropriately during triage.<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "delayed-revocation",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts ASC"<br />
}<br />
</bugzilla><br />
<br />
<br />
= Closed CA Bugs =<br />
== Closed CA Compliance Bugs ==<br />
A historical view of past CA compliance bugs may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_Incidents</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Closed_Incidents&diff=1248776CA/Closed Incidents2023-10-30T22:27:51Z<p>Kathleen Wilson: added creation-time column</p>
<hr />
<div>= Closed CA Compliance Bugs =<br />
A historical view of past overdue audit statements may be found [https://ccadb-public.secure.force.com/mozilla/OverDueActivityHistoryReport here].<br />
<br /><br />
Below is a historical view of past CA compliance bugs. These bugs may have been valid and remedied by the CA, or may have been deemed invalid and closed as unnecessary.<br />
<br />
== All Other Issues ==<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["CLOSED", "RESOLVED", "VERIFIED"],<br />
"resolution":["DUPLICATE", "FIXED", "INVALID", "WONTFIX", "WORKSFORME"],<br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "delayed-revocation",<br />
"include_fields": "summary, id, status, resolution, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts DESC"<br />
}<br />
</bugzilla><br />
<br />
== Delayed Revocation ==<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["CLOSED", "RESOLVED", "VERIFIED"], <br />
"resolution":["DUPLICATE", "FIXED", "INVALID", "WONTFIX", "WORKSFORME"],<br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "delayed-revocation",<br />
"include_fields": "summary, id, status, resolution, assigned_to, whiteboard, last_change_time",<br />
"order": "short_desc ASC, delta_ts DESC"<br />
}<br />
</bugzilla></div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Information_Checklist&diff=1248624CA/Information Checklist2023-10-17T22:35:57Z<p>Kathleen Wilson: Updating to remove duplication with the ccadb.org website and instructions documents</p>
<hr />
<div>= Information checklist for CAs applying for inclusion in Mozilla =<br />
<br />
In order to support cryptographic applications, such as those that make TLS connections to web and other servers, and those that sign and encrypt/decrypt email, Firefox and other Mozilla-based products contain digital certificates and related metadata for multiple Certification Authorities (CAs). By including the CA certificates and various associated pre-set metadata values Mozilla-based products can recognize as valid the end entity certificates that are issued under such CAs and are associated with, e.g., web servers, and email senders.<br />
<br />
== Example and Template ==<br />
The example and template below list the information that must be provided by the CA in their root inclusion or update request as per step 1 of [[CA/Application_Process#Process_Overview|Mozilla's Application Process]]. <br />
<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341 Example] -- This is what it will look like when you '''[[CA/Information_Checklist#Adding_Root_Certificates_and_Creating_Root_Inclusion_Cases|create a Root Inclusion Case directly]]''' in the CCADB.<br />
<br />
Mozilla's process is public-facing, so all information that will be taken under consideration during the root inclusion request must be publicly available and provided by the CA via a Case in the CCADB and in a Bugzilla bug report. (Both must be created as they will reference each other.)<br />
<br />
== Adding Root Certificates and Creating Root Inclusion Cases ==<br />
=== Access the CCADB ===<br />
If your CA does not yet have access to the CCADB, then you may request access here: <br />
* https://ccadb.org/cas/request-access<br />
<br />
Information and instructions for CAs about the CCADB are here:<br />
* https://www.ccadb.org/cas/<br />
<br />
=== Create an "Add/Update Root Request" case ===<br />
CAs provide information about their CA organization and root certificates by creating an "Add/Update Root Request".<br />
# Create an [https://www.ccadb.org/cas/updates "Add/Update Root Request"] case in the CCADB<br />
#* Detailed Instructions: [https://docs.google.com/document/d/1AUbwbyqCq3jR7wP0fSWjL1us9s4sZIbXGRyo_ko77QM/edit Create an Add/Update Root Request]<br />
# Add new root certificates to the case.<br />
#* In the ROOT INFORMATION tab, click on the "Add/Select Root Certificates" button. Then click on the "Add Root Certificate to CCADB" button and paste the certificate PEM into the window and click on "Validate PEM". If validation is successful, click on the "Create Root Certificate in CCADB" button.<br />
# Completely fill in the information in the five tabs of the "Add/Update Root Request" case: CA OWNER, AUDITS, POLICY DOCUMENTS, ROOT INFORMATION, and TEST WEBSITES.<br />
# Click on the "Submit to Root Store" button.<br />
<br />
'''Important''':<br />
* Audit statements must meet the requirements listed in [https://www.ccadb.org/policy#51-audit-statement-content section 5.1 of the CCADB Policy] '''and''' [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation in section 3 of the Mozilla Root Store Policy].<br />
** Also see Mozilla's [[CA/Audit_Statements#Audit_Lifecycle|audit lifecycle requirements]]<br />
* CCADB automatically converts WebTrust Seal URLs into PDF URLs when you click on ‘Save’<br />
* In each audit statement section in the AUDITS tab, be sure to select "Applicable Root Certificates". <br />
** Click on the inverted triangle ("Edit") to select all of the root certificates covered by the audit.<br />
* If you are requesting that the Websites (TLS) trust bit be enabled for your root certificate(s), then be sure to provide the 3 test websites (valid, expired, revoked) in the TEST WEBSITES tab.<br />
** Click on the "Validate Test Websites" button, resolve all failures, then click on the "Re-run Validation" button to make sure all the websites have Status of PASS.<br />
* Add records to the CCADB for all existing intermediate certificates chaining up to the new root certificate(s).<br />
** https://www.ccadb.org/cas/intermediates<br />
<br />
=== Create a "Root Inclusion Request" Case ===<br />
After you have provided information to the CCADB about your CA organization and root certificates, you may use a "Root Inclusion Request" case to request that your root certificate(s) be included in Mozilla's root store, update trust bit settings, and/or enable EV treatment.<br />
# Create a [https://www.ccadb.org/cas/inclusion "Root Inclusion Request" Case] in the CCADB <br />
#* Detailed Instructions: [https://docs.google.com/document/d/1FHSbpNJ3CQOcpVqrj66elKQhTmpllp-IBsDovPy6cOo/edit# Create a Root Inclusion Request]<br />
# Fill in all of the fields in the MOZILLA tab<br />
# Click on the "Submit to Root Store" button.<br />
<br />
'''Important''':<br />
* In the MOZILLA tab, click on the "Print View" button to see the data that will be shared publicly about your request.<br />
* Click on the "Get URLs" button (which may be in the button overflow – upside down triangle) and copy the line that begins with “Mozilla Root Inclusion Case Information:” into a Comment in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|your Bugzilla Bug]]. The line to copy and paste into the Bugzilla Bug looks like: <br />
**Mozilla Root Inclusion Case Information: https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341<br />
* Whenever you update data in your Root Inclusion Case in the CCADB, be sure to [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|add a comment to your Bugzilla Bug]] to let folks know to re-check the information.'''<br />
<br />
== CA Primary Point of Contact (POC) ==<br />
Each CA organization in the CCADB must provide the contact information for at least one person filling the role of Primary Point of Contact (POC), as described in [https://www.ccadb.org/policy#2-contact-information section 2 of the CCADB Policy].<br />
<br />
=== Provide or update POC information ===<br />
* Create an [https://www.ccadb.org/cas/contacts "Add/Update Contacts"] case.<br />
** Detailed Instructions: [https://docs.google.com/document/d/1QQ-wZYPJ_3p76Zc3RZPE929pKIResc5J4vjSGGi_NuE/edit?usp=sharing Add/Update Contacts]<br />
* Provide the updates in the CONTACTS tab.<br />
* Click on the "Submit to Root Store" button.<br />
<br />
=== Responsibilities of a Primary POC ===<br />
* Provide [http://ccadb.org/cas/updates annual updates] of CP/CPS documents, audit statements, and test websites.<br />
* Respond to [https://wiki.mozilla.org/CA/Communications CA Communications]<br />
* Input and maintain the CA’s data in the [https://www.ccadb.org/cas/ CCADB].<br />
* [mailto:certificates@mozilla.org Inform Mozilla] when there is a change in the organization, ownership, CA policies, or in the POCs that Mozilla should be aware of, as per <br />
** [http://ccadb.org/policy#2-contact-information Section 2 of the CCADB Policy], and<br />
** [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#8-ca-operational-changes Section 8 of the Mozilla Root Store Policy].<br />
* Make sure the "CA Email Alias" field on the CA Owner page is correct.<br />
** An email alias is being requested so that more than one person in your organization will receive notifications in case the primary contact is out of the office or leaves the organization.<br />
** The CA Email Alias is updated via an "Add/Update Root Request" case.<br />
<br />
=== Authority ===<br />
If the CA uses a contractor as a POC, then someone at the CA must also be a POC for the CA Owner record in the CCADB, and the POC from the CA must be CC’d on the root inclusion Bugzilla bug.<br />
* An individual within the CA must also get a Bugzilla account and comment in the bug to say that they will be a POC for the CA, and that the contractor has indeed been hired by the CA to act as one of the POCs.<br />
<br />
To ensure that the POC(s) has the authority to perform the tasks listed above, a representative of Mozilla may do the following.<br />
# Use the CA’s website to contact a person at the CA to confirm that the Primary POCs that have been provided do indeed have the authority to perform the responsibilities listed above on behalf of the CA.<br />
# Use the CA’s website, to confirm that the domain in the email address of at least one of the Primary POCs is owned by the CA (e.g. @CAname.com).<br />
# If a contractor is also used as a Primary POC, then contact the Primary POC that was previously verified to confirm that the CA has indeed enlisted the help of the contractor.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Information_Checklist&diff=1248621CA/Information Checklist2023-10-17T22:01:19Z<p>Kathleen Wilson: Updating to remove duplication with the ccadb.org website and instructions documents</p>
<hr />
<div>= Information checklist for CAs applying for inclusion in Mozilla =<br />
<br />
In order to support cryptographic applications, such as those that make TLS connections to web and other servers, and those that sign and encrypt/decrypt email, Firefox and other Mozilla-based products contain digital certificates and related metadata for multiple Certification Authorities (CAs). By including the CA certificates and various associated pre-set metadata values Mozilla-based products can recognize as valid the end entity certificates that are issued under such CAs and are associated with, e.g., web servers, and email senders.<br />
<br />
== Example and Template ==<br />
The example and template below list the information that must be provided by the CA in their root inclusion or update request as per step 1 of [[CA/Application_Process#Process_Overview|Mozilla's Application Process]]. <br />
<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341 Example] -- This is what it will look like when you '''[[CA/Information_Checklist#Adding_Root_Certificates_and_Creating_Root_Inclusion_Cases|create a Root Inclusion Case directly]]''' in the CCADB.<br />
<br />
Mozilla's process is public-facing, so all information that will be taken under consideration during the root inclusion request must be publicly available and provided by the CA via a Case in the CCADB and in a Bugzilla bug report. (Both must be created as they will reference each other.)<br />
<br />
== Adding Root Certificates and Creating Root Inclusion Cases ==<br />
=== Access the CCADB ===<br />
If your CA does not yet have access to the CCADB, then you may request access here: <br />
* https://ccadb.org/cas/request-access<br />
<br />
Information and instructions for CAs about the CCADB are here:<br />
* https://www.ccadb.org/cas/<br />
<br />
=== Create an "Add/Update Root Request" case ===<br />
CAs provide information about their CA organization and root certificates by creating an "Add/Update Root Request".<br />
# Create an [https://www.ccadb.org/cas/updates "Add/Update Root Request"] case in the CCADB<br />
#* Detailed Instructions: [https://docs.google.com/document/d/1AUbwbyqCq3jR7wP0fSWjL1us9s4sZIbXGRyo_ko77QM/edit Create an Add/Update Root Request]<br />
# Add new root certificates to the case.<br />
#* In the ROOT INFORMATION tab, click on the "Add/Select Root Certificates" button. Then click on the "Add Root Certificate to CCADB" button and paste the certificate PEM into the window and click on "Validate PEM". If validation is successful, click on the "Create Root Certificate in CCADB" button.<br />
# Completely fill in the information in the five tabs of the "Add/Update Root Request" case: CA OWNER, AUDITS, POLICY DOCUMENTS, ROOT INFORMATION, and TEST WEBSITES.<br />
# Click on the "Submit to Root Store" button.<br />
<br />
'''Important''':<br />
* Audit statements must meet the requirements listed in [https://www.ccadb.org/policy#51-audit-statement-content section 5.1 of the CCADB Policy] '''and''' [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation in section 3 of the Mozilla Root Store Policy].<br />
** Also see Mozilla's [[CA/Audit_Statements#Audit_Lifecycle|audit lifecycle requirements]]<br />
* CCADB automatically converts WebTrust Seal URLs into PDF URLs when you click on ‘Save’<br />
* In each audit statement section in the AUDITS tab, be sure to select "Applicable Root Certificates". <br />
** Click on the inverted triangle ("Edit") to select all of the root certificates covered by the audit.<br />
* If you are requesting that the Websites (TLS) trust bit be enabled for your root certificate(s), then be sure to provide the 3 test websites (valid, expired, revoked) in the TEST WEBSITES tab.<br />
** Click on the "Validate Test Websites" button, resolve all failures, then click on the "Re-run Validation" button to make sure all the websites have Status of PASS.<br />
* Add records to the CCADB for all existing intermediate certificates chaining up to the new root certificate(s).<br />
** https://www.ccadb.org/cas/intermediates<br />
<br />
=== Create a "Root Inclusion Request" Case ===<br />
After you have provided information to the CCADB about your CA organization and root certificates, you may use a "Root Inclusion Request" case to request that your root certificate(s) be included in Mozilla's root store, update trust bit settings, and/or enable EV treatment.<br />
# Create a [https://www.ccadb.org/cas/inclusion "Root Inclusion Request" Case] in the CCADB <br />
#* Detailed Instructions: [https://docs.google.com/document/d/1FHSbpNJ3CQOcpVqrj66elKQhTmpllp-IBsDovPy6cOo/edit# Create a Root Inclusion Request]<br />
# Fill in all of the fields in the MOZILLA tab<br />
# Click on the "Submit to Root Store" button.<br />
<br />
'''Important''':<br />
* In the MOZILLA tab, click on the "Print View" button to see the data that will be shared publicly about your request.<br />
* Click on the "Get URLs" button (which may be in the button overflow – upside down triangle) and copy the line that begins with “Mozilla Root Inclusion Case Information:” into a Comment in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|your Bugzilla Bug]]. The line to copy and paste into the Bugzilla Bug looks like: <br />
**Mozilla Root Inclusion Case Information: https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341<br />
* Whenever you update data in your Root Inclusion Case in the CCADB, be sure to [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|add a comment to your Bugzilla Bug]] to let folks know to re-check the information.'''<br />
<br />
== CA Primary Point of Contact (POC) ==<br />
In addition to the information listed in the template and example above, CAs must provide the contact information for at least one person filling the role of Primary Point of Contact (POC), and may use a contractor as one of the POCs. The CA must have one or more people within the CA’s organization who jointly have authority to speak on behalf of the CA, and to direct whatever changes the review process or Mozilla’s CA Communications require. At least one of the CA’s POCs should also be in a position to make commitments for the CA and be held accountable by the CA. <br />
<br />
The Primary POCs will:<br />
* Provide [http://ccadb.org/cas/updates annual updates] of CP/CPS documents, audit statements, and test websites.<br />
* Respond to [https://wiki.mozilla.org/CA/Communications CA Communications]<br />
* Input and maintain the CA’s data in the [http://ccadb.org/ Common CA Database (CCADB)]<br />
* [mailto:certificates@mozilla.org Inform Mozilla] when there is a change in the organization, ownership, CA policies, or in the POCs that Mozilla should be aware of, as per <br />
** [http://ccadb.org/policy#2-contact-information Common CCADB Policy]<br />
** [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#8-ca-operational-changes Mozilla's Root Store Pne number to a specific individual within the CA (must be one of the POCs). <br />
* CA Email Alias: An email alias is being requested so that more than one person in your organization will receive notifications in case the primary contact is out of the office or leaves the organiolicy]<br />
* [mailto:certificates@mozilla.org Provide Mozilla] with updated contact information if a new person becomes a POC.<br />
<br />
Required contact information:<br />
* Direct E-mail address, full name (first and last name), and phozation. Mozilla CA Communications will be sent to both the POC direct email address(es) and the email alias.<br />
* CA Phone Number: A main phone number from which Mozilla can reach the organization responsible for root certificates for the CA.<br />
* Title / Department: If Mozilla needed to call your main phone number, what Title/Department should the Mozilla representative ask for?<br />
<br />
If the CA uses a contractor as an additional POC, then someone at the CA must be CC’d on the root inclusion Bugzilla bug, CA Communications, and the CA’s responses to CA Communications.<br />
* An individual within the CA must also get a Bugzilla account and comment in the bug to say that they will be a POC for the CA, and that the contractor has indeed been hired by the CA to act as one of the POCs.<br />
<br />
To ensure that the POC(s) has the authority to perform the tasks listed above, a representative of Mozilla may do the following.<br />
# Use the CA’s website to contact a person at the CA to confirm that at least one of the POCs that have been provided does indeed have the authority to perform the responsibilities listed above on behalf of the CA.<br />
# Use the CA’s website, to confirm that the domain in the email address of at least one of the POCs is owned by the CA (e.g. @CAname.com).<br />
# If a contractor is also used as a POC, then contact the POC that was previously verified to confirm that the CA has indeed enlisted the help of the contractor.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Information_Checklist&diff=1248620CA/Information Checklist2023-10-17T21:50:52Z<p>Kathleen Wilson: Updating to remove duplication with the ccadb.org website and instructions documents</p>
<hr />
<div>= Information checklist for CAs applying for inclusion in Mozilla =<br />
<br />
In order to support cryptographic applications, such as those that make TLS connections to web and other servers, and those that sign and encrypt/decrypt email, Firefox and other Mozilla-based products contain digital certificates and related metadata for multiple Certification Authorities (CAs). By including the CA certificates and various associated pre-set metadata values Mozilla-based products can recognize as valid the end entity certificates that are issued under such CAs and are associated with, e.g., web servers, and email senders.<br />
<br />
== Example and Template ==<br />
The example and template below list the information that must be provided by the CA in their root inclusion or update request as per step 1 of [[CA/Application_Process#Process_Overview|Mozilla's Application Process]]. <br />
<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341 Example] -- This is what it will look like when you '''[[CA/Information_Checklist#Adding_Root_Certificates_and_Creating_Root_Inclusion_Cases|create a Root Inclusion Case directly]]''' in the CCADB.<br />
<br />
Mozilla's process is public-facing, so all information that will be taken under consideration during the root inclusion request must be publicly available and provided by the CA via a Case in the CCADB and in a Bugzilla bug report. (Both must be created as they will reference each other.)<br />
<br />
== Adding Root Certificates and Creating Root Inclusion Cases ==<br />
=== Access the CCADB ===<br />
If your CA does not yet have access to the CCADB, then you may request access here: <br />
* https://ccadb.org/cas/request-access<br />
<br />
Information and instructions for CAs about the CCADB are here:<br />
* https://www.ccadb.org/cas/<br />
<br />
=== Create an "Add/Update Root Request" case ===<br />
CAs provide information about their CA organization and root certificates by creating an "Add/Update Root Request".<br />
# Create an [https://www.ccadb.org/cas/updates "Add/Update Root Request"] case in the CCADB<br />
#* Detailed Instructions: [https://docs.google.com/document/d/1AUbwbyqCq3jR7wP0fSWjL1us9s4sZIbXGRyo_ko77QM/edit Create an Add/Update Root Request]<br />
# Add new root certificates to the case.<br />
#* In the ROOT INFORMATION tab, click on the "Add/Select Root Certificates" button. Then click on the "Add Root Certificate to CCADB" button and paste the certificate PEM into the window and click on "Validate PEM". If validation is successful, click on the "Create Root Certificate in CCADB" button.<br />
# Completely fill in the information in the five tabs of the "Add/Update Root Request" case: CA OWNER, AUDITS, POLICY DOCUMENTS, ROOT INFORMATION, and TEST WEBSITES.<br />
# Click on the "Submit to Root Store" button.<br />
<br />
'''Important''':<br />
* Audit statements must meet the requirements listed in [https://www.ccadb.org/policy#51-audit-statement-content section 5.1 of the CCADB Policy] '''and''' [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation in section 3 of the Mozilla Root Store Policy].<br />
** Also see Mozilla's [[CA/Audit_Statements#Audit_Lifecycle|audit lifecycle requirements]]<br />
* CCADB automatically converts WebTrust Seal URLs into PDF URLs when you click on ‘Save’<br />
* In each audit statement section in the AUDITS tab, be sure to select "Applicable Root Certificates". <br />
** Click on the inverted triangle ("Edit") to select all of the root certificates covered by the audit.<br />
* If you are requesting that the Websites (TLS) trust bit be enabled for your root certificate(s), then be sure to provide the 3 test websites (valid, expired, revoked) in the TEST WEBSITES tab.<br />
** Click on the 'Test Websites Validation' button, resolve all failures, then click on 'Re-run Validation'<br />
* Add records to the CCADB for all existing intermediate certificates chaining up to the new root certificate(s).<br />
** https://www.ccadb.org/cas/intermediates<br />
<br />
=== Create a "Root Inclusion Request" Case ===<br />
After you have provided information to the CCADB about your CA organization and root certificates, you may use a "Root Inclusion Request" case to request that your root certificate(s) be included in Mozilla's root store, update trust bit settings, and/or enable EV treatment.<br />
# Create a [https://www.ccadb.org/cas/inclusion "Root Inclusion Request" Case] in the CCADB <br />
#* Detailed Instructions: [https://docs.google.com/document/d/1FHSbpNJ3CQOcpVqrj66elKQhTmpllp-IBsDovPy6cOo/edit# Create a Root Inclusion Request]<br />
#* Example: https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341<br />
* Fill in all of the fields in the MOZILLA tab<br />
# Click on the "Submit to Root Store" button.<br />
<br />
'''Important''':<br />
* In the MOZILLA tab, click on the "Print View" button to see the data that will be shared publicly about your request.<br />
* Click on the "Get URLs" button (which may be in the button overflow – upside down triangle) and copy the line that begins with “Mozilla Root Inclusion Case Information:” into a Comment in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|your Bugzilla Bug]]. The line to copy and paste into the Bugzilla Bug looks like: <br />
**Mozilla Root Inclusion Case Information: https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341<br />
* Whenever you update data in your Root Inclusion Case in the CCADB, be sure to [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|add a comment to your Bugzilla Bug]] to let folks know to re-check the information.'''<br />
<br />
== CA Primary Point of Contact (POC) ==<br />
In addition to the information listed in the template and example above, CAs must provide the contact information for at least one person filling the role of Primary Point of Contact (POC), and may use a contractor as one of the POCs. The CA must have one or more people within the CA’s organization who jointly have authority to speak on behalf of the CA, and to direct whatever changes the review process or Mozilla’s CA Communications require. At least one of the CA’s POCs should also be in a position to make commitments for the CA and be held accountable by the CA. <br />
<br />
The Primary POCs will:<br />
* Provide [http://ccadb.org/cas/updates annual updates] of CP/CPS documents, audit statements, and test websites.<br />
* Respond to [https://wiki.mozilla.org/CA/Communications CA Communications]<br />
* Input and maintain the CA’s data in the [http://ccadb.org/ Common CA Database (CCADB)]<br />
* [mailto:certificates@mozilla.org Inform Mozilla] when there is a change in the organization, ownership, CA policies, or in the POCs that Mozilla should be aware of, as per <br />
** [http://ccadb.org/policy#2-contact-information Common CCADB Policy]<br />
** [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#8-ca-operational-changes Mozilla's Root Store Pne number to a specific individual within the CA (must be one of the POCs). <br />
* CA Email Alias: An email alias is being requested so that more than one person in your organization will receive notifications in case the primary contact is out of the office or leaves the organiolicy]<br />
* [mailto:certificates@mozilla.org Provide Mozilla] with updated contact information if a new person becomes a POC.<br />
<br />
Required contact information:<br />
* Direct E-mail address, full name (first and last name), and phozation. Mozilla CA Communications will be sent to both the POC direct email address(es) and the email alias.<br />
* CA Phone Number: A main phone number from which Mozilla can reach the organization responsible for root certificates for the CA.<br />
* Title / Department: If Mozilla needed to call your main phone number, what Title/Department should the Mozilla representative ask for?<br />
<br />
If the CA uses a contractor as an additional POC, then someone at the CA must be CC’d on the root inclusion Bugzilla bug, CA Communications, and the CA’s responses to CA Communications.<br />
* An individual within the CA must also get a Bugzilla account and comment in the bug to say that they will be a POC for the CA, and that the contractor has indeed been hired by the CA to act as one of the POCs.<br />
<br />
To ensure that the POC(s) has the authority to perform the tasks listed above, a representative of Mozilla may do the following.<br />
# Use the CA’s website to contact a person at the CA to confirm that at least one of the POCs that have been provided does indeed have the authority to perform the responsibilities listed above on behalf of the CA.<br />
# Use the CA’s website, to confirm that the domain in the email address of at least one of the POCs is owned by the CA (e.g. @CAname.com).<br />
# If a contractor is also used as a POC, then contact the POC that was previously verified to confirm that the CA has indeed enlisted the help of the contractor.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Information_Checklist&diff=1248619CA/Information Checklist2023-10-17T21:31:57Z<p>Kathleen Wilson: Updating to remove duplication with the ccadb.org website and instructions documents</p>
<hr />
<div>= Information checklist for CAs applying for inclusion in Mozilla =<br />
<br />
In order to support cryptographic applications, such as those that make TLS connections to web and other servers, and those that sign and encrypt/decrypt email, Firefox and other Mozilla-based products contain digital certificates and related metadata for multiple Certification Authorities (CAs). By including the CA certificates and various associated pre-set metadata values Mozilla-based products can recognize as valid the end entity certificates that are issued under such CAs and are associated with, e.g., web servers, and email senders.<br />
<br />
== Example and Template ==<br />
The example and template below list the information that must be provided by the CA in their root inclusion or update request as per step 1 of [[CA/Application_Process#Process_Overview|Mozilla's Application Process]]. <br />
<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341 Example] -- This is what it will look like when you '''[[CA/Information_Checklist#Adding_Root_Certificates_and_Creating_Root_Inclusion_Cases|create a Root Inclusion Case directly]]''' in the CCADB.<br />
<br />
Mozilla's process is public-facing, so all information that will be taken under consideration during the root inclusion request must be publicly available and provided by the CA via a Case in the CCADB and in a Bugzilla bug report. (Both must be created as they will reference each other.)<br />
<br />
== Adding Root Certificates and Creating Root Inclusion Cases ==<br />
=== Access the CCADB ===<br />
If your CA does not yet have access to the CCADB, then you may request access here: <br />
* https://ccadb.org/cas/request-access<br />
<br />
Information and instructions for CAs about the CCADB are here:<br />
* https://www.ccadb.org/cas/<br />
<br />
=== Create an "Add/Update Root Request" case ===<br />
CAs provide information about their CA organization and root certificates by creating an "Add/Update Root Request".<br />
# Create an [https://www.ccadb.org/cas/updates "Add/Update Root Request"] case in the CCADB<br />
#* Detailed Instructions: [https://docs.google.com/document/d/1AUbwbyqCq3jR7wP0fSWjL1us9s4sZIbXGRyo_ko77QM/edit Create an Add/Update Root Request]<br />
# Add new root certificates to the case.<br />
#* In the ROOT INFORMATION tab, click on the "Add/Select Root Certificates" button. Then click on the "Add Root Certificate to CCADB" button and paste the certificate PEM into the window and click on "Validate PEM". If validation is successful, click on the "Create Root Certificate in CCADB" button.<br />
# Completely fill in the information in the five tabs of the "Add/Update Root Request" case: CA OWNER, AUDITS, POLICY DOCUMENTS, ROOT INFORMATION, and TEST WEBSITES.<br />
# Click on the "Submit to Root Store" button.<br />
<br />
Note:<br />
* Audit statements must meet the requirements listed in [https://www.ccadb.org/policy#51-audit-statement-content section 5.1 of the CCADB Policy] '''and''' [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation in section 3 of the Mozilla Root Store Policy].<br />
** Also see Mozilla's [[CA/Audit_Statements#Audit_Lifecycle|audit lifecycle requirements]]<br />
* CCADB automatically converts WebTrust Seal URLs into PDF URLs when you click on ‘Save’<br />
* In each audit statement section in the AUDITS tab, be sure to select "Applicable Root Certificates". <br />
** Click on the inverted triangle ("Edit") to select all of the root certificates covered by the audit.<br />
* If you are requesting that the Websites (TLS) trust bit be enabled for your root certificate(s), then be sure to provide the 3 test websites (valid, expired, revoked) in the TEST WEBSITES tab.<br />
** Click on the 'Test Websites Validation' button, resolve all failures, then click on 'Re-run Validation'<br />
<br />
=== Create a "Root Inclusion Request" Case ===<br />
# Create a [https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341 Root Inclusion Case] in the CCADB <br />
#*Click on the 'My CA' tab<br />
#*Click on the 'CASES' tab under the CA Owner’s name, near the top left corner of the page<br />
#* Click on the 'New' button, which is on the right side of the page, below the 'Get URLs' button<br />
#* Select 'Root Inclusion Request', and click on 'Next'<br />
#* Type in information for the 'Subject', e.g. XYZ Root Certificates<br />
#* Click on the 'Save' button.<br />
#** There will be a green bar shown across the top of the page, which says “Case ###### was created. Click on the number in the list below (the same which was provided by green bar) to view the new Case.<br />
# '''Additional instructions for creating a root inclusion case are available [https://www.ccadb.org/cas/inclusion here] and [https://docs.google.com/document/d/1FHSbpNJ3CQOcpVqrj66elKQhTmpllp-IBsDovPy6cOo here].'''<br />
<br />
'''ADDITIONAL INSTRUCTIONS'''<br />
<br />
#* Add records to the CCADB for all existing intermediate certificates chaining up to this root certificate<br />
#* Update the 'Mozilla Fields' section to indicate which Mozilla Trust Bits are being requested (e.g. Email, Websites), and if EV treatment is being requested.<br />
#* Make sure that Mozilla is listed in the 'Root Stores Applying To' field. If it is not, then go back to the Case page, click on the 'Add/Update Root Cases' button, click on the Mozilla checkbox corresponding to the root certificate, then click on the 'Apply Changes' button.<br />
#Fill in the remaining information<br />
#*On the 'Mozilla' page, click on the 'Print View' to see where further information is needed.<br />
#Click on the 'Get URLs' button (which may be in the button overflow – upside down triangle) and copy the line that begins with “Mozilla Root Inclusion Case Information:” into a Comment in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|your Bugzilla Bug]]. The line to copy and paste into the Bugzilla Bug looks like: <br />
#*Mozilla Root Inclusion Case Information: https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341<br />
<br />
IMPORTANT:<br />
* '''Whenever you update data in your Root Inclusion Case in the CCADB, be sure to [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|add a comment to your Bugzilla Bug]] to let folks know to re-check the information.'''<br />
* Fields for which a root store operator has set "Data Verified" cannot be edited until you ask the root store operator to change the corresponding status back to "Not Verified".<br />
<br />
== CA Primary Point of Contact (POC) ==<br />
In addition to the information listed in the template and example above, CAs must provide the contact information for at least one person filling the role of Primary Point of Contact (POC), and may use a contractor as one of the POCs. The CA must have one or more people within the CA’s organization who jointly have authority to speak on behalf of the CA, and to direct whatever changes the review process or Mozilla’s CA Communications require. At least one of the CA’s POCs should also be in a position to make commitments for the CA and be held accountable by the CA. <br />
<br />
The Primary POCs will:<br />
* Provide [http://ccadb.org/cas/updates annual updates] of CP/CPS documents, audit statements, and test websites.<br />
* Respond to [https://wiki.mozilla.org/CA/Communications CA Communications]<br />
* Input and maintain the CA’s data in the [http://ccadb.org/ Common CA Database (CCADB)]<br />
* [mailto:certificates@mozilla.org Inform Mozilla] when there is a change in the organization, ownership, CA policies, or in the POCs that Mozilla should be aware of, as per <br />
** [http://ccadb.org/policy#2-contact-information Common CCADB Policy]<br />
** [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#8-ca-operational-changes Mozilla's Root Store Pne number to a specific individual within the CA (must be one of the POCs). <br />
* CA Email Alias: An email alias is being requested so that more than one person in your organization will receive notifications in case the primary contact is out of the office or leaves the organiolicy]<br />
* [mailto:certificates@mozilla.org Provide Mozilla] with updated contact information if a new person becomes a POC.<br />
<br />
Required contact information:<br />
* Direct E-mail address, full name (first and last name), and phozation. Mozilla CA Communications will be sent to both the POC direct email address(es) and the email alias.<br />
* CA Phone Number: A main phone number from which Mozilla can reach the organization responsible for root certificates for the CA.<br />
* Title / Department: If Mozilla needed to call your main phone number, what Title/Department should the Mozilla representative ask for?<br />
<br />
If the CA uses a contractor as an additional POC, then someone at the CA must be CC’d on the root inclusion Bugzilla bug, CA Communications, and the CA’s responses to CA Communications.<br />
* An individual within the CA must also get a Bugzilla account and comment in the bug to say that they will be a POC for the CA, and that the contractor has indeed been hired by the CA to act as one of the POCs.<br />
<br />
To ensure that the POC(s) has the authority to perform the tasks listed above, a representative of Mozilla may do the following.<br />
# Use the CA’s website to contact a person at the CA to confirm that at least one of the POCs that have been provided does indeed have the authority to perform the responsibilities listed above on behalf of the CA.<br />
# Use the CA’s website, to confirm that the domain in the email address of at least one of the POCs is owned by the CA (e.g. @CAname.com).<br />
# If a contractor is also used as a POC, then contact the POC that was previously verified to confirm that the CA has indeed enlisted the help of the contractor.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=Modules/Activities&diff=1248093Modules/Activities2023-09-20T23:57:26Z<p>Kathleen Wilson: Handing Mozilla CA Certificate Policy module over to Ben</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Governance<br />
|description=Policies and process for how we distribute authority and govern ourselves; including:<br />
* Development and Implementation of new policies as appropriate for delegation of authority and responsibility<br />
* Management of the source tree<br />
* Balancing different constituencies of the Mozilla project<br />
* Maintaining the Mozilla identity as we take on new activities<br />
<br />
[http://www.mozilla.org/about/roles.html#ultimate-decision-makers Ultimate authority] within the project rests with the owner and peer(s) of this module, and project decisions can be escalated to here.<br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=<br />
|peersemeritus=Brendan Eich<br />
|group=governance<br />
|url=https://wiki.mozilla.org/GovernanceIssues<br />
|components=mozilla.org::Governance<br />
}}<br />
<br />
===Governance Sub Modules===<br />
<br />
{{Module<br />
|name=Module Ownership System<br />
|description=Healthy operation of the module ownership system, including topics such as:<br />
* Filling vacant roles where appropriate<br />
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not<br />
* Creating and staffing new modules where new parts of the project evolve.<br />
* Figuring out what to do if a module isn't getting enough attention<br />
* Resolving conflicts among module owners <br />
|owner= [mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:dmose@mozilla.org Dan Mosedale], [mailto:kairo@kairo.at Robert Kaiser], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dbaron@dbaron.org David Baron], [mailto:dascher@mozilla.com David Ascher], [mailto:mitchell@mozilla.org Mitchell Baker], Guillermo Movia (as 'observer'. This is a new role we're trying out as of Jan 2012. The observers are watching and learning how the module operates, since there's no code in this module to serve as a learning /participation tool.)<br />
|ownersemeritus=Brendan Eich<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Commit Access Management<br />
|description= Governance structure for the work of implementing, managing and enforcing Mozilla's commit access systems and policies.<br />
|owner=[mailto:glob@mozilla.com glob]<br />
|peers=[mailto:mconnor@mozilla.com Mike Connor], [mailto:mhristova@mozilla.com Mira Hristova], [mailto:jdirks@mozilla.com James Dirks]<br />
|ownersemeritus=Mitchell Baker, Josh Matthews<br />
|peersemeritus=Marcia Knous, Jonathan Lin<br />
|group=<br />
|url=http://www.mozilla.org/hacking/committer/<br />
|components=mozilla.org::Repository Account Requests<br />
}}<br />
<br />
{{Module<br />
|name=Security Policy<br />
|description=Policies for handling security issues in Mozilla code<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:security@mozilla.org Tom Ritter]<br />
|peersemeritus= Al Billings<br />
|group=dev-security<br />
|url=http://www.mozilla.org/security/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Mozilla CA Certificate Policy<br />
|description=Definition and enforcement of policies governing Certification Authorities, their root certificates included in Mozilla software products, and intermediate and end-entity certificates within those CA hierarchies.<br />
|owner= [mailto:bwilson@mozilla.com Ben Wilson]<br />
|peers= [mailto:kwilson@mozilla.com Kathleen Wilson]<br />
|ownersemeritus=Frank Hecker, Wayne Thayer, Kathleen Wilson<br />
|peersemeritus= Johnathan Nightingale, Sid Stamm, Richard Barnes, Gervase Markham, Wayne Thayer<br />
|group=dev-security-policy<br />
|url=http://www.mozilla.org/projects/security/certs/policy/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Code Review Policy<br />
|description=<br />
|owner=[mailto:tlmc@mozilla.com Firefox Technical Leadership Module Committee]<br />
|peers=<br />
|peersemeritus=Brendan Eich<br />
|group=<br />
|url=http://www.mozilla.org/hacking/reviewers.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Performance Regression Policy<br />
|description=<br />
|owner=[mailto:tlmc@mozilla.com Firefox Technical Leadership Module Committee]<br />
|peers=<br />
|group=<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Planet Mozilla<br />
|description=Content and policy for planet.mozilla.org, including topics such as:<br />
* which blogs are syndicated to planet.mozilla.org<br />
* which content from syndicated blogs is included<br />
* other planet.mozilla.org policy issues <br />
|owner=<br />
|peers=[mailto:asa@mozilla.org Asa Dotzler]<br />
|group=<br />
|url=<br />
|components=Websites::planet.mozilla.org<br />
|ownersemeritus=Robert Accettura, Mike Hoye<br />
|peersemeritus=Reed Loden<br />
}}<br />
<br />
{{Module<br />
|name=Mozilla Public License<br />
|description=Maintenance and development of the MPL<br />
* changes in the legal landscape which could /should be reflected<br />
* changes in FLOSS development practices which could / should be reflected <br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=[mailto:handerson@mozilla.com Harvey Anderson], [mailto:MeekerH@gtlaw.com Heather Meeker], [mailto:villalu@gtlaw.com Luis Villa]<br />
|peersemeritus=Gervase Markham<br />
|group=governance-mpl-update<br />
|url=<br />
|components=mozilla.org::Licensing<br />
}}<br />
<br />
{{Module<br />
|name=CA Certificates<br />
|description=Determine which root certificates should be included in Mozilla software products, which trust bits should be set on them, and which of them should be enabled for EV treatment. Evaluate requests from Certification Authorities (CAs) for inclusion or removal of root certificates, and for updating trust bit settings or enabling EV treatment for already included root certificates.<br />
|owner=[mailto:bwilson@mozilla.com Ben Wilson]<br />
|peers=[mailto:kwilson@mozilla.com Kathleen Wilson]<br />
|ownersemeritus=Frank Hecker, Kathleen Wilson<br />
|peersemeritus= Johnathan Nightingale, Sid Stamm, Richard Barnes, Gervase Markham, Wayne Thayer, Ryan Sleevi<br />
|group=dev-security-policy <br />
|url=http://www.mozilla.org/projects/security/certs/policy/<br />
|components=mozilla.org::CA Certificates<br />
}}<br />
<br />
{{Module<br />
|name=Participation Metrics<br />
|description=Develop, monitor and analyze metrics relating to participation in the Mozilla project, including such things as:<br />
* determining which questions are most important to ask (how many people do X?)<br />
* determining what data is relevant to answer these questions<br />
* designing and operating a system to generate the requested data<br />
* analyzing the resulting metrics<br />
* notifying appropriate people when participation starts to change significantly<br />
* assisting various groups to understand and use the metrics to strengthen participation<br />
* produce periodic report/analysis of participation metrics <br />
|owner=[mailto:ppapadeas@mozilla.com Pierros Papadeas]<br />
|peers=[mailto:dboswell@mozilla.com David Boswell], [mailto:asa@mozilla.com Asa Dotzler], [mailto:deinspanjer@mozilla.com Daniel Einspanjer], [mailto:aelliott@mozilla.com Annie Elliott], [mailto:david@eaves.ca David Eaves], [mailto:michelle@mozillafoundation.org Michelle Thorne], [mailto:ryan@mozillafoundation.org Ryan Merkley]<br />
|group=<br />
|url=https://wiki.mozilla.org/Contribute/Dashboards<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Internet Public Policy<br />
|description=Mozilla activities related to Public Policy issues that affect the health of the Internet. Our working definition of Public Policy is taken from Wikipedia: "courses of action, regulatory measures, laws, and funding priorities concerning a given topic promulgated by a governmental entity or its representatives." <br />
This includes topics such as:<br />
*determining if Mozilla should take an official position on a particular public policy issue<br />
*determining what that position is <br />
*determining how mozilla communicates our position <br />
**global, multi-regional, regional or local action<br />
**direct action, or support of action by other aligned groups<br />
**public campaigns or opinion pieces or educational activities, dialog with policy makers, other techniques TBD<br />
*strengthening local community capabilities to address public policy issues <br />
|owner=[mailto:handerson@mozilla.com Harvey Anderson]<br />
|peers=[mailto:mitchell@mozilla.org Mitchell Baker], [mailto:afowler@mozilla.com Alex Fowler], [mailto:mark@mozillafoundation.org Mark Surman]<br />
|url=https://wiki.mozilla.org/Netpolicy<br />
|group=https://mail.mozilla.org/listinfo/netpolicy<br />
|components=<br />
|notes=Area Expert Advisors: Katharina Borchert, Andrew Bridges, Hanno Kaiser, Andrew McLaughlin, Danny Weitzner, Gene Kimmelman, and Ronaldo Lemos<br />
}}<br />
Area Expert Advisors are people with particular expertise who have agreed to assist Mozilla with their area-specific expertise. The Area Expert Advisors are different from peers. A peer is someone to whom the module owner has delegated some of her/his authority and a peer is expected to provide leadership for Mozilla within our specific context. Area Expert Advisors are advisors to Mozilla. They may become peers, but they need not. <br />
<br />
(It's a new thing to have a group such as "MoCo Desktop IT services" as a<br />
"peer." We're trying this based on the idea that anyone in the Desktop IT group<br />
should be able to resolve problems and make fixes to the systems.)<br />
<br />
===Other===<br />
<br />
{{Module<br />
|name=Tree Sheriffs<br />
|description=Tree Sheriffs aid developers to easily, quickly, and seamlessly land their code in the proper location(s) and ensure that code does not break our automated tests. In the service of this objective, the Sheriffs work closely with the larger engineering organization to create and enforce landing policies that increase productivity while maintaining an efficient and robust automated testing system. Beyond the policy role, they have also become shepherds of automation quality by monitoring intermittent failures, performing uplifts and merges, and identifying poorly performing automation machines. <br />
|owner=[mailto:rvandermeulen@mozilla.com Ryan VanderMeulen] (:RyanVM)<br />
|peers=[mailto:shengst@mozilla.com Sebastian Hengst] (:Aryx)<br />
|ownersemeritus=Ed Morley<br />
|peersemeritus=Carsten Book, Wes Kocher<br />
|group=https://mail.mozilla.org/listinfo/sheriffs<br />
|url=https://wiki.mozilla.org/Sheriffing<br />
}}</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=PSM:EV_Testing_Easy_Version&diff=1247985PSM:EV Testing Easy Version2023-09-14T21:56:39Z<p>Kathleen Wilson: updated to match the new tool</p>
<hr />
<div>This page is for [[CA:FAQ#What_are_CAs.3F | Certificate Authorities (CAs)]] who request to have a root certificate enabled for [https://cabforum.org/extended-validation Extended Validation (EV) treatment], and need to test that their CA hierarchy is ready for EV treatment.<br />
<br />
Before requesting EV treatment, CAs should understand how [[CA/EV_Processing_for_CAs | Firefox processes EV certificates]] and ensure that they are using the CA/Browser Forum EV OID (2.23.140.1.1), which Mozilla requires.<br />
<br />
To request that your root certificate be included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] and [https://hg.mozilla.org/mozilla-central/file/tip/security/certverifier/ExtendedValidation.cpp enabled for EV treatment], see [[CA/Application_Process|Mozilla's application process]].<br />
<br />
This page explains how you can test that your certificates and OCSP infrastructure are working correctly according to the expectations of Mozilla, Firefox, and the NSS library; and conforms to the SSL protocol specifications (as interpreted by Mozilla/NSS software.)<br />
<br />
= EV-Readiness Check =<br />
To test your CA hierarchy to see if it is ready to request EV treatment:<br />
# Browse to <br />
#* [https://github.com/mozilla/CCADB-Tools/tree/master/evReadiness NEW]: https://evready-dot-ccadb-231121.appspot.com/evready <br />
#* [https://github.com/mozilla/tls-observatory OLD]: https://tls-observatory.services.mozilla.com/static/ev-checker.html<br />
# Enter the URL to the test website for the EV certificate<br />
#* Example: https://observatory.mozilla.org<br />
# Enter the EV Policy OID<br />
#* Example: 2.23.140.1.1<br />
# Enter the PEM data for the root certificate, or use the "Browse..." button to select the PEM file for the root certificate (ending of file may be .pem or .cert)<br />
#* Begin with: -----BEGIN CERTIFICATE-----<br />
#* End with: -----END CERTIFICATE-----<br />
#* [https://crt.sh/?d=853428 Example PEM Data] - open with a plain text editor like TextEdit<br />
#* [http://ccadb.org/cas/fields#pem-data Help with getting PEM]<br />
# Click on "Submit"<br />
<br />
== Success == <br />
A successful result says: "Status: Success!"<br />
Any other text indicates a failure.<br />
<br />
== Test Failure? ==<br />
<br />
The purpose of this test is to make sure you have set up EV according to the [https://www.cabforum.org/documents.html EV Guidelines], so make sure you have not taken short-cuts like issuing the test cert directly from the root. <br />
* If you get ''Error: Could not initiate scan'', then wait for 3 minutes before trying again. <br />
* If you get ''SEC_ERROR_BAD_DATA'', then the program does not like the format of the data you entered. For instance, if you have extra spaces or characters before or after the TLS Server URL, EV Policy OID, or in the Root Certificate PEM.<br />
* The EV test only uses the root certificate it is given. So, if you are using an intermediate certificate that has been cross-signed with another root certificate, you may see different results when browsing to the site in Firefox, as opposed to the results provided by the EV Test. <br />
* OCSP must work without error for the intermediate certificates.<br />
* The EV Policy OID in the end-entity and intermediate certificates must match the EV Policy OID.<br />
** SEC_ERROR_POLICY_VALIDATION_FAILED error may mean that the intermediate certificate being sent by the server doesn't have a certificate policies extension<br />
** SEC_ERROR_EXTENSION_NOT_FOUND may mean that the certificate being sent by the server doesn't contain the specified policy OID.<br />
* If the test website cannot be reached by the server hosting the tool, check to see if you have a firewall preventing access. <br />
* Still failing? Try testing with https://certificate.revocationcheck.com/ because frequently resolving the errors listed on that page will resolve problems with EV testing.<br />
<br />
== About the Testing Tool ==<br />
The code for the Testing Tool is here: https://github.com/mozilla/CCADB-Tools/tree/master/evReadiness<br />
<br />
The Testing Tool...<br />
* Runs a program on a remote computer rather than the user's browser, so it should work with any browser/version. <br />
<br />
* Does not interact with the user's profile, so the user does not need to import the root certificate in order to run the tool. The web server must serve up the intermediate cert(s) along with the end-entity cert.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=PSM:EV_Testing_Easy_Version&diff=1247984PSM:EV Testing Easy Version2023-09-14T21:55:09Z<p>Kathleen Wilson: Deleted obsolete section about running the test locally</p>
<hr />
<div>This page is for [[CA:FAQ#What_are_CAs.3F | Certificate Authorities (CAs)]] who request to have a root certificate enabled for [https://cabforum.org/extended-validation Extended Validation (EV) treatment], and need to test that their CA hierarchy is ready for EV treatment.<br />
<br />
Before requesting EV treatment, CAs should understand how [[CA/EV_Processing_for_CAs | Firefox processes EV certificates]] and ensure that they are using the CA/Browser Forum EV OID (2.23.140.1.1), which Mozilla requires.<br />
<br />
To request that your root certificate be included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] and [https://hg.mozilla.org/mozilla-central/file/tip/security/certverifier/ExtendedValidation.cpp enabled for EV treatment], see [[CA/Application_Process|Mozilla's application process]].<br />
<br />
This page explains how you can test that your certificates and OCSP infrastructure are working correctly according to the expectations of Mozilla, Firefox, and the NSS library; and conforms to the SSL protocol specifications (as interpreted by Mozilla/NSS software.)<br />
<br />
= EV-Readiness Check =<br />
To test your CA hierarchy to see if it is ready to request EV treatment:<br />
# Browse to <br />
#* [https://github.com/mozilla/CCADB-Tools/tree/master/evReadiness NEW]: https://evready-dot-ccadb-231121.appspot.com/evready <br />
#* [https://github.com/mozilla/tls-observatory OLD]: https://tls-observatory.services.mozilla.com/static/ev-checker.html<br />
# Enter the URL to the test website for the EV certificate<br />
#* Example: https://observatory.mozilla.org<br />
# Enter the EV Policy OID<br />
#* Example: 2.23.140.1.1<br />
# Enter the PEM data for the root certificate, or use the "Browse..." button to select the PEM file for the root certificate (ending of file may be .pem or .cert)<br />
#* Begin with: -----BEGIN CERTIFICATE-----<br />
#* End with: -----END CERTIFICATE-----<br />
#* [https://crt.sh/?d=853428 Example PEM Data] - open with a plain text editor like TextEdit<br />
#* [http://ccadb.org/cas/fields#pem-data Help with getting PEM]<br />
# Click on "Submit"<br />
<br />
== Success == <br />
A successful result says: "Status: Success!"<br />
Any other text indicates a failure.<br />
<br />
== Test Failure? ==<br />
<br />
The purpose of this test is to make sure you have set up EV according to the [https://www.cabforum.org/documents.html EV Guidelines], so make sure you have not taken short-cuts like issuing the test cert directly from the root. <br />
* If you get ''Error: Could not initiate scan'', then wait for 3 minutes before trying again. <br />
* If you get ''SEC_ERROR_BAD_DATA'', then the program does not like the format of the data you entered. For instance, if you have extra spaces or characters before or after the TLS Server URL, EV Policy OID, or in the Root Certificate PEM.<br />
* The EV test only uses the root certificate it is given. So, if you are using an intermediate certificate that has been cross-signed with another root certificate, you may see different results when browsing to the site in Firefox, as opposed to the results provided by the EV Test. <br />
* OCSP must work without error for the intermediate certificates.<br />
* The EV Policy OID in the end-entity and intermediate certificates must match the EV Policy OID.<br />
** SEC_ERROR_POLICY_VALIDATION_FAILED error may mean that the intermediate certificate being sent by the server doesn't have a certificate policies extension<br />
** SEC_ERROR_EXTENSION_NOT_FOUND may mean that the certificate being sent by the server doesn't contain the specified policy OID.<br />
* If the test website cannot be reached by the server hosting the tool, check to see if you have a firewall preventing access. <br />
* Still failing? Try testing with https://certificate.revocationcheck.com/ because frequently resolving the errors listed on that page will resolve problems with EV testing.<br />
<br />
== About the Testing Tool ==<br />
The code for the Testing Tool is here: https://github.com/mozkeeler/ev-checker<br />
<br />
The Testing Tool...<br />
* Runs a program on a remote computer rather than the user's browser, so it should work with any browser/version. <br />
<br />
* Does not interact with the user's profile, so the user does not need to import the root certificate in order to run the tool. The web server must serve up the intermediate cert(s) along with the end-entity cert.<br />
<br />
* Runs on an [http://aws.amazon.com/ec2/ Amazon EC2 instance], so your test website must be accessible from Amazon EC2 instances.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=PSM:EV_Testing_Easy_Version&diff=1247983PSM:EV Testing Easy Version2023-09-14T21:53:06Z<p>Kathleen Wilson: updated to match the new tool</p>
<hr />
<div>This page is for [[CA:FAQ#What_are_CAs.3F | Certificate Authorities (CAs)]] who request to have a root certificate enabled for [https://cabforum.org/extended-validation Extended Validation (EV) treatment], and need to test that their CA hierarchy is ready for EV treatment.<br />
<br />
Before requesting EV treatment, CAs should understand how [[CA/EV_Processing_for_CAs | Firefox processes EV certificates]] and ensure that they are using the CA/Browser Forum EV OID (2.23.140.1.1), which Mozilla requires.<br />
<br />
To request that your root certificate be included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] and [https://hg.mozilla.org/mozilla-central/file/tip/security/certverifier/ExtendedValidation.cpp enabled for EV treatment], see [[CA/Application_Process|Mozilla's application process]].<br />
<br />
This page explains how you can test that your certificates and OCSP infrastructure are working correctly according to the expectations of Mozilla, Firefox, and the NSS library; and conforms to the SSL protocol specifications (as interpreted by Mozilla/NSS software.)<br />
<br />
= EV-Readiness Check =<br />
To test your CA hierarchy to see if it is ready to request EV treatment:<br />
# Browse to <br />
#* [https://github.com/mozilla/CCADB-Tools/tree/master/evReadiness NEW]: https://evready-dot-ccadb-231121.appspot.com/evready <br />
#* [https://github.com/mozilla/tls-observatory OLD]: https://tls-observatory.services.mozilla.com/static/ev-checker.html<br />
# Enter the URL to the test website for the EV certificate<br />
#* Example: https://observatory.mozilla.org<br />
# Enter the EV Policy OID<br />
#* Example: 2.23.140.1.1<br />
# Enter the PEM data for the root certificate, or use the "Browse..." button to select the PEM file for the root certificate (ending of file may be .pem or .cert)<br />
#* Begin with: -----BEGIN CERTIFICATE-----<br />
#* End with: -----END CERTIFICATE-----<br />
#* [https://crt.sh/?d=853428 Example PEM Data] - open with a plain text editor like TextEdit<br />
#* [http://ccadb.org/cas/fields#pem-data Help with getting PEM]<br />
# Click on "Submit"<br />
<br />
== Success == <br />
A successful result says: "Status: Success!"<br />
Any other text indicates a failure.<br />
<br />
== Test Failure? ==<br />
<br />
The purpose of this test is to make sure you have set up EV according to the [https://www.cabforum.org/documents.html EV Guidelines], so make sure you have not taken short-cuts like issuing the test cert directly from the root. <br />
* If you get ''Error: Could not initiate scan'', then wait for 3 minutes before trying again. <br />
* If you get ''SEC_ERROR_BAD_DATA'', then the program does not like the format of the data you entered. For instance, if you have extra spaces or characters before or after the TLS Server URL, EV Policy OID, or in the Root Certificate PEM.<br />
* The EV test only uses the root certificate it is given. So, if you are using an intermediate certificate that has been cross-signed with another root certificate, you may see different results when browsing to the site in Firefox, as opposed to the results provided by the EV Test. <br />
* OCSP must work without error for the intermediate certificates.<br />
* The EV Policy OID in the end-entity and intermediate certificates must match the EV Policy OID.<br />
** SEC_ERROR_POLICY_VALIDATION_FAILED error may mean that the intermediate certificate being sent by the server doesn't have a certificate policies extension<br />
** SEC_ERROR_EXTENSION_NOT_FOUND may mean that the certificate being sent by the server doesn't contain the specified policy OID.<br />
* If the test website cannot be reached by the server hosting the tool, check to see if you have a firewall preventing access. <br />
* Still failing? Try testing with https://certificate.revocationcheck.com/ because frequently resolving the errors listed on that page will resolve problems with EV testing.<br />
<br />
=== Running the test locally ===<br />
The following instructions may help you compile and run EV-Checker on Mac OS X.<br />
* One-time setup if needed, to get necessary developer tools <br />
** In Terminal window: <br />
*** curl https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py > bootstrap.py && python bootstrap.py<br />
*** Reference: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Mac_OS_X_Prerequisites<br />
** Other things you might need to install:<br />
*** brew install gnutls<br />
*** brew install nodejs<br />
*** brew install npm<br />
* To get the latest version of ev-checker:<br />
** git clone https://github.com/mozkeeler/ev-checker<br />
** cd ev-checker<br />
** make clean<br />
** make<br />
* To run EV Checker:<br />
** In Terminal window cd to the ev-checker folder and type: node server.js<br />
** In Firefox browser: http://localhost:8000/<br />
** Note: only one copy of the server may be running at a time. If you get an EADDRINUSE error, then in a terminal window type:<br />
***lsof -iTCP -sTCP:listen<br />
*** Look for any lines starting with "node"<br />
<br />
== About the Testing Tool ==<br />
The code for the Testing Tool is here: https://github.com/mozkeeler/ev-checker<br />
<br />
The Testing Tool...<br />
* Runs a program on a remote computer rather than the user's browser, so it should work with any browser/version. <br />
<br />
* Does not interact with the user's profile, so the user does not need to import the root certificate in order to run the tool. The web server must serve up the intermediate cert(s) along with the end-entity cert.<br />
<br />
* Runs on an [http://aws.amazon.com/ec2/ Amazon EC2 instance], so your test website must be accessible from Amazon EC2 instances.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=PSM:EV_Testing_Easy_Version&diff=1247981PSM:EV Testing Easy Version2023-09-14T21:34:19Z<p>Kathleen Wilson: updated to match the new tool</p>
<hr />
<div>This page is for [[CA:FAQ#What_are_CAs.3F | Certificate Authorities (CAs)]] who request to have a root certificate enabled for [https://cabforum.org/extended-validation Extended Validation (EV) treatment], and need to test that their CA hierarchy is ready for EV treatment.<br />
<br />
Before requesting EV treatment, CAs should understand how [[CA/EV_Processing_for_CAs | Firefox processes EV certificates]] and ensure that they are using the CA/Browser Forum EV OID (2.23.140.1.1), which Mozilla requires.<br />
<br />
To request that your root certificate be included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] and [https://hg.mozilla.org/mozilla-central/file/tip/security/certverifier/ExtendedValidation.cpp enabled for EV treatment], see [[CA/Application_Process|Mozilla's application process]].<br />
<br />
This page explains how you can test that your certificates and OCSP infrastructure are working correctly according to the expectations of Mozilla, Firefox, and the NSS library; and conforms to the SSL protocol specifications (as interpreted by Mozilla/NSS software.)<br />
<br />
= EV-Readiness Check =<br />
To test your CA hierarchy to see if it is ready to request EV treatment:<br />
# Browse to <br />
#* [https://github.com/mozilla/CCADB-Tools/tree/master/evReadiness NEW]: https://evready-dot-ccadb-231121.appspot.com/evready <br />
#* [https://github.com/mozilla/tls-observatory OLD]: https://tls-observatory.services.mozilla.com/static/ev-checker.html<br />
# Enter the URL to the test website for the EV certificate<br />
#* Example: https://observatory.mozilla.org<br />
# Enter the EV Policy OID<br />
#* Example: 2.23.140.1.1<br />
# Enter the PEM data for the root certificate, or use the "Browse..." button to select the PEM file for the root certificate (ending of file may be .pem or .cert)<br />
#* Begin with: -----BEGIN CERTIFICATE-----<br />
#* End with: -----END CERTIFICATE-----<br />
#* [https://crt.sh/?d=853428 Example PEM Data] - open with a plain text editor like TextEdit<br />
#* [http://ccadb.org/cas/fields#pem-data Help with getting PEM]<br />
# Click on "Submit"<br />
<br />
== Success == <br />
A successful result says: "Status: Success!"<br />
Any other text indicates a failure.<br />
<br />
== Test Failure? ==<br />
<br />
The purpose of this test is to make sure you have set up EV according to the [https://www.cabforum.org/documents.html EV Guidelines], so make sure you have not taken short-cuts like issuing the test cert directly from the root. <br />
* If you get ''Error: Could not initiate scan: Server error. Status: 429 Too Many Requests'', then wait for 3 minutes before trying again. TLS Observatory allows one scan per target every 3 minutes, so you will get this error if you test multiple times too quickly.<br />
* If you get ''Error: TypeError: json.analysis is undefined'', then the program does not like the format of the data you entered. For instance, if you have extra spaces or characters before or after the TLS Server URL, EV Policy OID, or Root Certificate PEM.<br />
* The EV test only uses the root certificate it is given. So, if you are using an intermediate certificate that has been cross-signed with another root certificate, you may see different results when browsing to the site in Firefox, as opposed to the results provided by the EV Test. <br />
* OCSP must work without error for the intermediate certificates.<br />
* The EV Policy OID in the end-entity and intermediate certificates must match the EV Policy OID.<br />
** SEC_ERROR_POLICY_VALIDATION_FAILED error may mean that the intermediate certificate being sent by the server doesn't have a certificate policies extension, or has an incorrect policy OID.<br />
* If the test website cannot be reached by the server hosting the tool, check to see if you have a firewall preventing access. If you are unable to create a test website that can be reached by the server hosting the tool, then you can download a copy of the [https://github.com/mozilla/tls-observatory source code] for the tool, compile it, and run it on your own server. <br />
* Still failing? Try testing with https://certificate.revocationcheck.com/ because frequently resolving the errors listed on that page will resolve problems with EV testing.<br />
<br />
=== Running the test locally ===<br />
The following instructions may help you compile and run EV-Checker on Mac OS X.<br />
* One-time setup if needed, to get necessary developer tools <br />
** In Terminal window: <br />
*** curl https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py > bootstrap.py && python bootstrap.py<br />
*** Reference: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Mac_OS_X_Prerequisites<br />
** Other things you might need to install:<br />
*** brew install gnutls<br />
*** brew install nodejs<br />
*** brew install npm<br />
* To get the latest version of ev-checker:<br />
** git clone https://github.com/mozkeeler/ev-checker<br />
** cd ev-checker<br />
** make clean<br />
** make<br />
* To run EV Checker:<br />
** In Terminal window cd to the ev-checker folder and type: node server.js<br />
** In Firefox browser: http://localhost:8000/<br />
** Note: only one copy of the server may be running at a time. If you get an EADDRINUSE error, then in a terminal window type:<br />
***lsof -iTCP -sTCP:listen<br />
*** Look for any lines starting with "node"<br />
<br />
== About the Testing Tool ==<br />
The code for the Testing Tool is here: https://github.com/mozkeeler/ev-checker<br />
<br />
The Testing Tool...<br />
* Runs a program on a remote computer rather than the user's browser, so it should work with any browser/version. <br />
<br />
* Does not interact with the user's profile, so the user does not need to import the root certificate in order to run the tool. The web server must serve up the intermediate cert(s) along with the end-entity cert.<br />
<br />
* Runs on an [http://aws.amazon.com/ec2/ Amazon EC2 instance], so your test website must be accessible from Amazon EC2 instances.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=PSM:EV_Testing_Easy_Version&diff=1247948PSM:EV Testing Easy Version2023-09-13T20:35:45Z<p>Kathleen Wilson: updated the new link</p>
<hr />
<div>This page is for [[CA:FAQ#What_are_CAs.3F | Certificate Authorities (CAs)]] who request to have a root certificate enabled for [https://cabforum.org/extended-validation Extended Validation (EV) treatment], and need to test that their CA hierarchy is ready for EV treatment.<br />
<br />
Before requesting EV treatment, CAs should understand how [[CA/EV_Processing_for_CAs | Firefox processes EV certificates]] and ensure that they are using the CA/Browser Forum EV OID (2.23.140.1.1), which Mozilla requires.<br />
<br />
To request that your root certificate be included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] and [https://hg.mozilla.org/mozilla-central/file/tip/security/certverifier/ExtendedValidation.cpp enabled for EV treatment], see [[CA/Application_Process|Mozilla's application process]].<br />
<br />
This page explains how you can test that your certificates and OCSP infrastructure are working correctly according to the expectations of Mozilla, Firefox, and the NSS library; and conforms to the SSL protocol specifications (as interpreted by Mozilla/NSS software.)<br />
<br />
= EV-Readiness Check =<br />
To test your CA hierarchy to see if it is ready to request EV treatment:<br />
# Browse to <br />
#* [https://github.com/mozilla/CCADB-Tools/tree/master/evReadiness NEW]: https://evready-dot-ccadb-231121.appspot.com/evready <br />
#* [https://github.com/mozilla/tls-observatory OLD]: https://tls-observatory.services.mozilla.com/static/ev-checker.html<br />
# Enter the URL to the test website for the EV certificate<br />
#* Example: https://observatory.mozilla.org<br />
# Enter the EV Policy OID<br />
#* Example: 2.23.140.1.1<br />
# Enter the PEM data for the root certificate, or use the "Browse..." button to select the PEM file for the root certificate (ending of file may be .pem or .cert)<br />
#* Begin with: -----BEGIN CERTIFICATE-----<br />
#* End with: -----END CERTIFICATE-----<br />
#* [https://crt.sh/?d=853428 Example PEM Data] - open with a plain text editor like TextEdit<br />
#* [http://ccadb.org/cas/fields#pem-data Help with getting PEM]<br />
# Click on "Submit"<br />
<br />
== Success == <br />
The status of the test will be displayed at the top of the window, just below the title "EV-Readiness Check". <br /><br />
A successful result says: "ev-checker exited successfully: Success!"<br />
<br />
== Test Failure? ==<br />
<br />
The purpose of this test is to make sure you have set up EV according to the [https://www.cabforum.org/documents.html EV Guidelines], so make sure you have not taken short-cuts like issuing the test cert directly from the root. <br />
* If you get ''Error: Could not initiate scan: Server error. Status: 429 Too Many Requests'', then wait for 3 minutes before trying again. TLS Observatory allows one scan per target every 3 minutes, so you will get this error if you test multiple times too quickly.<br />
* If you get ''Error: TypeError: json.analysis is undefined'', then the program does not like the format of the data you entered. For instance, if you have extra spaces or characters before or after the TLS Server URL, EV Policy OID, or Root Certificate PEM.<br />
* The EV test only uses the root certificate it is given. So, if you are using an intermediate certificate that has been cross-signed with another root certificate, you may see different results when browsing to the site in Firefox, as opposed to the results provided by the EV Test. <br />
* OCSP must work without error for the intermediate certificates.<br />
* The EV Policy OID in the end-entity and intermediate certificates must match the EV Policy OID.<br />
** SEC_ERROR_POLICY_VALIDATION_FAILED error may mean that the intermediate certificate being sent by the server doesn't have a certificate policies extension, or has an incorrect policy OID.<br />
* If the test website cannot be reached by the server hosting the tool, check to see if you have a firewall preventing access. If you are unable to create a test website that can be reached by the server hosting the tool, then you can download a copy of the [https://github.com/mozilla/tls-observatory source code] for the tool, compile it, and run it on your own server. <br />
* Still failing? Try testing with https://certificate.revocationcheck.com/ because frequently resolving the errors listed on that page will resolve problems with EV testing.<br />
<br />
=== Running the test locally ===<br />
The following instructions may help you compile and run EV-Checker on Mac OS X.<br />
* One-time setup if needed, to get necessary developer tools <br />
** In Terminal window: <br />
*** curl https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py > bootstrap.py && python bootstrap.py<br />
*** Reference: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Mac_OS_X_Prerequisites<br />
** Other things you might need to install:<br />
*** brew install gnutls<br />
*** brew install nodejs<br />
*** brew install npm<br />
* To get the latest version of ev-checker:<br />
** git clone https://github.com/mozkeeler/ev-checker<br />
** cd ev-checker<br />
** make clean<br />
** make<br />
* To run EV Checker:<br />
** In Terminal window cd to the ev-checker folder and type: node server.js<br />
** In Firefox browser: http://localhost:8000/<br />
** Note: only one copy of the server may be running at a time. If you get an EADDRINUSE error, then in a terminal window type:<br />
***lsof -iTCP -sTCP:listen<br />
*** Look for any lines starting with "node"<br />
<br />
== About the Testing Tool ==<br />
The code for the Testing Tool is here: https://github.com/mozkeeler/ev-checker<br />
<br />
The Testing Tool...<br />
* Runs a program on a remote computer rather than the user's browser, so it should work with any browser/version. <br />
<br />
* Does not interact with the user's profile, so the user does not need to import the root certificate in order to run the tool. The web server must serve up the intermediate cert(s) along with the end-entity cert.<br />
<br />
* Runs on an [http://aws.amazon.com/ec2/ Amazon EC2 instance], so your test website must be accessible from Amazon EC2 instances.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=PSM:EV_Testing_Easy_Version&diff=1247946PSM:EV Testing Easy Version2023-09-13T16:24:07Z<p>Kathleen Wilson: Added link to the new EV Readiness Checker</p>
<hr />
<div>This page is for [[CA:FAQ#What_are_CAs.3F | Certificate Authorities (CAs)]] who request to have a root certificate enabled for [https://cabforum.org/extended-validation Extended Validation (EV) treatment], and need to test that their CA hierarchy is ready for EV treatment.<br />
<br />
Before requesting EV treatment, CAs should understand how [[CA/EV_Processing_for_CAs | Firefox processes EV certificates]] and ensure that they are using the CA/Browser Forum EV OID (2.23.140.1.1), which Mozilla requires.<br />
<br />
To request that your root certificate be included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] and [https://hg.mozilla.org/mozilla-central/file/tip/security/certverifier/ExtendedValidation.cpp enabled for EV treatment], see [[CA/Application_Process|Mozilla's application process]].<br />
<br />
This page explains how you can test that your certificates and OCSP infrastructure are working correctly according to the expectations of Mozilla, Firefox, and the NSS library; and conforms to the SSL protocol specifications (as interpreted by Mozilla/NSS software.)<br />
<br />
= EV-Readiness Check =<br />
To test your CA hierarchy to see if it is ready to request EV treatment:<br />
# Browse to <br />
#* [https://github.com/mozilla/CCADB-Tools/tree/master/evReadiness NEW]: https://evready-dot-ccadb-231121.uc.r.appspot.com/evready<br />
#* [https://github.com/mozilla/tls-observatory OLD]: https://tls-observatory.services.mozilla.com/static/ev-checker.html<br />
# Enter the URL to the test website for the EV certificate<br />
#* Example: https://observatory.mozilla.org<br />
# Enter the EV Policy OID<br />
#* Example: 2.23.140.1.1<br />
# Enter the PEM data for the root certificate, or use the "Browse..." button to select the PEM file for the root certificate (ending of file may be .pem or .cert)<br />
#* Begin with: -----BEGIN CERTIFICATE-----<br />
#* End with: -----END CERTIFICATE-----<br />
#* [https://crt.sh/?d=853428 Example PEM Data] - open with a plain text editor like TextEdit<br />
#* [http://ccadb.org/cas/fields#pem-data Help with getting PEM]<br />
# Click on "Submit"<br />
<br />
== Success == <br />
The status of the test will be displayed at the top of the window, just below the title "EV-Readiness Check". <br /><br />
A successful result says: "ev-checker exited successfully: Success!"<br />
<br />
== Test Failure? ==<br />
<br />
The purpose of this test is to make sure you have set up EV according to the [https://www.cabforum.org/documents.html EV Guidelines], so make sure you have not taken short-cuts like issuing the test cert directly from the root. <br />
* If you get ''Error: Could not initiate scan: Server error. Status: 429 Too Many Requests'', then wait for 3 minutes before trying again. TLS Observatory allows one scan per target every 3 minutes, so you will get this error if you test multiple times too quickly.<br />
* If you get ''Error: TypeError: json.analysis is undefined'', then the program does not like the format of the data you entered. For instance, if you have extra spaces or characters before or after the TLS Server URL, EV Policy OID, or Root Certificate PEM.<br />
* The EV test only uses the root certificate it is given. So, if you are using an intermediate certificate that has been cross-signed with another root certificate, you may see different results when browsing to the site in Firefox, as opposed to the results provided by the EV Test. <br />
* OCSP must work without error for the intermediate certificates.<br />
* The EV Policy OID in the end-entity and intermediate certificates must match the EV Policy OID.<br />
** SEC_ERROR_POLICY_VALIDATION_FAILED error may mean that the intermediate certificate being sent by the server doesn't have a certificate policies extension, or has an incorrect policy OID.<br />
* If the test website cannot be reached by the server hosting the tool, check to see if you have a firewall preventing access. If you are unable to create a test website that can be reached by the server hosting the tool, then you can download a copy of the [https://github.com/mozilla/tls-observatory source code] for the tool, compile it, and run it on your own server. <br />
* Still failing? Try testing with https://certificate.revocationcheck.com/ because frequently resolving the errors listed on that page will resolve problems with EV testing.<br />
<br />
=== Running the test locally ===<br />
The following instructions may help you compile and run EV-Checker on Mac OS X.<br />
* One-time setup if needed, to get necessary developer tools <br />
** In Terminal window: <br />
*** curl https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py > bootstrap.py && python bootstrap.py<br />
*** Reference: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Mac_OS_X_Prerequisites<br />
** Other things you might need to install:<br />
*** brew install gnutls<br />
*** brew install nodejs<br />
*** brew install npm<br />
* To get the latest version of ev-checker:<br />
** git clone https://github.com/mozkeeler/ev-checker<br />
** cd ev-checker<br />
** make clean<br />
** make<br />
* To run EV Checker:<br />
** In Terminal window cd to the ev-checker folder and type: node server.js<br />
** In Firefox browser: http://localhost:8000/<br />
** Note: only one copy of the server may be running at a time. If you get an EADDRINUSE error, then in a terminal window type:<br />
***lsof -iTCP -sTCP:listen<br />
*** Look for any lines starting with "node"<br />
<br />
== About the Testing Tool ==<br />
The code for the Testing Tool is here: https://github.com/mozkeeler/ev-checker<br />
<br />
The Testing Tool...<br />
* Runs a program on a remote computer rather than the user's browser, so it should work with any browser/version. <br />
<br />
* Does not interact with the user's profile, so the user does not need to import the root certificate in order to run the tool. The web server must serve up the intermediate cert(s) along with the end-entity cert.<br />
<br />
* Runs on an [http://aws.amazon.com/ec2/ Amazon EC2 instance], so your test website must be accessible from Amazon EC2 instances.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1247872NSS:Release Versions2023-09-06T17:11:04Z<p>Kathleen Wilson: CA List version was bumped to 2.62 in NSS 3.92</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
| B. Beurdouche<br />
|-<br />
| 3.95<br />
|<br />
|<br />
| 2023-10-12<br />
| '''2023-10-19'''<br />
| 2023-10-23<br />
| 120<br />
| 2023-11-21<br />
| D. Jackson<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
| A. Weine<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| TBD<br />
| J. Schanck<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1247871NSS:Release Versions2023-09-06T17:09:06Z<p>Kathleen Wilson: Reverted edits by Kathleen Wilson (talk) to last revision by Beurdouche</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
| B. Beurdouche<br />
|-<br />
| 3.95<br />
|<br />
|<br />
| 2023-10-12<br />
| '''2023-10-19'''<br />
| 2023-10-23<br />
| 120<br />
| 2023-11-21<br />
| D. Jackson<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
| A. Weine<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| TBD<br />
| J. Schanck<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
|<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1247870NSS:Release Versions2023-09-06T17:06:29Z<p>Kathleen Wilson: CA List version was bumped to 2.62 in Firefox 3.92</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
| B. Beurdouche<br />
|-<br />
| 3.95<br />
|<br />
|<br />
| 2023-10-12<br />
| '''2023-10-19'''<br />
| 2023-10-23<br />
| 120<br />
| 2023-11-21<br />
| D. Jackson<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
| A. Weine<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| TBD<br />
| J. Schanck<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Communications&diff=1247831CA/Communications2023-09-02T23:50:50Z<p>Kathleen Wilson: minor re-arrangement</p>
<hr />
<div>The following are communications that have been sent to Certification Authorities participating in [[CA | Mozilla's root program.]] If you have questions regarding these communications, please first review related discussions in the Mozilla dev-security-policy forum. If your questions cannot be answered in that forum, then please send email to certificates@mozilla.org.<br />
<br />
== August 2023 CA Communication and Survey ==<br />
<br />
Communication and Survey: <br />
https://docs.google.com/document/d/1ieXSt3rJyOSopJnDp4wFGSugpk6pt5pJFJ55rkpb6Ks/edit?usp=sharing <br />
<br />
The purpose of this communication and survey is to ensure that CA operators are aware of and prepared to comply with changes to the Mozilla Root Store Policy (MRSP), which we plan to publish soon as version 2.9 with an effective date of September 1, 2023.<br />
<br />
The most significant changes to v2.9 of MRSP are:<br />
# Retirement of Older Root CA Certificates <br />
#* https://wiki.mozilla.org/CA/Root_CA_Lifecycles<br />
# Compliance with the CABF’s S/MIME BRs <br />
#* https://wiki.mozilla.org/CA/Transition_SMIME_BRs<br />
# Security Vulnerability Reporting<br />
#* https://wiki.mozilla.org/CA/Vulnerability_Disclosure<br />
# Removed duplication with CCADB Policy regarding Audit Requirements<br />
#* https://www.ccadb.org/policy<br />
# Annual Submission of CCADB Compliance Self-Assessment<br />
#* https://www.ccadb.org/cas/self-assessment<br />
# Elimination of SHA-1<br />
<br />
Survey Responses:<br />
Coming Soon<br />
<br />
== February 2023 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s Root Store Policy (MRSP) was recently updated to version 2.8.1 with an effective date of February 15, 2023, https://github.com/mozilla/pkipolicy/pull/265/files. Version 2.8.1 contains several clarifications and minor changes that may affect your organization. You need to be aware of these clarifications and changes to ensure your continued compliance with the MRSP. The following are summaries only of the actual language in the MRSP, and in the event of any conflicting interpretation, the MRSP takes precedence over these summaries:<br />
<br />
* You are required to follow and be aware of discussions in both the Mozilla dev-security-policy forum, https://groups.google.com/a/mozilla.org/g/dev-security-policy, and the CCADB Public List, https://groups.google.com/a/ccadb.org/g/public;<br />
* Your CP, CPS, or combined CP/CPS MUST clearly explain your CA’s domain validation procedures and indicate which subsection of section 3.2.2.4 of the CA/Browser Forum’s Baseline Requirements you are complying with;<br />
* Your CP, CPS, or combined CP/CPS MUST be updated at least every 365 days (more often is expected), and it must be reported in the CCADB in a “timely manner”, and failure to do either of these things will require that you file an incident report in Bugzilla;<br />
* You MUST maintain links to all historic versions of each CP, CPS, or combined CP/CPS from the creation of included CA certificates until such certificate hierarchies are no longer trusted by the Mozilla root store, and if your CA certificate was included by Mozilla before December 31, 2022, then you still must maintain links for “reasonably available historic versions” of your CPs, CPSes, or combined CP/CPSes; and<br />
* In the CCADB, if you elect to publish a JSON array of partial CRLs (rather than the full CRL), then the JSON Array of Partitioned CRLs must contain a critical Issuing Distribution Point extension, which shall include a URI whose value is derived from either the URI as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5) or the URL included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA.<br />
<br />
Finally, participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard user security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you very much for your continued cooperation in this pursuit.<br />
<br />
Regards,<br />
Ben Wilson<br />
Mozilla CA Program Manager<br />
<br />
<br />
<br />
== May 2022 CA Communication and Survey ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a058Z000013UmsDQAS Read-only copy of May 2022 CA Communication and Survey]<br />
** This link is '''Read Only'''. To submit your responses, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2022 CA Communication and Survey' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
=== May 2022 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00160,Q00161 Responses to Item 1] -- Compliance with MRSP v. 2.8<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00162,Q00163 Responses to Item 2] -- "Incidents" include audit findings<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00164,Q00165 Responses to Item 3] -- Auditor membership in ACAB'c and WebTrust<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00166,Q00167,Q00168 Responses to Item 4] -- Online Archival of CPs and CPSes<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00169,Q00170 Responses to Item 5] -- Full CRLs for Intermediate TLS CAs in CCADB<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00171,Q00172 Responses to Item 6.1] -- Sunsetting of SHA1 for S/MIME Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00173,Q00174 Responses to Item 6.2] -- Sunsetting of SHA1 for Other Types of Signing<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00175,Q00176 Responses to Item 7] -- Publicly Disclose Intermediate CA Certificates capable of Issuing TLS or S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00177,Q00178 Responses to Item 8] -- Misissuance of Certificate Transparency Precertificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00179,Q00180,Q00181 Responses to Item 9] -- CRL Revocation Reasons for TLS Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00182,Q00183 Responses to Item 10] -- Public Review of Unconstrained Externally-Operated Subordinate CAs<br />
<br />
== February 2022 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla is engaged in policy review discussions to sunset the use of SHA1 for signing by CAs of CRLs, OCSP responses, and SMIME certificates.<br />
See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/CnVjV-bFcyI/m/TFuWOy2BAwAJ<br />
<br />
(Server certificate signing is governed by the Baseline Requirements, and effective June 1, 2022, OCSP responses related to server certificates cannot be signed with SHA1.)<br />
<br />
One proposal is to remove SHA1 from the list of allowed signing algorithms altogether, but before we do this, I would like your proposed sunset dates for the different types of SHA1 signing you might currently perform--SMIME certificates, ARLs/CRLs, and OCSP responses for SMIME certificates.<br />
<br />
Please participate in this important topic, which is already underway on the Mozilla dev-security-policy list. Let us know about your specific concerns and hurdles that would need to be overcome.<br />
(Some CAs have expressed willingness to quickly convert over to SHA256, while others have expressed that it is not a simple task and will require additional development work.)<br />
<br />
Thanks,<br />
Ben Wilson (bwilson@mozilla.com)<br />
Mozilla Root Store Program<br />
<br />
== April 2021 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a054o00000EL1Fo Read-only copy of April 2021 CA Communication]<br />
** This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br><br />
<br><br />
Mozilla’s Root Store Policy was recently updated to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ version 2.7.1] with an effective date of 1 May 2021. This version contains [https://github.com/mozilla/pkipolicy/pull/223 several changes] that may affect your organization and the auditors who evaluate your PKI. These changes require you to take action to ensure your continued compliance. <br />
<br><br><br />
Please review version 2.7.1 of [https://www.mozilla.org/projects/security/certs/policy/ Mozilla’s Root Store Policy] internally, and with your auditors as well. After you and your auditors have reviewed these new requirements, complete the April 2021 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your practices. Read all survey questions first before beginning to respond. <br />
<br><br><br />
To respond to this survey, [https://ccadb.org/cas/ log in to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 30-April-2021.<br />
<br><br><br />
A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Ben Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== April 2021 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00129,Q00142 Responses to Item 1] -- Review Version 2.7.1 of Mozilla's Root Store Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00131,Q00149,Q00143 Responses to Item 2] -- 398-day reuse period on domain/IP address validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00132,Q00144 Responses to Item 3] -- Clarification about EV Audit Requirements <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00133,Q00145 Responses to Item 4] -- Annual Audit Covering the CA Key Pair Lifecycle <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00136,Q00146 Responses to Item 5] -- Audit Team Qualifications<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00137,Q00147 Responses to Item 6] -- List of Incidents in Audit Reports<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00140,Q00150,Q00148 Responses to Item 7] -- Methods to Demonstrate Key Compromise<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00141,Q00157,Q00159 Responses to Item 8] -- Removal of Old Root CA Certificates (challenges and alternatives)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00156,Q00151,Q00158 Responses to Item 8 timelines] -- Timelines and strategies to replace old, non-BR compliant CA hierarchies and root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00152,Q00155,Q00153 Responses to Item 9] -- Audit Letter Validation on Intermediate Certificates<br />
<br />
== May 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J000042AUSv Read-only copy of May 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>This survey requests your input on current policy and upcoming policy changes that affect you as a participant in Mozilla's CA Certificate Program. <br />
<br><br />
<br>To respond to this survey, [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 31-May 2020. <br />
<br><br />
<br>A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br><br />
<br>Regards,<br />
<br>Kathleen Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== May 2020 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00099,Q00100 Responses to Item 1] -- Impact of COVID-19 Restrictions<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00101,Q00102, Responses to Item 2] -- Mozilla Root Store Policy version 2.7 Requirements and Deadlines <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00103,Q00104 Responses to Item 3] -- Reducing Maximum Validity Period for TLS Certificates <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107 Responses to Sub Item 3.1] -- Limit TLS Certificates to 398-day validity<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00108,Q00109,Q00110 Responses to Sub Item 3.2] -- Limit re-use of domain name and IP address verification to 398 days<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00111,Q00112 Responses to Item 4] -- CA/Browser Forum Ballot for Browser Alignment <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00113,Q00114,Q00115 Responses to Sub Item 4.1] -- CA/Browser Forum defined-policy OID in Subscriber Cert certificatePolicies<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00116,Q00117,Q00118 Responses to Sub Item 4.2] -- Byte-for-byte Identical Issuer and Subject Distinguished Names<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00119,Q00120,Q00121 Responses to Sub Item 4.3] -- Text-searchable PDF Audit Statements<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00122,Q00123,Q00124 Responses to Sub Item 4.4] -- OCSP Requirements<br />
<br />
== January 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003waNOW Read-only copy of January 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/ updated]. The 2.7 version went into effect on 1-January 2020. This version contains a [https://github.com/mozilla/pkipolicy/pull/199/files number of changes] that may affect your organization and will require you to take action to comply. Please review Mozilla’s updated Root Store Policy and complete the January 2020 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your Certificate Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘January 2020 CA Communication' survey. Please enter your response by 31 January 2020.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== January 2020 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00082,Q00083 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00084,Q00085,Q00098 Responses to Action 2] -- Update CP/CPS <br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00086,Q00087,Q00097 Responses to Action 3] -- Include EKUs in All End-entity Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00088,Q00089 Responses to Action 4] -- Ensure Audit Reports are Properly Formatted<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00090,Q00096,Q00091 Responses to Action 5] -- Resolve Audit Issues with Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00092,Q00093 Responses to Action 6] -- Incident Reporting<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00094,Q00095 Responses to Action 7] -- Compliance with BRs<br />
<br />
== November 2018 CA Communication (Underscores in dNSNames) ==<br />
On November 12, 2018, the following message was sent to all CAs in the Mozilla program, alerting them to CA/Browser Forum SC12 that established a brief sunset period for the use of underscore characters in dNSNames in publicly-trusted TLS certificates.<br />
<br /><br />
<br />
Dear Certification Authority,<br />
<br />
The CA/Browser Forum recently approved [1] a clarification to the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (BRs) that may affect you. Domain names containing underscore (“_”) characters are not permitted to be encoded as dNSName types in the subjectAlternativeName (SAN) field of BR-compliant certificates. This requirement derives from section 4.2.1.6 of RFC 5280 that the BRs require CAs to comply with by reference.<br />
<br />
Section 7.1.4.2.1 of the BRs will add the following language that clarifies the existing requirement and adds a short time in which CAs must discontinue the use of underscore characters in dNSNames:<br />
-----<br />
Prior to April 1, 2019, certificates containing underscore characters (“_”) in domain labels in dNSName entries MAY be issued as follows:<br />
* dNSName entries MAY include underscore characters such that replacing all underscore characters with hyphen characters (“-“) would result in a valid domain label, and;<br />
* Underscore characters MUST NOT be placed in the left most domain label, and;<br />
* Such certificates MUST NOT be valid for longer than 30 days.<br />
<br />
All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019.<br />
<br />
After April 30, 2019, underscore characters (“_”) MUST NOT be present in dNSName entries.<br />
-----<br />
This new language will go into effect on December 10, 2018 when the IPR review period for ballot SC12 [1] is completed. At that time, CAs must be prepared to stop issuing publicly-trusted TLS certificates containing the underscore character in any dNSName with validity periods of more than 30 days.<br />
<br />
As a participant in Mozilla's CA Certificate Program, we want you to be aware of this important change, and ask that you take any necessary steps to comply. No further action related to this change is requested at this time.<br />
<br />
Regards,<br />
<br />
Wayne Thayer<br />
Mozilla CA Program Manager<br />
<br />
[1] https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/<br />
<br />
=== November 2018 Responses ===<br />
* No survey was included in this CA Communication<br />
<br />
== September 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL Read-only copy of September 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'September 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/ updated]. The 2.6.1 version went into effect on 1-July, 2018. This version contains a number of changes that may affect your organization and will require you to take action to comply. This survey also contains information regarding other recent and upcoming changes that may affect your Certification Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘September 2018 CA Communication' survey. Please enter your response by 30-September 2018.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== September 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00068,Q00069 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00070,Q00071 Responses to Action 2] -- Update CP/CPS<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00072,Q00073 Responses to Action 3] -- Transition to Separate Intermediate Certificates for SSL and S/MIME<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00074,Q00075 Responses to Action 4] -- Ensure Audit Reports comply with Mozilla’s Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00076,Q00077 Responses to Action 5] -- Discontinue use of BR Validation Methods 3.2.2.4.1 and 3.2.2.4.5<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00078,Q00079 Responses to Action 6] -- Disclose Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00080,Q00081 Responses to Action 7] -- Submit TLS Certificates to CT Logs for Mozilla's CRLite<br />
<br />
== January 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mqMFN Read-only copy of January 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br /><br /><br />
2018 has already generated some important news for Certification Authorities, and as a result we are sending this message to ensure that every CA in the Mozilla program is aware of current events and impending deadlines.<br />
<br /><br /><br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.<br />
<br /><br /><br />
To respond to this survey, login to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Please enter your response by 9-February 2018.<br />
<br /><br /><br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br /><br /><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br /><br /><br />
Regards,<br /><br />
Wayne Thayer<br /><br />
Mozilla CA Program Manager<br /><br />
<br />
=== January 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00056,Q00057 Responses to Action 1] -- Disclose Use of Methods 3.2.2.4.9 or 3.2.2.4.10 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00058,Q00059 Responses to Action 2] -- Disclose Use of Methods 3.2.2.4.1 or 3.2.2.4.5 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00060,Q00061 Responses to Action 3] -- Disclose All Non-Technically-Constrained Subordinate CA Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00062,Q00063 Responses to Action 4] -- Complete BR Self Assessment<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00064,Q00065 Responses to Action 5] -- Update CP/CPS to Comply with version 2.5 of Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00066,Q00067 Responses to Action 6] -- Reduce SSL Certificate Validity Periods to 825 Days or Less by March 1, 2018<br />
<br />
== November 2017 CA Communication ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7 Read-only copy of November 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority, <br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, login to the [http://ccadb.org/cas Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Please enter your response by December 15, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be [[CA/Communications|automatically and immediately published]] by the CCADB system.<br />
<br />
Participation in [[CA|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== November 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00035,Q00036 Responses to Action 1] -- Full compliance with version 2.5 of [https://www.mozilla.org/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00037,Q00044 Responses to Action 2] -- non-technically-constrained intermediate certificates must be [http://ccadb.org/cas/intermediates disclosed in CCADB] within one week of creation. '''New requirements''' for [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#technically-constrained technical constraints on intermediate certificates issuing S/MIME certificates].<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00038,Q00045 Responses to Action 3] -- Annual updates via [http://ccadb.org/cas/updates CCADB Audit Cases]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00050,Q00051 Responses to Action 4] -- Reiterate [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#audit-parameters audit requirements] and '''penalty for incomplete audit statements'''<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00039,Q00046 Responses to Action 5] -- Perform a [[CA/BR_Self-Assessment|BR Self Assessment]]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00042,Q00048 Responses to Action 6] -- Provide tested email address for [https://ccadb.my.salesforce-sites.com/mozilla/CAInformationReport Problem Reporting Mechanism]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00040,Q00047 Responses to Action 7] -- Follow new developments and effective dates for [http://tools.ietf.org/html/rfc6844 Certification Authority Authorization (CAA)]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00052,Q00053 Responses to Action 8] -- Check [https://groups.google.com/d/msg/mozilla.dev.security.policy/4kj8Jeem0EU/GvqsgIzSAAAJ issuance of certs to .tg domains] from October 25 to November 11, 2017.<br />
<br />
== May 2017 - Announcing CCADB Changes ==<br />
<br /><br />
Subject: Common CA Database (CCADB) changes May 19-21, 2017<br />
<br /><br /><br />
Message:<br /><br /><br />
Dear Certification Authority,<br />
<br /><br />
<br /><br />
The Common CA Database (CCADB) will undergo the following changes this weekend, May 19 to May 21. During this time, the old URLs listed below will stop working, and there will be some time when the CCADB is in read-only mode.<br />
<br /><br />
<br /><br />
On May 19 the following three breaking changes are planned, meaning that the old URLs will no longer work. Any links or bookmarks to these URLs will need to be updated. After these changes are made, I will also update Mozilla's wiki pages to point to the new URLs.<br />
<br /><br />
<br /><br />
1) The CA login page and the domain CAs see when they are logged into the CCADB will change.<br />
<br /><br />
https://mozillacacommunity.force.com/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb.force.com/<br />
<br /><br />
<br /><br />
2) The links to reports that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/CA/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/mozilla/<br />
<br /><br />
<br /><br />
3) The links to CA communication responses that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/Communications<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/Surveys<br />
<br /><br />
<br /><br />
Then on May 21 between 12am and 4am PDT, the CCADB will be in read-only mode while Salesforce performs an instance refresh to upgrade the infrastructure supporting the CCADB instance in their data centers.<br />
<br /><br />
<br /><br />
Regards,<br />
<br /><br />
Kathleen<br />
<br />
== April 2017 ==<br />
<br />
Note: The deadline to reply to this survey has [https://groups.google.com/d/msg/mozilla.dev.security.policy/03rdTdnm7iw/NQUHmWOcEAAJ been extended] by one week, to May 5, 2017.<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000003WrzBC Read-only copy of April 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [https://ccadb.force.com/CustomLogin login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA:IncludedCAs|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, [https://mozillacacommunity.force.com/CustomLogin login to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Please enter your response by April 28, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br />
In addition to responding to the action items in this survey, we are instituting a program requirement that you follow discussions in the [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] forum, which includes discussions about upcoming changes to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy], questions and clarification about policy and expectations, root certificate [[CA|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] or other program requirements. You are not required to contribute to those discussions, only to be aware of them. However, we hope you will participate and help shape the future of Mozilla's CA Certificate Program.<br />
<br />
Participation in [[CA:Overview|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== April 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [[CA:CommonCADatabase|Common CA Database]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00015,Q00030 Responses to Action 1] -- Domain Validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 2 and Action 10] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00022,Q00029 Responses to Action 3] -- Updated Mozilla CA Certificate Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00017,Q00031 Responses to Action 4] -- Audit Statements, annual updates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00018,Q00032 Responses to Action 5] -- Audit Statement Contents<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00021,Q00033 Responses to Action 6] -- Qualified Audit Statements<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00019 Responses to Action 7] -- BR Compliance Bugs<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 Responses to Action 8] -- Confirm Completion of Previous Commitments<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00027 Responses to Action 9] -- Registration Authorities<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 10 and Action 2] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00023 Responses to Action 11] -- Certification Authority Authorization (CAA)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00028 Responses to Action 12] -- Problem Reporting Mechanism<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00024 Responses to Action 13] -- SHA-1 and S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00034 Responses to Action 14] -- Certificate Validity Periods in TLS/SSL Certs<br />
<br />
== March 2016 ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000000iHdtx Read-only copy of March 2016 CA Communication]<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program, by April 22, 2016.<br />
<br />
To respond to this survey, please login to the [[CA:SalesforceCommunity|CA Community in Salesforce]], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'March 2016 CA Communication' survey. Please enter your response by April 22, 2016. <br />
<br />
A compiled list of CA responses to the survey action items will be [[CA:Communications#March_2016_Responses|automatically and immediately published]] by Salesforce.<br />
<br />
In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the [https://groups.google.com/forum/#!forum/mozilla.dev.security.policy mozilla.dev.security.policy] forum, which includes discussions about [[CA:CertificatePolicyV2.3|upcoming changes to Mozilla's CA Certificate Policy]], questions and clarification about policy and expectations, root certificate [[CA:Schedule|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements]. Your contributions to the discussions will help shape the future of [[CA:Overview|Mozilla's CA Certificate Program]].<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Mozilla CA Program Manager<br />
<br />
=== March 2016 Responses ===<br />
<br />
The following links are automatically generated from data in the [[CA:SalesforceCommunity|CA Community in Salesforce]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommSummaryReport?CommunicationID=a05o000000iHdtx CA Responses to March 2016 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00001,Q00013 Responses to Action #1a] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00002,Q00014 Responses to Action #1b] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 Responses to Action #1c] -- SHA-1 Deprecation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 Responses to Action #2] -- Entering intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00005 Responses to Action #3] -- Entering revoked intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00006&QuestionIdForText=Q00007 Responses to Action #4] -- [[SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix|Removing workarounds]] to compatibility issues that were encountered involving certificates that did not conform to the Baseline Requirements. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00008 Responses to Action #5] -- Plans to remove old/retired root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00009 Responses to Action #6] -- Confirmation of understanding that all certificates, including test certificates, must conform to stated policies<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00012 Responses to Action #7] -- [[CA:RootTransferPolicy|Mozilla's Root Transfer Policy]]<br />
<br />
== May 2015 ==<br />
<br />
Dear Certification Authority, <br />
<br />
This email requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by June 5, 2015, with your response to the action items by clicking on the survey link below. A compiled list of CA responses to these action items will be published. <br />
<br />
Certification Authority: <CA Account Name><br />
<br />
Your Survey Link: <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/TakeSurvey?id=a04o000000M89RCAAZ&cId=&caId=none Survey Link] -- '''IMPORTANT: CA's do NOT use the link in this wiki page! This link will NOT record your response. Please use the link that was emailed to you.'''<br />
<br />
Please use the above link to read and respond to the action items. Note that you may access the above link multiple times to update your responses.<br />
<br />
Additionally, we plan to update Mozilla's CA Certificate Policy soon, and will be discussing proposed policy updates in the mozilla.dev.security.policy forum, https://www.mozilla.org/en-US/about/forums/#dev-security-policy. We encourage you to monitor the discussions to see how the updates will impact you, and your participation in the discussions will help shape the policy updates.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, <br />
Mozilla <br />
CA Program Manager<br />
<br />
=== May 2015 Responses ===<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationSummaryReport?CommunicationId=a04o000000M89RCAAZ CA Responses to May 2015 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%233:%20After%20January%201,%202016 Responses to Action #3] -- SHA-1 Deprecation Plans<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%234:%20Workarounds%20were%20implemented Responses to Action #4] -- Removing workarounds implemented to allow mozilla::pkix to handle the things listed here https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%235:%20We%20wish%20to%20understand%20what%20support Responses to Action #5] -- IPv6 survey<br />
<br />
== May 2014 ==<br />
<br />
Subject: Mozilla Communication: Action requested by May 30, 2014<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by May 30, 2014, with your response to these action items. A compiled list of CA responses to the following action items will be published. <br />
<br />
CA Certificate Inclusion Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/<br />
<br />
CA Certificate Maintenance Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/<br />
<br />
Spreadsheet of included root certificates: http://www.mozilla.org/about/governance/policies/security-group/certs/included/<br />
<br />
1) Ensure that Mozilla’s [http://www.mozilla.org/about/governance/policies/security-group/certs/included/ spreadsheet of included root certificates] has the correct link to your most recent audit statement, and that the date of the audit statement is correct. As per [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/ Mozilla's CA Certificate Maintenance Policy], we require that all CAs whose certificates are distributed with our software products provide us an updated statement annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties. To notify us of an updated statement of attestation, send email to certificates@mozilla.org or [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates submit a bug report] into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "mozilla.org" product.<br />
If you are not proactively sending Mozilla your updated audit statements, please create a process to do so.<br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent audit statement, and the audit statement date is correct.<br />
* B) Here is the most recent audit statement for our certificates that are included in Mozilla’s CA program: <insert link here> <br />
* C) We plan to send Mozilla our current audit statement by <insert date here>.<br />
* D) We do not have a current audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
2) Send Mozilla the link to your most recent [https://cabforum.org/about-the-baseline-requirements/ Baseline Requirements] audit statement. Details about Mozilla's audit requirements are listed in section 11 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy]. The Baseline Requirements audit statement should also be proactively sent to Mozilla each year, along with the other audit statements as described in action #1. <br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent Baseline Requirements audit statement.<br />
* B) Here is the most recent Baseline Requirements audit statement for our certificates that are included in Mozilla’s CA program: <insert link here>. <br />
* C) We plan to send Mozilla our current Baseline Requirements audit statement by <insert date here and explain reason for delay>.<br />
* D) The websites (SSL/TLS) trust bit is not enabled for our certificates that are included in Mozilla's CA program.<br />
* E) We do not have a current Baseline Requirements audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
3) Test Mozilla's new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed. <br />
The new Certificate Verification library (mozilla::pkix) was announced here: https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ .<br />
Mozilla::pkix includes some changes in support of current best practices and policies, as listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes .<br />
How to test: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing .<br />
<br />
Please respond with one of the following: <br />
* A) We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix.<br />
* B) We have found the following issues when testing certificates in our CA hierarchy with mozilla::pkix. <descriptions or Bugzilla bug numbers, related URLs and/or certificates><br />
* C) We are testing certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and plan to send Mozilla our results by <insert date here, must be before June 30, 2014>.<br />
<br />
4) Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix<br />
<br />
Please respond with one of the following: <br />
* A) We have not and will not issue certificates with any of the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page.<br />
* B) We have previously issued certificates with the following problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page: <list the problems that needed to be fixed>. The last of those certificates expire <insert dates here, one date per problem>. We will not issue new certificates with the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page as of this date: <date when your operations will be updated, no later than June 30, 2014><br />
<br />
5) Send Mozilla information about your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, as per Items #8, 9, and 10 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy].<br />
<br />
Please provide a URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, and contains the required information according to section 10 of Mozilla's CA Certificate Inclusion Policy. If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificates" component of the "mozilla.org" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates)<br />
<br />
Additionally, please respond with one of the following: <br />
* A) All subordinate CA certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy.<br />
* B) We request an extension for the following specific subordinate CA certificates, because these subordinate CAs need more time to transition from their legacy systems to their new CA hierarchy: <list of issuer hash, issuer public key hash, and certificate serial number>. For each subordinate CA who needs to operate in their legacy design a little longer, the attached document explains the reason that continued operation is needed and their target date for resolution. <attach document(s) to response><br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== May 2014 Responses ===<br />
<br />
[https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml CA Responses to May 2014 Communication]<br />
<br />
== July 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by August 16, 2013<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s CA Certificate Policy has been updated with a few important changes. This update was motivated by security concerns regarding ICANN granting applied-for new gTLD strings. Additionally, we want to make it very clear that there will be serious consequences if it is found that a CA has knowingly or intentionally mis-issued certificates chaining to trust anchors in Mozilla’s program.<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of applications.<br />
<br />
Please carefully review the following wiki page for information about the changes introduced in version 2.2 of Mozilla’s CA Certificate Policy.<br />
<br />
https://wiki.mozilla.org/CA:CertificatePolicyV2.2<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by August 16, 2013, with your response to the following action items. <br />
<br />
1) Update your CA operations and policies to include the CA/Browser Forum’s Baseline Requirement #11.1.4 regarding new gTLD domains, and subscribe to ICANN’s new gTLD Registry Agreement notification mailing list at: https://mm.icann.org/mailman/listinfo/gtldnotification<br />
<br />
Please respond with one of the following:<br />
* A) No action required, because we have not and will not issue SSL certificates with internal or private domain names chaining up to root certificates that are included in Mozilla’s program.<br />
* B) We have issued or may issue SSL certificates with internal or private domain names that chain up to root certificates that are included in Mozilla’s program, so we are implementing Baseline Requirement #11.1.4, and will subscribe to ICANN’s notification service regarding applied-for-gTLD strings. We plan to have this completed by September 16, 2013.<br />
* C) We have already implemented Baseline Requirement #11.1.4, and have subscribed to ICANN’s notification service regarding applied-for-gTLD strings.<br />
<br />
2) Review your CA operations and customers to ensure that there are no certificates chaining up to your trust anchors that are included in Mozilla’s program that may be used for MITM or “traffic management” of domain names or IP addresses that the certificate holder does not own or control. [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla’s CA Certificate Enforcement Policy] has been updated to make it clear that Mozilla will not tolerate this use of publicly trusted certificates. <br />
<br />
Please respond with:<br />
* “We have reviewed Mozilla’s updated CA Certificate Enforcement Policy and understand that knowing or intentional mis-issuance of a certificate is expressly against Mozilla’s CA Certificate Policy and could result in removal of all of our certificates from Mozilla’s products.”<br />
<br />
3) Ensure that your CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current, including links to the CP/CPS documents, audit statements, and test websites. Mozilla will be adding a column to this spreadsheet to indicate the date of the most recent audit statement for each root certificate.<br />
<br />
http://www.mozilla.org/projects/security/certs/included/index.html<br />
<br />
Please respond with one of the following:<br />
* A) Our CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current for all of our included certificates.<br />
* B) Here is the current information for our certificates that are included in Mozilla’s program: <insert data here><br />
<br />
4) Complete the action items from Mozilla’s January CA Communication.<br />
* https://wiki.mozilla.org/CA:Communications#January_10.2C_2013<br />
* https://wiki.mozilla.org/CA:Communications#January_2013_Responses<br />
<br />
Please respond with one of the following:<br />
* A) Our recorded response to the January CA Communication is complete and correct.<br />
* B) We have the following updated status for our response to the January CA Communication: <insert data here><br />
<br />
5) Follow discussion about the changes to policy and code that Mozilla will be making in order to improve how revocation checking is handled in Firefox. Discussions will be held in the mozilla.dev.security.policy forum, and descriptions of the changes that will be considered for both policy and code will be provided here: https://wiki.mozilla.org/CA:ImprovingRevocation<br />
As part of this effort, Mozilla will be implementing a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker. More information will follow, and policy will be added soon to require CAs to send Mozilla revocation information. We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
<br />
=== July 2013 Responses ===<br />
<br />
* [https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGR1TmZLZnJ1RThHRDcwMDJRaXZicFE&output=html CA Responses to July 2013 Communication]<br />
<br />
== January 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by January 31, 2013. <br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by January 31, 2013, with your response to these action items. A compiled list of CA responses to the following action items will be published.<br />
<br />
1) Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations. <br />
<br />
Version 2.1 of Mozilla’s CA Certificate Policy is in final review, and will be ratified and published in Q1 of 2013. There are changes to the policy that may impact your current operations, so we encourage you to review the changes that are indicated in red or bold text here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html<br />
<br />
There will be a transition period for CAs to bring existing customers into compliance with the new policy, as described here:<br />
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1<br />
<br />
Please respond to this action item with one of the following:<br />
* a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.<br />
* b) The proposed changes to Mozilla’s CA Certificate Policy impact our CA operations, but we will be able to complete the transition within the allotted time frame.<br />
* c) We will not be able to update our CA operations to comply with the proposed version 2.1 of Mozilla’s CA Certificate Policy within the allotted time frame, because <insert reason(s)>. We plan to meet the new requirements by <insert date>.<br />
<br />
2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements.<br />
<br />
The CA/Browser Forum (http://www.cabforum.org) released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which became effective on July 1, 2012. It is our expectation that as of January 2013 CA issuance of SSL certificates will be audited against these Baseline Requirements as well as the acceptable audit criteria that are listed in Mozilla’s CA Certificate Policy.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.<br />
* b) Not applicable, because we do not issue SSL certificates.<br />
* c) We are working towards compliance with the CA/Browser Forum’s Baseline Requirements, but we need to complete <insert list of tasks>. We plan to have this completed by <insert date>.<br />
<br />
3) Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit.<br />
<br />
Due to the recent incident in which a mis-issued intermediate certificate was found (https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates), we are concerned that CAs may have responded to our last communication based on their policies, rather than checking their certificate databases. Therefore, we request that you scan your certificate database and inform Mozilla if you find any un-expired intermediate certificates in your CA hierarchy that should not be trusted. In your reply, please attach all such intermediate certificates, even if you have already revoked them.<br />
<br />
While you are scanning your certificate databases to ensure that all certificates with basicConstraints:CA:TRUE have been issued in accordance with your CPS, please also check for compliance with the following practices.<br />
* All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.<br />
* All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.<br />
* All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration).<br />
* All end-entity certificates with RSA key sizes smaller than 2048 bits expire no later than December 2013.<br />
* Certificates are not issued with sequential serial numbers. If it is found that certificates have been issued with contiguous serial numbers, then the subject of those certificates must contain unpredictable data that is not under the control of the certificate subscriber.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* b) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
* c) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* d) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
<br />
4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name.<br />
<br />
The CA/Browser Forum’s Baseline Requirements state: <br />
“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 Server 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.”<br />
<br />
This practice is being eliminated for security reasons, so we encourage all CAs to begin working with their customers to transition to alternative arrangements, and to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names as soon as possible rather than waiting until the deadline.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names.<br />
* b) We plan to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names by <insert date>.<br />
<br />
5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it. We expect this website to endure for the lifetime of the root, or until you notify us of an alternative URL. The website does not need to support high traffic loads or have greater than 99% uptime.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson, <br />
Module Owner of Mozilla's CA Certificates Module <br />
<br />
=== January 2013 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dHdISmM3c05tb1dMQjlJclJqS21QNmc&output=html CA Responses to January 2013 Communication] -- Contains two spreadsheets: "Action Item Responses" and "Test Website URLs".<br />
<br />
== February 2012 ==<br />
<br />
Subject: Mozilla Communication: Action requested by March 2, 2012<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Please reply by March 2, 2012, to confirm completion of the following actions or state when these actions will be completed.<br />
<br />
1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012. For each subordinate CA that is revoked, send me:<br />
* a) The certificate that signed the subCA. If it is a root certificate in NSS, then the root certificate's subject and SHA1 fingerprint.<br />
* b) The Serial Number of the revoked certificate.<br />
* c) The CRL that contains the serial number of the revoked certificate.<br />
<br />
As a CA in Mozilla’s root program you are ultimately responsible for certificates issued by you and any intermediate CAs that chain up to your roots. After April 27, 2012, if it is found that a subordinate CA is being used for MITM, we will take action to mitigate, including and up to removing the corresponding root certificate. Based on Mozilla’s assessment, we may also remove any of your other root certificates, and root certificates from other organizations that cross-sign your certificates.<br />
<br />
I am planning to publish a compiled list of CA responses to all of the action items in this communication. Therefore, I recommend responding to action item #1 with one of the following choices:<br />
* a) Does not apply, because we do not issue subCA certificates to third parties.<br />
* b) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
* c) We are reviewing all of our subCAs and will take the necessary action by <date>. <br />
* d) We have revoked such subCA certificates, and here is the requested information.<br />
* e) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM. ''(Note: This option was added after the communication was sent.)''<br />
<br />
2) If you issue subordinate CAs to third parties or your CP/CPS permits you to do so in the future, please add a statement to your CP/CPS committing that you will not issue a subordinate certificate that can be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control. Send me the URL to the updated document(s) and the impacted sections or page numbers. <br />
<br />
3) Please scan all of your EV SSL certificates and revoke any that do not meet the EV requirements. This includes, but is not limited to maximum validity period of the certificate, subject naming, minimum key sizes, required extensions, and maximum expiration time of OCSP responses.<br />
<br />
4) Certificates chaining to root certificates in Mozilla’s root program should not have MD5 algorithms or RSA keys shorter than 1024 bits long. Please scan the certificates chaining to your root certificates in NSS, and revoke any certificates that contain small key sizes or MD5 algorithms. <br />
<br />
5) The CA/Browser Forum has released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which is available here: http://www.cabforum.org/. Discussions are in progress in the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate Policy to add a requirement that CAs also meet these baseline requirements for issuance of SSL/TLS certificates. Please contribute to the discussions in the mozilla.dev.security.policy forum, and update your operations and documentation as needed to meet the baseline requirements by the effective date of July 1, 2012.<br />
<br />
The currently proposed updates to Mozilla’s CA Certificate Policy are here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== February 2012 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGxsWlZEdGFDaW9JTlNTUGxBNWhqSlE&output=html CA Responses] -- spreadsheet of the responses to the action items of the CA Communication that was sent on February 17, 2012.<br />
<br />
Response Key:<br />
* IP = "In Progress"<br />
* ? = I need further clarification on the response<br />
* N/A = "Not Applicable"<br />
** N/A for Action #2 means that the CP/CPS does not allow for externally-operated subCAs.<br />
** N/A for Action #3 means that the CA is not issuing EV certs under the roots included in NSS.<br />
* Responses to action #1 can be one or more of the following. If option C is listed, there is also a date by which the CA plans to complete their investigation and provide further information.<br />
** A) Does not apply, because the CA does not have externally-operated subCAs chaining to roots in NSS.<br />
** B) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
** C) The CA is reviewing all of their subCAs and will take the necessary action by <date>.<br />
** D) The CA has revoked such subCA certificates, and provided the requested information.<br />
** E) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
<br />
== September 2011 ==<br />
<br />
Subject: Mozilla Communication: Immediate action requested<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Mozilla recently removed the DigiNotar root certificate in response to their failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates (https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up). If you ever have reason to suspect a security breach or mis-issuance has occurred at your CA or elsewhere, please contact security@mozilla.org immediately.<br />
<br />
Please confirm completion of the following actions or state when these actions will be completed, and provide the requested information no later than September 16, 2011:<br />
<br />
1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs.<br />
<br />
2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included<br />
<br />
3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance.<br />
<br />
4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked.<br />
<br />
5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either:<br />
<br />
a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical)<br />
<br />
OR<br />
<br />
b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public 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 subordinate CA's internal operations.<br />
<br />
Each action requested above applies both to your root and to these third parties.<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your participation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== April 2011 ==<br />
<br />
Subject: Mozilla Communication: Policy Discussions are in Progress that may Impact Your CA<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to three important items that we would like to bring to your attention.<br />
<br />
1) The CA/Browser Forum has published a final draft of the document "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." We are now hosting a discussion about this document in the mozilla.dev.security.policy forum. For more information, see http://cabforum.org/. <br />
The document is here: http://cabforum.org/Baseline_Requirements_Draft_30b.pdf<br />
<br />
Mozilla supports the CA/Browser Forum’s efforts in this area. After version 1.0 of the CA/Browser Forum’s Baseline Requirements document is published, we will have a discussion to add a requirement to the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/) that CAs include the CA/Browser Forum Baseline Requirements in their policies, practices, and audits. Therefore, we urge you to review the draft of the Baseline Requirements, assessing the impact to your CA policies and practices, and participate in the current discussions about these requirements. The CA/Browser Forum has set the duration of this discussion to 45 days from April 11.<br />
<br />
2) Mozilla has begun discussions about the Phase 2 items to be considered for updating the Mozilla CA Certificate Policy, https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. The current discussions are focused on RAs and Subordinate CAs. We recommend that you monitor and contribute to these discussions so that you are aware of how the potential changes to the Mozilla CA Certificate Policy may impact you.<br />
<br />
3) As per previous communications, we will implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== February 2011 ==<br />
<br />
Subject: Mozilla Communication: Version 2.0 of Mozilla CA Certificate Policy has been published<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla has ratified and published Version 2.0 of the Mozilla CA Certificate Policy. <br />
<br />
The new policy is here:<br />
http://www.mozilla.org/projects/security/certs/policy/ <br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than August 8, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. Now that this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== January 2011 ==<br />
<br />
Subject: Mozilla Communication: Major Pending Update to Mozilla CA Certificate Policy<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla is preparing to update the Mozilla CA Certificate Policy. The forthcoming changes will come in multiple phases, and the first phase is nearly complete. Discussion about the first phase of changes has proceeded for several months in the mozilla.dev.security.policy forum. Version 2.0 of the policy, reflecting the first phase of updates, is now under final review. Mozilla expects it to be ratified by January 31, 2011.<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than April 30, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
The current policy (version 1.2) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/<br />
<br />
The new policy (version 2.0) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/<br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945#c3<br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. After this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== October 2010 ==<br />
<br />
Subject: Mozilla Communication to CAs regarding Policy updates, October 2010<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to five important points that we would like to bring to your attention.<br />
<br />
1) Mozilla has started a project to update the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/). The proposed changes may impact the operation of your root certificates that are included in NSS. Therefore, we request that all CAs participate in the discussions, which will be held in the Mozilla.dev.security.policy forum, http://www.mozilla.org/about/forums/#dev-security-policy. For information about the potential changes, please see https://wiki.mozilla.org/CA:CertPolicyUpdates.<br />
<br />
2) As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must provide an OCSP capability for end-entity certificates that are issued after Dec 31, 2010. Mozilla is considering technical ways to enforce this OCSP requirement such that if Firefox cannot obtain a valid response from the OCSP responder, then the certificate will not be given EV treatment. We are considering requiring the end-entity certificate to provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23<br />
Additionally, we urge all CAs to provide OCSP for all certs, even when they are not EV.<br />
<br />
3) We expect that all new certificates contain randomness (preferably in the serial number), especially when using the SHA-1 hash function or an RSA key size smaller than 2048 bits. For more information, please see http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period and serial number prediction”, and section 7, “Countermeasures.”<br />
<br />
4) As per the NIST guidelines, it is our expectation that all CAs are transitioning from issuing certs with RSA key sizes smaller than 2048 bits. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
5) We are planning to implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certs. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== May 2010 ==<br />
<br />
Subject: Mozilla Communication: Acceptable Addresses for Domain Control Validation<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to some changes that we are proposing to make to Mozilla’s CA Certificate Policy.<br />
<br />
Section 7 of the Mozilla CA Certificate Policy states: “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;”<br />
<br />
Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. Offering too many options for the email address prefix increases the risk of issuing a certificate to a subscriber who does not own/control the domain. Therefore, the list of email address prefixes should be limited.<br />
<br />
Mozilla is proposing to restrict the set of verification addresses that may be used for domain validation to the following list or a subset of it. Mozilla’s goal is to strike a balance between flexibility and safety.<br />
<br />
Accepted addresses for domain validation challenge-response email:<br />
* root@domain<br />
* admin@domain<br />
* administrator@domain<br />
* webmaster@domain<br />
* hostmaster@domain<br />
* Plus any address listed in the contact fields of the domain's WHOIS record.<br />
<br />
We hope that this restriction, when implemented consistently across CAs, will not cause discrimination or hardship. We are seeking feedback on whether this is the case. We invite you to contribute your feedback to a discussion about this new restriction in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.<br />
<br />
http://www.mozilla.org/community/developer-forums.html<br />
https://lists.mozilla.org/listinfo/dev-security-policy<br />
news://news.mozilla.org/mozilla.dev.security.policy<br />
<br />
The discussion thread is called “Domain Control validation” and “Acceptable Addresses for Domain Control Validation”.<br />
<br />
We have also added this information to our wiki page:<br />
https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs<br />
<br />
We look forward to your contributions to this discussion.<br />
<br />
Regards,<br />
Kathleen Wilson<br />
<br />
== November 2009 ==<br />
<br />
Subject: Mozilla Communication: SSL certificates issued to internal domain names <br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla I am contacting you in regards to root certificates that you currently have included by default in Mozilla products, such as the Firefox browser. <br />
<br />
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. <br />
<br />
Section 7 of Mozilla’s CA Certificate Policy states that CAs need to take “reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate.” There are different interpretations as to what this means in regards to internal domain names such as non-valid TLDs, hostnames, and IP addresses. However, there is consensus that there are problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks. Mozilla is currently discussing whether the CA Certificate Policy should be updated to add more explicit requirements on this practice, or even to disallow it altogether.<br />
<br />
In the light of the current situation, Mozilla requests that you take the following actions.<br />
<br />
1) Perform an internal audit to look for certificates that have been issued within your CA hierarchy which have .int domain names in the Common Name and/or as DNS Names in the subjectAlternativeName. For each of these certificates, check to see if the certificate subscriber owns/controls that domain name, and revoke the certificate if they do not own/control that domain name.<br />
<br />
2) Review your controls/procedures (both internally and your RAs) for correct identification of internal and external domain names and verification that subscribers own/control the domain name to be included in their certificate. Please refer to these documents:<br />
a) Section 7 of Mozilla’s CA Certificate Policy<br />
(http://www.mozilla.org/projects/security/certs/policy/)<br />
b) https://wiki.mozilla.org/CA:Recommended_Practices<br />
c) https://wiki.mozilla.org/CA:Problematic_Practices<br />
<br />
Mozilla also recommends that you <br />
1) Update your training procedures to ensure that all validation staff are aware of this situation. <br />
2) Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates.<br />
3) Maintain your own list of ICANN approved TLDs that are eligible to be used for domains in certificates issued within your CA hierarchy. If a new TLD is created by IANA, make an explicit decision whether or not to add the new TLD to your list.<br />
http://www.icann.org/en/registries/top-level-domains.htm<br />
<br />
Mozilla strongly encourages you to take prompt action in order to ensure the continued security and trust-ability of your CA service. <br />
<br />
Kathleen Wilson</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Communications&diff=1247830CA/Communications2023-09-02T23:48:26Z<p>Kathleen Wilson: fixed typo</p>
<hr />
<div>The following are communications that have been sent to Certification Authorities participating in [[CA | Mozilla's root program.]] If you have questions regarding these communications, please first review related discussions in the Mozilla dev-security-policy forum. If your questions cannot be answered in that forum, then please send email to certificates@mozilla.org.<br />
<br />
== August 2023 CA Communication and Survey ==<br />
The purpose of this communication and survey is to ensure that CA operators are aware of and prepared to comply with changes to the Mozilla Root Store Policy (MRSP), which we plan to publish soon as version 2.9 with an effective date of September 1, 2023.<br />
<br />
The most significant changes to v2.9 of MRSP are:<br />
# Retirement of Older Root CA Certificates <br />
#* https://wiki.mozilla.org/CA/Root_CA_Lifecycles<br />
# Compliance with the CABF’s S/MIME BRs <br />
#* https://wiki.mozilla.org/CA/Transition_SMIME_BRs<br />
# Security Vulnerability Reporting<br />
#* https://wiki.mozilla.org/CA/Vulnerability_Disclosure<br />
# Removed duplication with CCADB Policy regarding Audit Requirements<br />
#* https://www.ccadb.org/policy<br />
# Annual Submission of CCADB Compliance Self-Assessment<br />
#* https://www.ccadb.org/cas/self-assessment<br />
# Elimination of SHA-1<br />
<br />
Communication and Survey: <br />
https://docs.google.com/document/d/1ieXSt3rJyOSopJnDp4wFGSugpk6pt5pJFJ55rkpb6Ks/edit?usp=sharing <br />
<br />
Survey Responses:<br />
<br />
== February 2023 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s Root Store Policy (MRSP) was recently updated to version 2.8.1 with an effective date of February 15, 2023, https://github.com/mozilla/pkipolicy/pull/265/files. Version 2.8.1 contains several clarifications and minor changes that may affect your organization. You need to be aware of these clarifications and changes to ensure your continued compliance with the MRSP. The following are summaries only of the actual language in the MRSP, and in the event of any conflicting interpretation, the MRSP takes precedence over these summaries:<br />
<br />
* You are required to follow and be aware of discussions in both the Mozilla dev-security-policy forum, https://groups.google.com/a/mozilla.org/g/dev-security-policy, and the CCADB Public List, https://groups.google.com/a/ccadb.org/g/public;<br />
* Your CP, CPS, or combined CP/CPS MUST clearly explain your CA’s domain validation procedures and indicate which subsection of section 3.2.2.4 of the CA/Browser Forum’s Baseline Requirements you are complying with;<br />
* Your CP, CPS, or combined CP/CPS MUST be updated at least every 365 days (more often is expected), and it must be reported in the CCADB in a “timely manner”, and failure to do either of these things will require that you file an incident report in Bugzilla;<br />
* You MUST maintain links to all historic versions of each CP, CPS, or combined CP/CPS from the creation of included CA certificates until such certificate hierarchies are no longer trusted by the Mozilla root store, and if your CA certificate was included by Mozilla before December 31, 2022, then you still must maintain links for “reasonably available historic versions” of your CPs, CPSes, or combined CP/CPSes; and<br />
* In the CCADB, if you elect to publish a JSON array of partial CRLs (rather than the full CRL), then the JSON Array of Partitioned CRLs must contain a critical Issuing Distribution Point extension, which shall include a URI whose value is derived from either the URI as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5) or the URL included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA.<br />
<br />
Finally, participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard user security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you very much for your continued cooperation in this pursuit.<br />
<br />
Regards,<br />
Ben Wilson<br />
Mozilla CA Program Manager<br />
<br />
<br />
<br />
== May 2022 CA Communication and Survey ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a058Z000013UmsDQAS Read-only copy of May 2022 CA Communication and Survey]<br />
** This link is '''Read Only'''. To submit your responses, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2022 CA Communication and Survey' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
=== May 2022 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00160,Q00161 Responses to Item 1] -- Compliance with MRSP v. 2.8<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00162,Q00163 Responses to Item 2] -- "Incidents" include audit findings<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00164,Q00165 Responses to Item 3] -- Auditor membership in ACAB'c and WebTrust<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00166,Q00167,Q00168 Responses to Item 4] -- Online Archival of CPs and CPSes<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00169,Q00170 Responses to Item 5] -- Full CRLs for Intermediate TLS CAs in CCADB<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00171,Q00172 Responses to Item 6.1] -- Sunsetting of SHA1 for S/MIME Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00173,Q00174 Responses to Item 6.2] -- Sunsetting of SHA1 for Other Types of Signing<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00175,Q00176 Responses to Item 7] -- Publicly Disclose Intermediate CA Certificates capable of Issuing TLS or S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00177,Q00178 Responses to Item 8] -- Misissuance of Certificate Transparency Precertificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00179,Q00180,Q00181 Responses to Item 9] -- CRL Revocation Reasons for TLS Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00182,Q00183 Responses to Item 10] -- Public Review of Unconstrained Externally-Operated Subordinate CAs<br />
<br />
== February 2022 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla is engaged in policy review discussions to sunset the use of SHA1 for signing by CAs of CRLs, OCSP responses, and SMIME certificates.<br />
See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/CnVjV-bFcyI/m/TFuWOy2BAwAJ<br />
<br />
(Server certificate signing is governed by the Baseline Requirements, and effective June 1, 2022, OCSP responses related to server certificates cannot be signed with SHA1.)<br />
<br />
One proposal is to remove SHA1 from the list of allowed signing algorithms altogether, but before we do this, I would like your proposed sunset dates for the different types of SHA1 signing you might currently perform--SMIME certificates, ARLs/CRLs, and OCSP responses for SMIME certificates.<br />
<br />
Please participate in this important topic, which is already underway on the Mozilla dev-security-policy list. Let us know about your specific concerns and hurdles that would need to be overcome.<br />
(Some CAs have expressed willingness to quickly convert over to SHA256, while others have expressed that it is not a simple task and will require additional development work.)<br />
<br />
Thanks,<br />
Ben Wilson (bwilson@mozilla.com)<br />
Mozilla Root Store Program<br />
<br />
== April 2021 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a054o00000EL1Fo Read-only copy of April 2021 CA Communication]<br />
** This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br><br />
<br><br />
Mozilla’s Root Store Policy was recently updated to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ version 2.7.1] with an effective date of 1 May 2021. This version contains [https://github.com/mozilla/pkipolicy/pull/223 several changes] that may affect your organization and the auditors who evaluate your PKI. These changes require you to take action to ensure your continued compliance. <br />
<br><br><br />
Please review version 2.7.1 of [https://www.mozilla.org/projects/security/certs/policy/ Mozilla’s Root Store Policy] internally, and with your auditors as well. After you and your auditors have reviewed these new requirements, complete the April 2021 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your practices. Read all survey questions first before beginning to respond. <br />
<br><br><br />
To respond to this survey, [https://ccadb.org/cas/ log in to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 30-April-2021.<br />
<br><br><br />
A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Ben Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== April 2021 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00129,Q00142 Responses to Item 1] -- Review Version 2.7.1 of Mozilla's Root Store Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00131,Q00149,Q00143 Responses to Item 2] -- 398-day reuse period on domain/IP address validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00132,Q00144 Responses to Item 3] -- Clarification about EV Audit Requirements <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00133,Q00145 Responses to Item 4] -- Annual Audit Covering the CA Key Pair Lifecycle <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00136,Q00146 Responses to Item 5] -- Audit Team Qualifications<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00137,Q00147 Responses to Item 6] -- List of Incidents in Audit Reports<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00140,Q00150,Q00148 Responses to Item 7] -- Methods to Demonstrate Key Compromise<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00141,Q00157,Q00159 Responses to Item 8] -- Removal of Old Root CA Certificates (challenges and alternatives)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00156,Q00151,Q00158 Responses to Item 8 timelines] -- Timelines and strategies to replace old, non-BR compliant CA hierarchies and root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00152,Q00155,Q00153 Responses to Item 9] -- Audit Letter Validation on Intermediate Certificates<br />
<br />
== May 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J000042AUSv Read-only copy of May 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>This survey requests your input on current policy and upcoming policy changes that affect you as a participant in Mozilla's CA Certificate Program. <br />
<br><br />
<br>To respond to this survey, [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 31-May 2020. <br />
<br><br />
<br>A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br><br />
<br>Regards,<br />
<br>Kathleen Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== May 2020 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00099,Q00100 Responses to Item 1] -- Impact of COVID-19 Restrictions<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00101,Q00102, Responses to Item 2] -- Mozilla Root Store Policy version 2.7 Requirements and Deadlines <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00103,Q00104 Responses to Item 3] -- Reducing Maximum Validity Period for TLS Certificates <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107 Responses to Sub Item 3.1] -- Limit TLS Certificates to 398-day validity<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00108,Q00109,Q00110 Responses to Sub Item 3.2] -- Limit re-use of domain name and IP address verification to 398 days<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00111,Q00112 Responses to Item 4] -- CA/Browser Forum Ballot for Browser Alignment <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00113,Q00114,Q00115 Responses to Sub Item 4.1] -- CA/Browser Forum defined-policy OID in Subscriber Cert certificatePolicies<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00116,Q00117,Q00118 Responses to Sub Item 4.2] -- Byte-for-byte Identical Issuer and Subject Distinguished Names<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00119,Q00120,Q00121 Responses to Sub Item 4.3] -- Text-searchable PDF Audit Statements<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00122,Q00123,Q00124 Responses to Sub Item 4.4] -- OCSP Requirements<br />
<br />
== January 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003waNOW Read-only copy of January 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/ updated]. The 2.7 version went into effect on 1-January 2020. This version contains a [https://github.com/mozilla/pkipolicy/pull/199/files number of changes] that may affect your organization and will require you to take action to comply. Please review Mozilla’s updated Root Store Policy and complete the January 2020 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your Certificate Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘January 2020 CA Communication' survey. Please enter your response by 31 January 2020.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== January 2020 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00082,Q00083 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00084,Q00085,Q00098 Responses to Action 2] -- Update CP/CPS <br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00086,Q00087,Q00097 Responses to Action 3] -- Include EKUs in All End-entity Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00088,Q00089 Responses to Action 4] -- Ensure Audit Reports are Properly Formatted<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00090,Q00096,Q00091 Responses to Action 5] -- Resolve Audit Issues with Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00092,Q00093 Responses to Action 6] -- Incident Reporting<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00094,Q00095 Responses to Action 7] -- Compliance with BRs<br />
<br />
== November 2018 CA Communication (Underscores in dNSNames) ==<br />
On November 12, 2018, the following message was sent to all CAs in the Mozilla program, alerting them to CA/Browser Forum SC12 that established a brief sunset period for the use of underscore characters in dNSNames in publicly-trusted TLS certificates.<br />
<br /><br />
<br />
Dear Certification Authority,<br />
<br />
The CA/Browser Forum recently approved [1] a clarification to the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (BRs) that may affect you. Domain names containing underscore (“_”) characters are not permitted to be encoded as dNSName types in the subjectAlternativeName (SAN) field of BR-compliant certificates. This requirement derives from section 4.2.1.6 of RFC 5280 that the BRs require CAs to comply with by reference.<br />
<br />
Section 7.1.4.2.1 of the BRs will add the following language that clarifies the existing requirement and adds a short time in which CAs must discontinue the use of underscore characters in dNSNames:<br />
-----<br />
Prior to April 1, 2019, certificates containing underscore characters (“_”) in domain labels in dNSName entries MAY be issued as follows:<br />
* dNSName entries MAY include underscore characters such that replacing all underscore characters with hyphen characters (“-“) would result in a valid domain label, and;<br />
* Underscore characters MUST NOT be placed in the left most domain label, and;<br />
* Such certificates MUST NOT be valid for longer than 30 days.<br />
<br />
All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019.<br />
<br />
After April 30, 2019, underscore characters (“_”) MUST NOT be present in dNSName entries.<br />
-----<br />
This new language will go into effect on December 10, 2018 when the IPR review period for ballot SC12 [1] is completed. At that time, CAs must be prepared to stop issuing publicly-trusted TLS certificates containing the underscore character in any dNSName with validity periods of more than 30 days.<br />
<br />
As a participant in Mozilla's CA Certificate Program, we want you to be aware of this important change, and ask that you take any necessary steps to comply. No further action related to this change is requested at this time.<br />
<br />
Regards,<br />
<br />
Wayne Thayer<br />
Mozilla CA Program Manager<br />
<br />
[1] https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/<br />
<br />
=== November 2018 Responses ===<br />
* No survey was included in this CA Communication<br />
<br />
== September 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL Read-only copy of September 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'September 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/ updated]. The 2.6.1 version went into effect on 1-July, 2018. This version contains a number of changes that may affect your organization and will require you to take action to comply. This survey also contains information regarding other recent and upcoming changes that may affect your Certification Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘September 2018 CA Communication' survey. Please enter your response by 30-September 2018.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== September 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00068,Q00069 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00070,Q00071 Responses to Action 2] -- Update CP/CPS<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00072,Q00073 Responses to Action 3] -- Transition to Separate Intermediate Certificates for SSL and S/MIME<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00074,Q00075 Responses to Action 4] -- Ensure Audit Reports comply with Mozilla’s Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00076,Q00077 Responses to Action 5] -- Discontinue use of BR Validation Methods 3.2.2.4.1 and 3.2.2.4.5<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00078,Q00079 Responses to Action 6] -- Disclose Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00080,Q00081 Responses to Action 7] -- Submit TLS Certificates to CT Logs for Mozilla's CRLite<br />
<br />
== January 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mqMFN Read-only copy of January 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br /><br /><br />
2018 has already generated some important news for Certification Authorities, and as a result we are sending this message to ensure that every CA in the Mozilla program is aware of current events and impending deadlines.<br />
<br /><br /><br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.<br />
<br /><br /><br />
To respond to this survey, login to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Please enter your response by 9-February 2018.<br />
<br /><br /><br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br /><br /><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br /><br /><br />
Regards,<br /><br />
Wayne Thayer<br /><br />
Mozilla CA Program Manager<br /><br />
<br />
=== January 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00056,Q00057 Responses to Action 1] -- Disclose Use of Methods 3.2.2.4.9 or 3.2.2.4.10 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00058,Q00059 Responses to Action 2] -- Disclose Use of Methods 3.2.2.4.1 or 3.2.2.4.5 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00060,Q00061 Responses to Action 3] -- Disclose All Non-Technically-Constrained Subordinate CA Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00062,Q00063 Responses to Action 4] -- Complete BR Self Assessment<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00064,Q00065 Responses to Action 5] -- Update CP/CPS to Comply with version 2.5 of Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00066,Q00067 Responses to Action 6] -- Reduce SSL Certificate Validity Periods to 825 Days or Less by March 1, 2018<br />
<br />
== November 2017 CA Communication ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7 Read-only copy of November 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority, <br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, login to the [http://ccadb.org/cas Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Please enter your response by December 15, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be [[CA/Communications|automatically and immediately published]] by the CCADB system.<br />
<br />
Participation in [[CA|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== November 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00035,Q00036 Responses to Action 1] -- Full compliance with version 2.5 of [https://www.mozilla.org/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00037,Q00044 Responses to Action 2] -- non-technically-constrained intermediate certificates must be [http://ccadb.org/cas/intermediates disclosed in CCADB] within one week of creation. '''New requirements''' for [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#technically-constrained technical constraints on intermediate certificates issuing S/MIME certificates].<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00038,Q00045 Responses to Action 3] -- Annual updates via [http://ccadb.org/cas/updates CCADB Audit Cases]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00050,Q00051 Responses to Action 4] -- Reiterate [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#audit-parameters audit requirements] and '''penalty for incomplete audit statements'''<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00039,Q00046 Responses to Action 5] -- Perform a [[CA/BR_Self-Assessment|BR Self Assessment]]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00042,Q00048 Responses to Action 6] -- Provide tested email address for [https://ccadb.my.salesforce-sites.com/mozilla/CAInformationReport Problem Reporting Mechanism]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00040,Q00047 Responses to Action 7] -- Follow new developments and effective dates for [http://tools.ietf.org/html/rfc6844 Certification Authority Authorization (CAA)]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00052,Q00053 Responses to Action 8] -- Check [https://groups.google.com/d/msg/mozilla.dev.security.policy/4kj8Jeem0EU/GvqsgIzSAAAJ issuance of certs to .tg domains] from October 25 to November 11, 2017.<br />
<br />
== May 2017 - Announcing CCADB Changes ==<br />
<br /><br />
Subject: Common CA Database (CCADB) changes May 19-21, 2017<br />
<br /><br /><br />
Message:<br /><br /><br />
Dear Certification Authority,<br />
<br /><br />
<br /><br />
The Common CA Database (CCADB) will undergo the following changes this weekend, May 19 to May 21. During this time, the old URLs listed below will stop working, and there will be some time when the CCADB is in read-only mode.<br />
<br /><br />
<br /><br />
On May 19 the following three breaking changes are planned, meaning that the old URLs will no longer work. Any links or bookmarks to these URLs will need to be updated. After these changes are made, I will also update Mozilla's wiki pages to point to the new URLs.<br />
<br /><br />
<br /><br />
1) The CA login page and the domain CAs see when they are logged into the CCADB will change.<br />
<br /><br />
https://mozillacacommunity.force.com/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb.force.com/<br />
<br /><br />
<br /><br />
2) The links to reports that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/CA/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/mozilla/<br />
<br /><br />
<br /><br />
3) The links to CA communication responses that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/Communications<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/Surveys<br />
<br /><br />
<br /><br />
Then on May 21 between 12am and 4am PDT, the CCADB will be in read-only mode while Salesforce performs an instance refresh to upgrade the infrastructure supporting the CCADB instance in their data centers.<br />
<br /><br />
<br /><br />
Regards,<br />
<br /><br />
Kathleen<br />
<br />
== April 2017 ==<br />
<br />
Note: The deadline to reply to this survey has [https://groups.google.com/d/msg/mozilla.dev.security.policy/03rdTdnm7iw/NQUHmWOcEAAJ been extended] by one week, to May 5, 2017.<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000003WrzBC Read-only copy of April 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [https://ccadb.force.com/CustomLogin login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA:IncludedCAs|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, [https://mozillacacommunity.force.com/CustomLogin login to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Please enter your response by April 28, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br />
In addition to responding to the action items in this survey, we are instituting a program requirement that you follow discussions in the [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] forum, which includes discussions about upcoming changes to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy], questions and clarification about policy and expectations, root certificate [[CA|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] or other program requirements. You are not required to contribute to those discussions, only to be aware of them. However, we hope you will participate and help shape the future of Mozilla's CA Certificate Program.<br />
<br />
Participation in [[CA:Overview|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== April 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [[CA:CommonCADatabase|Common CA Database]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00015,Q00030 Responses to Action 1] -- Domain Validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 2 and Action 10] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00022,Q00029 Responses to Action 3] -- Updated Mozilla CA Certificate Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00017,Q00031 Responses to Action 4] -- Audit Statements, annual updates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00018,Q00032 Responses to Action 5] -- Audit Statement Contents<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00021,Q00033 Responses to Action 6] -- Qualified Audit Statements<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00019 Responses to Action 7] -- BR Compliance Bugs<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 Responses to Action 8] -- Confirm Completion of Previous Commitments<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00027 Responses to Action 9] -- Registration Authorities<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 10 and Action 2] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00023 Responses to Action 11] -- Certification Authority Authorization (CAA)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00028 Responses to Action 12] -- Problem Reporting Mechanism<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00024 Responses to Action 13] -- SHA-1 and S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00034 Responses to Action 14] -- Certificate Validity Periods in TLS/SSL Certs<br />
<br />
== March 2016 ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000000iHdtx Read-only copy of March 2016 CA Communication]<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program, by April 22, 2016.<br />
<br />
To respond to this survey, please login to the [[CA:SalesforceCommunity|CA Community in Salesforce]], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'March 2016 CA Communication' survey. Please enter your response by April 22, 2016. <br />
<br />
A compiled list of CA responses to the survey action items will be [[CA:Communications#March_2016_Responses|automatically and immediately published]] by Salesforce.<br />
<br />
In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the [https://groups.google.com/forum/#!forum/mozilla.dev.security.policy mozilla.dev.security.policy] forum, which includes discussions about [[CA:CertificatePolicyV2.3|upcoming changes to Mozilla's CA Certificate Policy]], questions and clarification about policy and expectations, root certificate [[CA:Schedule|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements]. Your contributions to the discussions will help shape the future of [[CA:Overview|Mozilla's CA Certificate Program]].<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Mozilla CA Program Manager<br />
<br />
=== March 2016 Responses ===<br />
<br />
The following links are automatically generated from data in the [[CA:SalesforceCommunity|CA Community in Salesforce]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommSummaryReport?CommunicationID=a05o000000iHdtx CA Responses to March 2016 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00001,Q00013 Responses to Action #1a] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00002,Q00014 Responses to Action #1b] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 Responses to Action #1c] -- SHA-1 Deprecation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 Responses to Action #2] -- Entering intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00005 Responses to Action #3] -- Entering revoked intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00006&QuestionIdForText=Q00007 Responses to Action #4] -- [[SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix|Removing workarounds]] to compatibility issues that were encountered involving certificates that did not conform to the Baseline Requirements. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00008 Responses to Action #5] -- Plans to remove old/retired root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00009 Responses to Action #6] -- Confirmation of understanding that all certificates, including test certificates, must conform to stated policies<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00012 Responses to Action #7] -- [[CA:RootTransferPolicy|Mozilla's Root Transfer Policy]]<br />
<br />
== May 2015 ==<br />
<br />
Dear Certification Authority, <br />
<br />
This email requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by June 5, 2015, with your response to the action items by clicking on the survey link below. A compiled list of CA responses to these action items will be published. <br />
<br />
Certification Authority: <CA Account Name><br />
<br />
Your Survey Link: <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/TakeSurvey?id=a04o000000M89RCAAZ&cId=&caId=none Survey Link] -- '''IMPORTANT: CA's do NOT use the link in this wiki page! This link will NOT record your response. Please use the link that was emailed to you.'''<br />
<br />
Please use the above link to read and respond to the action items. Note that you may access the above link multiple times to update your responses.<br />
<br />
Additionally, we plan to update Mozilla's CA Certificate Policy soon, and will be discussing proposed policy updates in the mozilla.dev.security.policy forum, https://www.mozilla.org/en-US/about/forums/#dev-security-policy. We encourage you to monitor the discussions to see how the updates will impact you, and your participation in the discussions will help shape the policy updates.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, <br />
Mozilla <br />
CA Program Manager<br />
<br />
=== May 2015 Responses ===<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationSummaryReport?CommunicationId=a04o000000M89RCAAZ CA Responses to May 2015 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%233:%20After%20January%201,%202016 Responses to Action #3] -- SHA-1 Deprecation Plans<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%234:%20Workarounds%20were%20implemented Responses to Action #4] -- Removing workarounds implemented to allow mozilla::pkix to handle the things listed here https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%235:%20We%20wish%20to%20understand%20what%20support Responses to Action #5] -- IPv6 survey<br />
<br />
== May 2014 ==<br />
<br />
Subject: Mozilla Communication: Action requested by May 30, 2014<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by May 30, 2014, with your response to these action items. A compiled list of CA responses to the following action items will be published. <br />
<br />
CA Certificate Inclusion Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/<br />
<br />
CA Certificate Maintenance Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/<br />
<br />
Spreadsheet of included root certificates: http://www.mozilla.org/about/governance/policies/security-group/certs/included/<br />
<br />
1) Ensure that Mozilla’s [http://www.mozilla.org/about/governance/policies/security-group/certs/included/ spreadsheet of included root certificates] has the correct link to your most recent audit statement, and that the date of the audit statement is correct. As per [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/ Mozilla's CA Certificate Maintenance Policy], we require that all CAs whose certificates are distributed with our software products provide us an updated statement annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties. To notify us of an updated statement of attestation, send email to certificates@mozilla.org or [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates submit a bug report] into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "mozilla.org" product.<br />
If you are not proactively sending Mozilla your updated audit statements, please create a process to do so.<br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent audit statement, and the audit statement date is correct.<br />
* B) Here is the most recent audit statement for our certificates that are included in Mozilla’s CA program: <insert link here> <br />
* C) We plan to send Mozilla our current audit statement by <insert date here>.<br />
* D) We do not have a current audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
2) Send Mozilla the link to your most recent [https://cabforum.org/about-the-baseline-requirements/ Baseline Requirements] audit statement. Details about Mozilla's audit requirements are listed in section 11 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy]. The Baseline Requirements audit statement should also be proactively sent to Mozilla each year, along with the other audit statements as described in action #1. <br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent Baseline Requirements audit statement.<br />
* B) Here is the most recent Baseline Requirements audit statement for our certificates that are included in Mozilla’s CA program: <insert link here>. <br />
* C) We plan to send Mozilla our current Baseline Requirements audit statement by <insert date here and explain reason for delay>.<br />
* D) The websites (SSL/TLS) trust bit is not enabled for our certificates that are included in Mozilla's CA program.<br />
* E) We do not have a current Baseline Requirements audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
3) Test Mozilla's new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed. <br />
The new Certificate Verification library (mozilla::pkix) was announced here: https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ .<br />
Mozilla::pkix includes some changes in support of current best practices and policies, as listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes .<br />
How to test: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing .<br />
<br />
Please respond with one of the following: <br />
* A) We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix.<br />
* B) We have found the following issues when testing certificates in our CA hierarchy with mozilla::pkix. <descriptions or Bugzilla bug numbers, related URLs and/or certificates><br />
* C) We are testing certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and plan to send Mozilla our results by <insert date here, must be before June 30, 2014>.<br />
<br />
4) Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix<br />
<br />
Please respond with one of the following: <br />
* A) We have not and will not issue certificates with any of the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page.<br />
* B) We have previously issued certificates with the following problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page: <list the problems that needed to be fixed>. The last of those certificates expire <insert dates here, one date per problem>. We will not issue new certificates with the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page as of this date: <date when your operations will be updated, no later than June 30, 2014><br />
<br />
5) Send Mozilla information about your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, as per Items #8, 9, and 10 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy].<br />
<br />
Please provide a URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, and contains the required information according to section 10 of Mozilla's CA Certificate Inclusion Policy. If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificates" component of the "mozilla.org" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates)<br />
<br />
Additionally, please respond with one of the following: <br />
* A) All subordinate CA certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy.<br />
* B) We request an extension for the following specific subordinate CA certificates, because these subordinate CAs need more time to transition from their legacy systems to their new CA hierarchy: <list of issuer hash, issuer public key hash, and certificate serial number>. For each subordinate CA who needs to operate in their legacy design a little longer, the attached document explains the reason that continued operation is needed and their target date for resolution. <attach document(s) to response><br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== May 2014 Responses ===<br />
<br />
[https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml CA Responses to May 2014 Communication]<br />
<br />
== July 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by August 16, 2013<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s CA Certificate Policy has been updated with a few important changes. This update was motivated by security concerns regarding ICANN granting applied-for new gTLD strings. Additionally, we want to make it very clear that there will be serious consequences if it is found that a CA has knowingly or intentionally mis-issued certificates chaining to trust anchors in Mozilla’s program.<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of applications.<br />
<br />
Please carefully review the following wiki page for information about the changes introduced in version 2.2 of Mozilla’s CA Certificate Policy.<br />
<br />
https://wiki.mozilla.org/CA:CertificatePolicyV2.2<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by August 16, 2013, with your response to the following action items. <br />
<br />
1) Update your CA operations and policies to include the CA/Browser Forum’s Baseline Requirement #11.1.4 regarding new gTLD domains, and subscribe to ICANN’s new gTLD Registry Agreement notification mailing list at: https://mm.icann.org/mailman/listinfo/gtldnotification<br />
<br />
Please respond with one of the following:<br />
* A) No action required, because we have not and will not issue SSL certificates with internal or private domain names chaining up to root certificates that are included in Mozilla’s program.<br />
* B) We have issued or may issue SSL certificates with internal or private domain names that chain up to root certificates that are included in Mozilla’s program, so we are implementing Baseline Requirement #11.1.4, and will subscribe to ICANN’s notification service regarding applied-for-gTLD strings. We plan to have this completed by September 16, 2013.<br />
* C) We have already implemented Baseline Requirement #11.1.4, and have subscribed to ICANN’s notification service regarding applied-for-gTLD strings.<br />
<br />
2) Review your CA operations and customers to ensure that there are no certificates chaining up to your trust anchors that are included in Mozilla’s program that may be used for MITM or “traffic management” of domain names or IP addresses that the certificate holder does not own or control. [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla’s CA Certificate Enforcement Policy] has been updated to make it clear that Mozilla will not tolerate this use of publicly trusted certificates. <br />
<br />
Please respond with:<br />
* “We have reviewed Mozilla’s updated CA Certificate Enforcement Policy and understand that knowing or intentional mis-issuance of a certificate is expressly against Mozilla’s CA Certificate Policy and could result in removal of all of our certificates from Mozilla’s products.”<br />
<br />
3) Ensure that your CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current, including links to the CP/CPS documents, audit statements, and test websites. Mozilla will be adding a column to this spreadsheet to indicate the date of the most recent audit statement for each root certificate.<br />
<br />
http://www.mozilla.org/projects/security/certs/included/index.html<br />
<br />
Please respond with one of the following:<br />
* A) Our CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current for all of our included certificates.<br />
* B) Here is the current information for our certificates that are included in Mozilla’s program: <insert data here><br />
<br />
4) Complete the action items from Mozilla’s January CA Communication.<br />
* https://wiki.mozilla.org/CA:Communications#January_10.2C_2013<br />
* https://wiki.mozilla.org/CA:Communications#January_2013_Responses<br />
<br />
Please respond with one of the following:<br />
* A) Our recorded response to the January CA Communication is complete and correct.<br />
* B) We have the following updated status for our response to the January CA Communication: <insert data here><br />
<br />
5) Follow discussion about the changes to policy and code that Mozilla will be making in order to improve how revocation checking is handled in Firefox. Discussions will be held in the mozilla.dev.security.policy forum, and descriptions of the changes that will be considered for both policy and code will be provided here: https://wiki.mozilla.org/CA:ImprovingRevocation<br />
As part of this effort, Mozilla will be implementing a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker. More information will follow, and policy will be added soon to require CAs to send Mozilla revocation information. We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
<br />
=== July 2013 Responses ===<br />
<br />
* [https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGR1TmZLZnJ1RThHRDcwMDJRaXZicFE&output=html CA Responses to July 2013 Communication]<br />
<br />
== January 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by January 31, 2013. <br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by January 31, 2013, with your response to these action items. A compiled list of CA responses to the following action items will be published.<br />
<br />
1) Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations. <br />
<br />
Version 2.1 of Mozilla’s CA Certificate Policy is in final review, and will be ratified and published in Q1 of 2013. There are changes to the policy that may impact your current operations, so we encourage you to review the changes that are indicated in red or bold text here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html<br />
<br />
There will be a transition period for CAs to bring existing customers into compliance with the new policy, as described here:<br />
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1<br />
<br />
Please respond to this action item with one of the following:<br />
* a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.<br />
* b) The proposed changes to Mozilla’s CA Certificate Policy impact our CA operations, but we will be able to complete the transition within the allotted time frame.<br />
* c) We will not be able to update our CA operations to comply with the proposed version 2.1 of Mozilla’s CA Certificate Policy within the allotted time frame, because <insert reason(s)>. We plan to meet the new requirements by <insert date>.<br />
<br />
2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements.<br />
<br />
The CA/Browser Forum (http://www.cabforum.org) released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which became effective on July 1, 2012. It is our expectation that as of January 2013 CA issuance of SSL certificates will be audited against these Baseline Requirements as well as the acceptable audit criteria that are listed in Mozilla’s CA Certificate Policy.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.<br />
* b) Not applicable, because we do not issue SSL certificates.<br />
* c) We are working towards compliance with the CA/Browser Forum’s Baseline Requirements, but we need to complete <insert list of tasks>. We plan to have this completed by <insert date>.<br />
<br />
3) Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit.<br />
<br />
Due to the recent incident in which a mis-issued intermediate certificate was found (https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates), we are concerned that CAs may have responded to our last communication based on their policies, rather than checking their certificate databases. Therefore, we request that you scan your certificate database and inform Mozilla if you find any un-expired intermediate certificates in your CA hierarchy that should not be trusted. In your reply, please attach all such intermediate certificates, even if you have already revoked them.<br />
<br />
While you are scanning your certificate databases to ensure that all certificates with basicConstraints:CA:TRUE have been issued in accordance with your CPS, please also check for compliance with the following practices.<br />
* All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.<br />
* All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.<br />
* All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration).<br />
* All end-entity certificates with RSA key sizes smaller than 2048 bits expire no later than December 2013.<br />
* Certificates are not issued with sequential serial numbers. If it is found that certificates have been issued with contiguous serial numbers, then the subject of those certificates must contain unpredictable data that is not under the control of the certificate subscriber.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* b) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
* c) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* d) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
<br />
4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name.<br />
<br />
The CA/Browser Forum’s Baseline Requirements state: <br />
“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 Server 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.”<br />
<br />
This practice is being eliminated for security reasons, so we encourage all CAs to begin working with their customers to transition to alternative arrangements, and to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names as soon as possible rather than waiting until the deadline.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names.<br />
* b) We plan to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names by <insert date>.<br />
<br />
5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it. We expect this website to endure for the lifetime of the root, or until you notify us of an alternative URL. The website does not need to support high traffic loads or have greater than 99% uptime.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson, <br />
Module Owner of Mozilla's CA Certificates Module <br />
<br />
=== January 2013 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dHdISmM3c05tb1dMQjlJclJqS21QNmc&output=html CA Responses to January 2013 Communication] -- Contains two spreadsheets: "Action Item Responses" and "Test Website URLs".<br />
<br />
== February 2012 ==<br />
<br />
Subject: Mozilla Communication: Action requested by March 2, 2012<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Please reply by March 2, 2012, to confirm completion of the following actions or state when these actions will be completed.<br />
<br />
1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012. For each subordinate CA that is revoked, send me:<br />
* a) The certificate that signed the subCA. If it is a root certificate in NSS, then the root certificate's subject and SHA1 fingerprint.<br />
* b) The Serial Number of the revoked certificate.<br />
* c) The CRL that contains the serial number of the revoked certificate.<br />
<br />
As a CA in Mozilla’s root program you are ultimately responsible for certificates issued by you and any intermediate CAs that chain up to your roots. After April 27, 2012, if it is found that a subordinate CA is being used for MITM, we will take action to mitigate, including and up to removing the corresponding root certificate. Based on Mozilla’s assessment, we may also remove any of your other root certificates, and root certificates from other organizations that cross-sign your certificates.<br />
<br />
I am planning to publish a compiled list of CA responses to all of the action items in this communication. Therefore, I recommend responding to action item #1 with one of the following choices:<br />
* a) Does not apply, because we do not issue subCA certificates to third parties.<br />
* b) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
* c) We are reviewing all of our subCAs and will take the necessary action by <date>. <br />
* d) We have revoked such subCA certificates, and here is the requested information.<br />
* e) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM. ''(Note: This option was added after the communication was sent.)''<br />
<br />
2) If you issue subordinate CAs to third parties or your CP/CPS permits you to do so in the future, please add a statement to your CP/CPS committing that you will not issue a subordinate certificate that can be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control. Send me the URL to the updated document(s) and the impacted sections or page numbers. <br />
<br />
3) Please scan all of your EV SSL certificates and revoke any that do not meet the EV requirements. This includes, but is not limited to maximum validity period of the certificate, subject naming, minimum key sizes, required extensions, and maximum expiration time of OCSP responses.<br />
<br />
4) Certificates chaining to root certificates in Mozilla’s root program should not have MD5 algorithms or RSA keys shorter than 1024 bits long. Please scan the certificates chaining to your root certificates in NSS, and revoke any certificates that contain small key sizes or MD5 algorithms. <br />
<br />
5) The CA/Browser Forum has released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which is available here: http://www.cabforum.org/. Discussions are in progress in the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate Policy to add a requirement that CAs also meet these baseline requirements for issuance of SSL/TLS certificates. Please contribute to the discussions in the mozilla.dev.security.policy forum, and update your operations and documentation as needed to meet the baseline requirements by the effective date of July 1, 2012.<br />
<br />
The currently proposed updates to Mozilla’s CA Certificate Policy are here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== February 2012 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGxsWlZEdGFDaW9JTlNTUGxBNWhqSlE&output=html CA Responses] -- spreadsheet of the responses to the action items of the CA Communication that was sent on February 17, 2012.<br />
<br />
Response Key:<br />
* IP = "In Progress"<br />
* ? = I need further clarification on the response<br />
* N/A = "Not Applicable"<br />
** N/A for Action #2 means that the CP/CPS does not allow for externally-operated subCAs.<br />
** N/A for Action #3 means that the CA is not issuing EV certs under the roots included in NSS.<br />
* Responses to action #1 can be one or more of the following. If option C is listed, there is also a date by which the CA plans to complete their investigation and provide further information.<br />
** A) Does not apply, because the CA does not have externally-operated subCAs chaining to roots in NSS.<br />
** B) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
** C) The CA is reviewing all of their subCAs and will take the necessary action by <date>.<br />
** D) The CA has revoked such subCA certificates, and provided the requested information.<br />
** E) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
<br />
== September 2011 ==<br />
<br />
Subject: Mozilla Communication: Immediate action requested<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Mozilla recently removed the DigiNotar root certificate in response to their failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates (https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up). If you ever have reason to suspect a security breach or mis-issuance has occurred at your CA or elsewhere, please contact security@mozilla.org immediately.<br />
<br />
Please confirm completion of the following actions or state when these actions will be completed, and provide the requested information no later than September 16, 2011:<br />
<br />
1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs.<br />
<br />
2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included<br />
<br />
3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance.<br />
<br />
4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked.<br />
<br />
5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either:<br />
<br />
a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical)<br />
<br />
OR<br />
<br />
b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public 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 subordinate CA's internal operations.<br />
<br />
Each action requested above applies both to your root and to these third parties.<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your participation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== April 2011 ==<br />
<br />
Subject: Mozilla Communication: Policy Discussions are in Progress that may Impact Your CA<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to three important items that we would like to bring to your attention.<br />
<br />
1) The CA/Browser Forum has published a final draft of the document "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." We are now hosting a discussion about this document in the mozilla.dev.security.policy forum. For more information, see http://cabforum.org/. <br />
The document is here: http://cabforum.org/Baseline_Requirements_Draft_30b.pdf<br />
<br />
Mozilla supports the CA/Browser Forum’s efforts in this area. After version 1.0 of the CA/Browser Forum’s Baseline Requirements document is published, we will have a discussion to add a requirement to the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/) that CAs include the CA/Browser Forum Baseline Requirements in their policies, practices, and audits. Therefore, we urge you to review the draft of the Baseline Requirements, assessing the impact to your CA policies and practices, and participate in the current discussions about these requirements. The CA/Browser Forum has set the duration of this discussion to 45 days from April 11.<br />
<br />
2) Mozilla has begun discussions about the Phase 2 items to be considered for updating the Mozilla CA Certificate Policy, https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. The current discussions are focused on RAs and Subordinate CAs. We recommend that you monitor and contribute to these discussions so that you are aware of how the potential changes to the Mozilla CA Certificate Policy may impact you.<br />
<br />
3) As per previous communications, we will implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== February 2011 ==<br />
<br />
Subject: Mozilla Communication: Version 2.0 of Mozilla CA Certificate Policy has been published<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla has ratified and published Version 2.0 of the Mozilla CA Certificate Policy. <br />
<br />
The new policy is here:<br />
http://www.mozilla.org/projects/security/certs/policy/ <br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than August 8, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. Now that this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== January 2011 ==<br />
<br />
Subject: Mozilla Communication: Major Pending Update to Mozilla CA Certificate Policy<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla is preparing to update the Mozilla CA Certificate Policy. The forthcoming changes will come in multiple phases, and the first phase is nearly complete. Discussion about the first phase of changes has proceeded for several months in the mozilla.dev.security.policy forum. Version 2.0 of the policy, reflecting the first phase of updates, is now under final review. Mozilla expects it to be ratified by January 31, 2011.<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than April 30, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
The current policy (version 1.2) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/<br />
<br />
The new policy (version 2.0) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/<br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945#c3<br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. After this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== October 2010 ==<br />
<br />
Subject: Mozilla Communication to CAs regarding Policy updates, October 2010<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to five important points that we would like to bring to your attention.<br />
<br />
1) Mozilla has started a project to update the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/). The proposed changes may impact the operation of your root certificates that are included in NSS. Therefore, we request that all CAs participate in the discussions, which will be held in the Mozilla.dev.security.policy forum, http://www.mozilla.org/about/forums/#dev-security-policy. For information about the potential changes, please see https://wiki.mozilla.org/CA:CertPolicyUpdates.<br />
<br />
2) As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must provide an OCSP capability for end-entity certificates that are issued after Dec 31, 2010. Mozilla is considering technical ways to enforce this OCSP requirement such that if Firefox cannot obtain a valid response from the OCSP responder, then the certificate will not be given EV treatment. We are considering requiring the end-entity certificate to provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23<br />
Additionally, we urge all CAs to provide OCSP for all certs, even when they are not EV.<br />
<br />
3) We expect that all new certificates contain randomness (preferably in the serial number), especially when using the SHA-1 hash function or an RSA key size smaller than 2048 bits. For more information, please see http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period and serial number prediction”, and section 7, “Countermeasures.”<br />
<br />
4) As per the NIST guidelines, it is our expectation that all CAs are transitioning from issuing certs with RSA key sizes smaller than 2048 bits. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
5) We are planning to implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certs. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== May 2010 ==<br />
<br />
Subject: Mozilla Communication: Acceptable Addresses for Domain Control Validation<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to some changes that we are proposing to make to Mozilla’s CA Certificate Policy.<br />
<br />
Section 7 of the Mozilla CA Certificate Policy states: “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;”<br />
<br />
Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. Offering too many options for the email address prefix increases the risk of issuing a certificate to a subscriber who does not own/control the domain. Therefore, the list of email address prefixes should be limited.<br />
<br />
Mozilla is proposing to restrict the set of verification addresses that may be used for domain validation to the following list or a subset of it. Mozilla’s goal is to strike a balance between flexibility and safety.<br />
<br />
Accepted addresses for domain validation challenge-response email:<br />
* root@domain<br />
* admin@domain<br />
* administrator@domain<br />
* webmaster@domain<br />
* hostmaster@domain<br />
* Plus any address listed in the contact fields of the domain's WHOIS record.<br />
<br />
We hope that this restriction, when implemented consistently across CAs, will not cause discrimination or hardship. We are seeking feedback on whether this is the case. We invite you to contribute your feedback to a discussion about this new restriction in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.<br />
<br />
http://www.mozilla.org/community/developer-forums.html<br />
https://lists.mozilla.org/listinfo/dev-security-policy<br />
news://news.mozilla.org/mozilla.dev.security.policy<br />
<br />
The discussion thread is called “Domain Control validation” and “Acceptable Addresses for Domain Control Validation”.<br />
<br />
We have also added this information to our wiki page:<br />
https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs<br />
<br />
We look forward to your contributions to this discussion.<br />
<br />
Regards,<br />
Kathleen Wilson<br />
<br />
== November 2009 ==<br />
<br />
Subject: Mozilla Communication: SSL certificates issued to internal domain names <br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla I am contacting you in regards to root certificates that you currently have included by default in Mozilla products, such as the Firefox browser. <br />
<br />
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. <br />
<br />
Section 7 of Mozilla’s CA Certificate Policy states that CAs need to take “reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate.” There are different interpretations as to what this means in regards to internal domain names such as non-valid TLDs, hostnames, and IP addresses. However, there is consensus that there are problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks. Mozilla is currently discussing whether the CA Certificate Policy should be updated to add more explicit requirements on this practice, or even to disallow it altogether.<br />
<br />
In the light of the current situation, Mozilla requests that you take the following actions.<br />
<br />
1) Perform an internal audit to look for certificates that have been issued within your CA hierarchy which have .int domain names in the Common Name and/or as DNS Names in the subjectAlternativeName. For each of these certificates, check to see if the certificate subscriber owns/controls that domain name, and revoke the certificate if they do not own/control that domain name.<br />
<br />
2) Review your controls/procedures (both internally and your RAs) for correct identification of internal and external domain names and verification that subscribers own/control the domain name to be included in their certificate. Please refer to these documents:<br />
a) Section 7 of Mozilla’s CA Certificate Policy<br />
(http://www.mozilla.org/projects/security/certs/policy/)<br />
b) https://wiki.mozilla.org/CA:Recommended_Practices<br />
c) https://wiki.mozilla.org/CA:Problematic_Practices<br />
<br />
Mozilla also recommends that you <br />
1) Update your training procedures to ensure that all validation staff are aware of this situation. <br />
2) Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates.<br />
3) Maintain your own list of ICANN approved TLDs that are eligible to be used for domains in certificates issued within your CA hierarchy. If a new TLD is created by IANA, make an explicit decision whether or not to add the new TLD to your list.<br />
http://www.icann.org/en/registries/top-level-domains.htm<br />
<br />
Mozilla strongly encourages you to take prompt action in order to ensure the continued security and trust-ability of your CA service. <br />
<br />
Kathleen Wilson</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Communications&diff=1247829CA/Communications2023-09-02T23:46:28Z<p>Kathleen Wilson: fixed typo</p>
<hr />
<div>The following are communications that have been sent to Certification Authorities participating in [[CA | Mozilla's root program.]] If you have questions regarding these communications, please first review related discussions in the Mozilla dev-security-policy forum. If your questions cannot be answered in that forum, then please send email to certificates@mozilla.org.<br />
<br />
== August 2023 CA Communication and Survey ==<br />
The purpose of this communication and survey is to ensure that CA operators are aware of and prepared to comply with changes to the Mozilla Root Store Policy (MRSP), which we plan to publish soon as version 2.9 with an effective date of September 1, 2023.<br />
<br />
The most significant changes to v2.9 of MRSP are:<br />
# Retirement of Older Root CA Certificates <br />
#* https://wiki.mozilla.org/CA/Root_CA_Lifecycles<br />
# Compliance with the CABF’s S/MIME BRs <br />
#* https://wiki.mozilla.org/CA/Transition_SMIME_BRs<br />
# Security Vulnerability Reporting<br />
#* https://wiki.mozilla.org/CA/Vulnerability_Disclosure<br />
# Removed duplication with CCADB Policy regarding Audit Requirements<br />
#* https://www.ccadb.org/policy<br />
# Annual Submission of CCADB Compliance Self-Assessment<br />
#* https://www.ccadb.org/cas/self-assessment<br />
# Elimination of SHA-1<br />
<br />
Communication and Survey: <br />
https://docs.google.com/document/d/1ieXSt3rJyOSopJnDp4wFGSugpk6pt5pJFJ55rkpb6Ks/edit?usp=sharing <br />
<br />
Survey Responses:<br />
https://docs.google.com/spreadsheets/d/16NMWm9No4MFkC-q9pxLCOwJwvV9sKLen17wnwodu4AU/edit?usp=sharing<br />
<br />
== February 2023 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s Root Store Policy (MRSP) was recently updated to version 2.8.1 with an effective date of February 15, 2023, https://github.com/mozilla/pkipolicy/pull/265/files. Version 2.8.1 contains several clarifications and minor changes that may affect your organization. You need to be aware of these clarifications and changes to ensure your continued compliance with the MRSP. The following are summaries only of the actual language in the MRSP, and in the event of any conflicting interpretation, the MRSP takes precedence over these summaries:<br />
<br />
* You are required to follow and be aware of discussions in both the Mozilla dev-security-policy forum, https://groups.google.com/a/mozilla.org/g/dev-security-policy, and the CCADB Public List, https://groups.google.com/a/ccadb.org/g/public;<br />
* Your CP, CPS, or combined CP/CPS MUST clearly explain your CA’s domain validation procedures and indicate which subsection of section 3.2.2.4 of the CA/Browser Forum’s Baseline Requirements you are complying with;<br />
* Your CP, CPS, or combined CP/CPS MUST be updated at least every 365 days (more often is expected), and it must be reported in the CCADB in a “timely manner”, and failure to do either of these things will require that you file an incident report in Bugzilla;<br />
* You MUST maintain links to all historic versions of each CP, CPS, or combined CP/CPS from the creation of included CA certificates until such certificate hierarchies are no longer trusted by the Mozilla root store, and if your CA certificate was included by Mozilla before December 31, 2022, then you still must maintain links for “reasonably available historic versions” of your CPs, CPSes, or combined CP/CPSes; and<br />
* In the CCADB, if you elect to publish a JSON array of partial CRLs (rather than the full CRL), then the JSON Array of Partitioned CRLs must contain a critical Issuing Distribution Point extension, which shall include a URI whose value is derived from either the URI as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5) or the URL included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA.<br />
<br />
Finally, participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard user security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you very much for your continued cooperation in this pursuit.<br />
<br />
Regards,<br />
Ben Wilson<br />
Mozilla CA Program Manager<br />
<br />
<br />
<br />
== May 2022 CA Communication and Survey ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a058Z000013UmsDQAS Read-only copy of May 2022 CA Communication and Survey]<br />
** This link is '''Read Only'''. To submit your responses, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2022 CA Communication and Survey' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
=== May 2022 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00160,Q00161 Responses to Item 1] -- Compliance with MRSP v. 2.8<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00162,Q00163 Responses to Item 2] -- "Incidents" include audit findings<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00164,Q00165 Responses to Item 3] -- Auditor membership in ACAB'c and WebTrust<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00166,Q00167,Q00168 Responses to Item 4] -- Online Archival of CPs and CPSes<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00169,Q00170 Responses to Item 5] -- Full CRLs for Intermediate TLS CAs in CCADB<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00171,Q00172 Responses to Item 6.1] -- Sunsetting of SHA1 for S/MIME Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00173,Q00174 Responses to Item 6.2] -- Sunsetting of SHA1 for Other Types of Signing<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00175,Q00176 Responses to Item 7] -- Publicly Disclose Intermediate CA Certificates capable of Issuing TLS or S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00177,Q00178 Responses to Item 8] -- Misissuance of Certificate Transparency Precertificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00179,Q00180,Q00181 Responses to Item 9] -- CRL Revocation Reasons for TLS Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00182,Q00183 Responses to Item 10] -- Public Review of Unconstrained Externally-Operated Subordinate CAs<br />
<br />
== February 2022 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla is engaged in policy review discussions to sunset the use of SHA1 for signing by CAs of CRLs, OCSP responses, and SMIME certificates.<br />
See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/CnVjV-bFcyI/m/TFuWOy2BAwAJ<br />
<br />
(Server certificate signing is governed by the Baseline Requirements, and effective June 1, 2022, OCSP responses related to server certificates cannot be signed with SHA1.)<br />
<br />
One proposal is to remove SHA1 from the list of allowed signing algorithms altogether, but before we do this, I would like your proposed sunset dates for the different types of SHA1 signing you might currently perform--SMIME certificates, ARLs/CRLs, and OCSP responses for SMIME certificates.<br />
<br />
Please participate in this important topic, which is already underway on the Mozilla dev-security-policy list. Let us know about your specific concerns and hurdles that would need to be overcome.<br />
(Some CAs have expressed willingness to quickly convert over to SHA256, while others have expressed that it is not a simple task and will require additional development work.)<br />
<br />
Thanks,<br />
Ben Wilson (bwilson@mozilla.com)<br />
Mozilla Root Store Program<br />
<br />
== April 2021 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a054o00000EL1Fo Read-only copy of April 2021 CA Communication]<br />
** This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br><br />
<br><br />
Mozilla’s Root Store Policy was recently updated to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ version 2.7.1] with an effective date of 1 May 2021. This version contains [https://github.com/mozilla/pkipolicy/pull/223 several changes] that may affect your organization and the auditors who evaluate your PKI. These changes require you to take action to ensure your continued compliance. <br />
<br><br><br />
Please review version 2.7.1 of [https://www.mozilla.org/projects/security/certs/policy/ Mozilla’s Root Store Policy] internally, and with your auditors as well. After you and your auditors have reviewed these new requirements, complete the April 2021 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your practices. Read all survey questions first before beginning to respond. <br />
<br><br><br />
To respond to this survey, [https://ccadb.org/cas/ log in to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 30-April-2021.<br />
<br><br><br />
A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Ben Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== April 2021 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00129,Q00142 Responses to Item 1] -- Review Version 2.7.1 of Mozilla's Root Store Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00131,Q00149,Q00143 Responses to Item 2] -- 398-day reuse period on domain/IP address validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00132,Q00144 Responses to Item 3] -- Clarification about EV Audit Requirements <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00133,Q00145 Responses to Item 4] -- Annual Audit Covering the CA Key Pair Lifecycle <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00136,Q00146 Responses to Item 5] -- Audit Team Qualifications<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00137,Q00147 Responses to Item 6] -- List of Incidents in Audit Reports<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00140,Q00150,Q00148 Responses to Item 7] -- Methods to Demonstrate Key Compromise<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00141,Q00157,Q00159 Responses to Item 8] -- Removal of Old Root CA Certificates (challenges and alternatives)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00156,Q00151,Q00158 Responses to Item 8 timelines] -- Timelines and strategies to replace old, non-BR compliant CA hierarchies and root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00152,Q00155,Q00153 Responses to Item 9] -- Audit Letter Validation on Intermediate Certificates<br />
<br />
== May 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J000042AUSv Read-only copy of May 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>This survey requests your input on current policy and upcoming policy changes that affect you as a participant in Mozilla's CA Certificate Program. <br />
<br><br />
<br>To respond to this survey, [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 31-May 2020. <br />
<br><br />
<br>A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br><br />
<br>Regards,<br />
<br>Kathleen Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== May 2020 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00099,Q00100 Responses to Item 1] -- Impact of COVID-19 Restrictions<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00101,Q00102, Responses to Item 2] -- Mozilla Root Store Policy version 2.7 Requirements and Deadlines <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00103,Q00104 Responses to Item 3] -- Reducing Maximum Validity Period for TLS Certificates <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107 Responses to Sub Item 3.1] -- Limit TLS Certificates to 398-day validity<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00108,Q00109,Q00110 Responses to Sub Item 3.2] -- Limit re-use of domain name and IP address verification to 398 days<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00111,Q00112 Responses to Item 4] -- CA/Browser Forum Ballot for Browser Alignment <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00113,Q00114,Q00115 Responses to Sub Item 4.1] -- CA/Browser Forum defined-policy OID in Subscriber Cert certificatePolicies<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00116,Q00117,Q00118 Responses to Sub Item 4.2] -- Byte-for-byte Identical Issuer and Subject Distinguished Names<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00119,Q00120,Q00121 Responses to Sub Item 4.3] -- Text-searchable PDF Audit Statements<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00122,Q00123,Q00124 Responses to Sub Item 4.4] -- OCSP Requirements<br />
<br />
== January 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003waNOW Read-only copy of January 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/ updated]. The 2.7 version went into effect on 1-January 2020. This version contains a [https://github.com/mozilla/pkipolicy/pull/199/files number of changes] that may affect your organization and will require you to take action to comply. Please review Mozilla’s updated Root Store Policy and complete the January 2020 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your Certificate Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘January 2020 CA Communication' survey. Please enter your response by 31 January 2020.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== January 2020 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00082,Q00083 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00084,Q00085,Q00098 Responses to Action 2] -- Update CP/CPS <br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00086,Q00087,Q00097 Responses to Action 3] -- Include EKUs in All End-entity Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00088,Q00089 Responses to Action 4] -- Ensure Audit Reports are Properly Formatted<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00090,Q00096,Q00091 Responses to Action 5] -- Resolve Audit Issues with Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00092,Q00093 Responses to Action 6] -- Incident Reporting<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00094,Q00095 Responses to Action 7] -- Compliance with BRs<br />
<br />
== November 2018 CA Communication (Underscores in dNSNames) ==<br />
On November 12, 2018, the following message was sent to all CAs in the Mozilla program, alerting them to CA/Browser Forum SC12 that established a brief sunset period for the use of underscore characters in dNSNames in publicly-trusted TLS certificates.<br />
<br /><br />
<br />
Dear Certification Authority,<br />
<br />
The CA/Browser Forum recently approved [1] a clarification to the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (BRs) that may affect you. Domain names containing underscore (“_”) characters are not permitted to be encoded as dNSName types in the subjectAlternativeName (SAN) field of BR-compliant certificates. This requirement derives from section 4.2.1.6 of RFC 5280 that the BRs require CAs to comply with by reference.<br />
<br />
Section 7.1.4.2.1 of the BRs will add the following language that clarifies the existing requirement and adds a short time in which CAs must discontinue the use of underscore characters in dNSNames:<br />
-----<br />
Prior to April 1, 2019, certificates containing underscore characters (“_”) in domain labels in dNSName entries MAY be issued as follows:<br />
* dNSName entries MAY include underscore characters such that replacing all underscore characters with hyphen characters (“-“) would result in a valid domain label, and;<br />
* Underscore characters MUST NOT be placed in the left most domain label, and;<br />
* Such certificates MUST NOT be valid for longer than 30 days.<br />
<br />
All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019.<br />
<br />
After April 30, 2019, underscore characters (“_”) MUST NOT be present in dNSName entries.<br />
-----<br />
This new language will go into effect on December 10, 2018 when the IPR review period for ballot SC12 [1] is completed. At that time, CAs must be prepared to stop issuing publicly-trusted TLS certificates containing the underscore character in any dNSName with validity periods of more than 30 days.<br />
<br />
As a participant in Mozilla's CA Certificate Program, we want you to be aware of this important change, and ask that you take any necessary steps to comply. No further action related to this change is requested at this time.<br />
<br />
Regards,<br />
<br />
Wayne Thayer<br />
Mozilla CA Program Manager<br />
<br />
[1] https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/<br />
<br />
=== November 2018 Responses ===<br />
* No survey was included in this CA Communication<br />
<br />
== September 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL Read-only copy of September 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'September 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/ updated]. The 2.6.1 version went into effect on 1-July, 2018. This version contains a number of changes that may affect your organization and will require you to take action to comply. This survey also contains information regarding other recent and upcoming changes that may affect your Certification Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘September 2018 CA Communication' survey. Please enter your response by 30-September 2018.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== September 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00068,Q00069 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00070,Q00071 Responses to Action 2] -- Update CP/CPS<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00072,Q00073 Responses to Action 3] -- Transition to Separate Intermediate Certificates for SSL and S/MIME<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00074,Q00075 Responses to Action 4] -- Ensure Audit Reports comply with Mozilla’s Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00076,Q00077 Responses to Action 5] -- Discontinue use of BR Validation Methods 3.2.2.4.1 and 3.2.2.4.5<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00078,Q00079 Responses to Action 6] -- Disclose Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00080,Q00081 Responses to Action 7] -- Submit TLS Certificates to CT Logs for Mozilla's CRLite<br />
<br />
== January 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mqMFN Read-only copy of January 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br /><br /><br />
2018 has already generated some important news for Certification Authorities, and as a result we are sending this message to ensure that every CA in the Mozilla program is aware of current events and impending deadlines.<br />
<br /><br /><br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.<br />
<br /><br /><br />
To respond to this survey, login to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Please enter your response by 9-February 2018.<br />
<br /><br /><br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br /><br /><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br /><br /><br />
Regards,<br /><br />
Wayne Thayer<br /><br />
Mozilla CA Program Manager<br /><br />
<br />
=== January 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00056,Q00057 Responses to Action 1] -- Disclose Use of Methods 3.2.2.4.9 or 3.2.2.4.10 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00058,Q00059 Responses to Action 2] -- Disclose Use of Methods 3.2.2.4.1 or 3.2.2.4.5 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00060,Q00061 Responses to Action 3] -- Disclose All Non-Technically-Constrained Subordinate CA Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00062,Q00063 Responses to Action 4] -- Complete BR Self Assessment<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00064,Q00065 Responses to Action 5] -- Update CP/CPS to Comply with version 2.5 of Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00066,Q00067 Responses to Action 6] -- Reduce SSL Certificate Validity Periods to 825 Days or Less by March 1, 2018<br />
<br />
== November 2017 CA Communication ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7 Read-only copy of November 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority, <br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, login to the [http://ccadb.org/cas Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Please enter your response by December 15, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be [[CA/Communications|automatically and immediately published]] by the CCADB system.<br />
<br />
Participation in [[CA|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== November 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00035,Q00036 Responses to Action 1] -- Full compliance with version 2.5 of [https://www.mozilla.org/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00037,Q00044 Responses to Action 2] -- non-technically-constrained intermediate certificates must be [http://ccadb.org/cas/intermediates disclosed in CCADB] within one week of creation. '''New requirements''' for [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#technically-constrained technical constraints on intermediate certificates issuing S/MIME certificates].<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00038,Q00045 Responses to Action 3] -- Annual updates via [http://ccadb.org/cas/updates CCADB Audit Cases]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00050,Q00051 Responses to Action 4] -- Reiterate [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#audit-parameters audit requirements] and '''penalty for incomplete audit statements'''<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00039,Q00046 Responses to Action 5] -- Perform a [[CA/BR_Self-Assessment|BR Self Assessment]]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00042,Q00048 Responses to Action 6] -- Provide tested email address for [https://ccadb.my.salesforce-sites.com/mozilla/CAInformationReport Problem Reporting Mechanism]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00040,Q00047 Responses to Action 7] -- Follow new developments and effective dates for [http://tools.ietf.org/html/rfc6844 Certification Authority Authorization (CAA)]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00052,Q00053 Responses to Action 8] -- Check [https://groups.google.com/d/msg/mozilla.dev.security.policy/4kj8Jeem0EU/GvqsgIzSAAAJ issuance of certs to .tg domains] from October 25 to November 11, 2017.<br />
<br />
== May 2017 - Announcing CCADB Changes ==<br />
<br /><br />
Subject: Common CA Database (CCADB) changes May 19-21, 2017<br />
<br /><br /><br />
Message:<br /><br /><br />
Dear Certification Authority,<br />
<br /><br />
<br /><br />
The Common CA Database (CCADB) will undergo the following changes this weekend, May 19 to May 21. During this time, the old URLs listed below will stop working, and there will be some time when the CCADB is in read-only mode.<br />
<br /><br />
<br /><br />
On May 19 the following three breaking changes are planned, meaning that the old URLs will no longer work. Any links or bookmarks to these URLs will need to be updated. After these changes are made, I will also update Mozilla's wiki pages to point to the new URLs.<br />
<br /><br />
<br /><br />
1) The CA login page and the domain CAs see when they are logged into the CCADB will change.<br />
<br /><br />
https://mozillacacommunity.force.com/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb.force.com/<br />
<br /><br />
<br /><br />
2) The links to reports that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/CA/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/mozilla/<br />
<br /><br />
<br /><br />
3) The links to CA communication responses that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/Communications<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/Surveys<br />
<br /><br />
<br /><br />
Then on May 21 between 12am and 4am PDT, the CCADB will be in read-only mode while Salesforce performs an instance refresh to upgrade the infrastructure supporting the CCADB instance in their data centers.<br />
<br /><br />
<br /><br />
Regards,<br />
<br /><br />
Kathleen<br />
<br />
== April 2017 ==<br />
<br />
Note: The deadline to reply to this survey has [https://groups.google.com/d/msg/mozilla.dev.security.policy/03rdTdnm7iw/NQUHmWOcEAAJ been extended] by one week, to May 5, 2017.<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000003WrzBC Read-only copy of April 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [https://ccadb.force.com/CustomLogin login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA:IncludedCAs|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, [https://mozillacacommunity.force.com/CustomLogin login to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Please enter your response by April 28, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br />
In addition to responding to the action items in this survey, we are instituting a program requirement that you follow discussions in the [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] forum, which includes discussions about upcoming changes to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy], questions and clarification about policy and expectations, root certificate [[CA|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] or other program requirements. You are not required to contribute to those discussions, only to be aware of them. However, we hope you will participate and help shape the future of Mozilla's CA Certificate Program.<br />
<br />
Participation in [[CA:Overview|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== April 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [[CA:CommonCADatabase|Common CA Database]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00015,Q00030 Responses to Action 1] -- Domain Validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 2 and Action 10] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00022,Q00029 Responses to Action 3] -- Updated Mozilla CA Certificate Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00017,Q00031 Responses to Action 4] -- Audit Statements, annual updates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00018,Q00032 Responses to Action 5] -- Audit Statement Contents<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00021,Q00033 Responses to Action 6] -- Qualified Audit Statements<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00019 Responses to Action 7] -- BR Compliance Bugs<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 Responses to Action 8] -- Confirm Completion of Previous Commitments<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00027 Responses to Action 9] -- Registration Authorities<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 10 and Action 2] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00023 Responses to Action 11] -- Certification Authority Authorization (CAA)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00028 Responses to Action 12] -- Problem Reporting Mechanism<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00024 Responses to Action 13] -- SHA-1 and S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00034 Responses to Action 14] -- Certificate Validity Periods in TLS/SSL Certs<br />
<br />
== March 2016 ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000000iHdtx Read-only copy of March 2016 CA Communication]<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program, by April 22, 2016.<br />
<br />
To respond to this survey, please login to the [[CA:SalesforceCommunity|CA Community in Salesforce]], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'March 2016 CA Communication' survey. Please enter your response by April 22, 2016. <br />
<br />
A compiled list of CA responses to the survey action items will be [[CA:Communications#March_2016_Responses|automatically and immediately published]] by Salesforce.<br />
<br />
In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the [https://groups.google.com/forum/#!forum/mozilla.dev.security.policy mozilla.dev.security.policy] forum, which includes discussions about [[CA:CertificatePolicyV2.3|upcoming changes to Mozilla's CA Certificate Policy]], questions and clarification about policy and expectations, root certificate [[CA:Schedule|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements]. Your contributions to the discussions will help shape the future of [[CA:Overview|Mozilla's CA Certificate Program]].<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Mozilla CA Program Manager<br />
<br />
=== March 2016 Responses ===<br />
<br />
The following links are automatically generated from data in the [[CA:SalesforceCommunity|CA Community in Salesforce]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommSummaryReport?CommunicationID=a05o000000iHdtx CA Responses to March 2016 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00001,Q00013 Responses to Action #1a] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00002,Q00014 Responses to Action #1b] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 Responses to Action #1c] -- SHA-1 Deprecation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 Responses to Action #2] -- Entering intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00005 Responses to Action #3] -- Entering revoked intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00006&QuestionIdForText=Q00007 Responses to Action #4] -- [[SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix|Removing workarounds]] to compatibility issues that were encountered involving certificates that did not conform to the Baseline Requirements. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00008 Responses to Action #5] -- Plans to remove old/retired root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00009 Responses to Action #6] -- Confirmation of understanding that all certificates, including test certificates, must conform to stated policies<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00012 Responses to Action #7] -- [[CA:RootTransferPolicy|Mozilla's Root Transfer Policy]]<br />
<br />
== May 2015 ==<br />
<br />
Dear Certification Authority, <br />
<br />
This email requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by June 5, 2015, with your response to the action items by clicking on the survey link below. A compiled list of CA responses to these action items will be published. <br />
<br />
Certification Authority: <CA Account Name><br />
<br />
Your Survey Link: <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/TakeSurvey?id=a04o000000M89RCAAZ&cId=&caId=none Survey Link] -- '''IMPORTANT: CA's do NOT use the link in this wiki page! This link will NOT record your response. Please use the link that was emailed to you.'''<br />
<br />
Please use the above link to read and respond to the action items. Note that you may access the above link multiple times to update your responses.<br />
<br />
Additionally, we plan to update Mozilla's CA Certificate Policy soon, and will be discussing proposed policy updates in the mozilla.dev.security.policy forum, https://www.mozilla.org/en-US/about/forums/#dev-security-policy. We encourage you to monitor the discussions to see how the updates will impact you, and your participation in the discussions will help shape the policy updates.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, <br />
Mozilla <br />
CA Program Manager<br />
<br />
=== May 2015 Responses ===<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationSummaryReport?CommunicationId=a04o000000M89RCAAZ CA Responses to May 2015 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%233:%20After%20January%201,%202016 Responses to Action #3] -- SHA-1 Deprecation Plans<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%234:%20Workarounds%20were%20implemented Responses to Action #4] -- Removing workarounds implemented to allow mozilla::pkix to handle the things listed here https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%235:%20We%20wish%20to%20understand%20what%20support Responses to Action #5] -- IPv6 survey<br />
<br />
== May 2014 ==<br />
<br />
Subject: Mozilla Communication: Action requested by May 30, 2014<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by May 30, 2014, with your response to these action items. A compiled list of CA responses to the following action items will be published. <br />
<br />
CA Certificate Inclusion Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/<br />
<br />
CA Certificate Maintenance Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/<br />
<br />
Spreadsheet of included root certificates: http://www.mozilla.org/about/governance/policies/security-group/certs/included/<br />
<br />
1) Ensure that Mozilla’s [http://www.mozilla.org/about/governance/policies/security-group/certs/included/ spreadsheet of included root certificates] has the correct link to your most recent audit statement, and that the date of the audit statement is correct. As per [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/ Mozilla's CA Certificate Maintenance Policy], we require that all CAs whose certificates are distributed with our software products provide us an updated statement annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties. To notify us of an updated statement of attestation, send email to certificates@mozilla.org or [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates submit a bug report] into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "mozilla.org" product.<br />
If you are not proactively sending Mozilla your updated audit statements, please create a process to do so.<br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent audit statement, and the audit statement date is correct.<br />
* B) Here is the most recent audit statement for our certificates that are included in Mozilla’s CA program: <insert link here> <br />
* C) We plan to send Mozilla our current audit statement by <insert date here>.<br />
* D) We do not have a current audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
2) Send Mozilla the link to your most recent [https://cabforum.org/about-the-baseline-requirements/ Baseline Requirements] audit statement. Details about Mozilla's audit requirements are listed in section 11 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy]. The Baseline Requirements audit statement should also be proactively sent to Mozilla each year, along with the other audit statements as described in action #1. <br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent Baseline Requirements audit statement.<br />
* B) Here is the most recent Baseline Requirements audit statement for our certificates that are included in Mozilla’s CA program: <insert link here>. <br />
* C) We plan to send Mozilla our current Baseline Requirements audit statement by <insert date here and explain reason for delay>.<br />
* D) The websites (SSL/TLS) trust bit is not enabled for our certificates that are included in Mozilla's CA program.<br />
* E) We do not have a current Baseline Requirements audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
3) Test Mozilla's new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed. <br />
The new Certificate Verification library (mozilla::pkix) was announced here: https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ .<br />
Mozilla::pkix includes some changes in support of current best practices and policies, as listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes .<br />
How to test: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing .<br />
<br />
Please respond with one of the following: <br />
* A) We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix.<br />
* B) We have found the following issues when testing certificates in our CA hierarchy with mozilla::pkix. <descriptions or Bugzilla bug numbers, related URLs and/or certificates><br />
* C) We are testing certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and plan to send Mozilla our results by <insert date here, must be before June 30, 2014>.<br />
<br />
4) Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix<br />
<br />
Please respond with one of the following: <br />
* A) We have not and will not issue certificates with any of the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page.<br />
* B) We have previously issued certificates with the following problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page: <list the problems that needed to be fixed>. The last of those certificates expire <insert dates here, one date per problem>. We will not issue new certificates with the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page as of this date: <date when your operations will be updated, no later than June 30, 2014><br />
<br />
5) Send Mozilla information about your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, as per Items #8, 9, and 10 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy].<br />
<br />
Please provide a URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, and contains the required information according to section 10 of Mozilla's CA Certificate Inclusion Policy. If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificates" component of the "mozilla.org" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates)<br />
<br />
Additionally, please respond with one of the following: <br />
* A) All subordinate CA certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy.<br />
* B) We request an extension for the following specific subordinate CA certificates, because these subordinate CAs need more time to transition from their legacy systems to their new CA hierarchy: <list of issuer hash, issuer public key hash, and certificate serial number>. For each subordinate CA who needs to operate in their legacy design a little longer, the attached document explains the reason that continued operation is needed and their target date for resolution. <attach document(s) to response><br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== May 2014 Responses ===<br />
<br />
[https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml CA Responses to May 2014 Communication]<br />
<br />
== July 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by August 16, 2013<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s CA Certificate Policy has been updated with a few important changes. This update was motivated by security concerns regarding ICANN granting applied-for new gTLD strings. Additionally, we want to make it very clear that there will be serious consequences if it is found that a CA has knowingly or intentionally mis-issued certificates chaining to trust anchors in Mozilla’s program.<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of applications.<br />
<br />
Please carefully review the following wiki page for information about the changes introduced in version 2.2 of Mozilla’s CA Certificate Policy.<br />
<br />
https://wiki.mozilla.org/CA:CertificatePolicyV2.2<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by August 16, 2013, with your response to the following action items. <br />
<br />
1) Update your CA operations and policies to include the CA/Browser Forum’s Baseline Requirement #11.1.4 regarding new gTLD domains, and subscribe to ICANN’s new gTLD Registry Agreement notification mailing list at: https://mm.icann.org/mailman/listinfo/gtldnotification<br />
<br />
Please respond with one of the following:<br />
* A) No action required, because we have not and will not issue SSL certificates with internal or private domain names chaining up to root certificates that are included in Mozilla’s program.<br />
* B) We have issued or may issue SSL certificates with internal or private domain names that chain up to root certificates that are included in Mozilla’s program, so we are implementing Baseline Requirement #11.1.4, and will subscribe to ICANN’s notification service regarding applied-for-gTLD strings. We plan to have this completed by September 16, 2013.<br />
* C) We have already implemented Baseline Requirement #11.1.4, and have subscribed to ICANN’s notification service regarding applied-for-gTLD strings.<br />
<br />
2) Review your CA operations and customers to ensure that there are no certificates chaining up to your trust anchors that are included in Mozilla’s program that may be used for MITM or “traffic management” of domain names or IP addresses that the certificate holder does not own or control. [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla’s CA Certificate Enforcement Policy] has been updated to make it clear that Mozilla will not tolerate this use of publicly trusted certificates. <br />
<br />
Please respond with:<br />
* “We have reviewed Mozilla’s updated CA Certificate Enforcement Policy and understand that knowing or intentional mis-issuance of a certificate is expressly against Mozilla’s CA Certificate Policy and could result in removal of all of our certificates from Mozilla’s products.”<br />
<br />
3) Ensure that your CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current, including links to the CP/CPS documents, audit statements, and test websites. Mozilla will be adding a column to this spreadsheet to indicate the date of the most recent audit statement for each root certificate.<br />
<br />
http://www.mozilla.org/projects/security/certs/included/index.html<br />
<br />
Please respond with one of the following:<br />
* A) Our CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current for all of our included certificates.<br />
* B) Here is the current information for our certificates that are included in Mozilla’s program: <insert data here><br />
<br />
4) Complete the action items from Mozilla’s January CA Communication.<br />
* https://wiki.mozilla.org/CA:Communications#January_10.2C_2013<br />
* https://wiki.mozilla.org/CA:Communications#January_2013_Responses<br />
<br />
Please respond with one of the following:<br />
* A) Our recorded response to the January CA Communication is complete and correct.<br />
* B) We have the following updated status for our response to the January CA Communication: <insert data here><br />
<br />
5) Follow discussion about the changes to policy and code that Mozilla will be making in order to improve how revocation checking is handled in Firefox. Discussions will be held in the mozilla.dev.security.policy forum, and descriptions of the changes that will be considered for both policy and code will be provided here: https://wiki.mozilla.org/CA:ImprovingRevocation<br />
As part of this effort, Mozilla will be implementing a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker. More information will follow, and policy will be added soon to require CAs to send Mozilla revocation information. We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
<br />
=== July 2013 Responses ===<br />
<br />
* [https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGR1TmZLZnJ1RThHRDcwMDJRaXZicFE&output=html CA Responses to July 2013 Communication]<br />
<br />
== January 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by January 31, 2013. <br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by January 31, 2013, with your response to these action items. A compiled list of CA responses to the following action items will be published.<br />
<br />
1) Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations. <br />
<br />
Version 2.1 of Mozilla’s CA Certificate Policy is in final review, and will be ratified and published in Q1 of 2013. There are changes to the policy that may impact your current operations, so we encourage you to review the changes that are indicated in red or bold text here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html<br />
<br />
There will be a transition period for CAs to bring existing customers into compliance with the new policy, as described here:<br />
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1<br />
<br />
Please respond to this action item with one of the following:<br />
* a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.<br />
* b) The proposed changes to Mozilla’s CA Certificate Policy impact our CA operations, but we will be able to complete the transition within the allotted time frame.<br />
* c) We will not be able to update our CA operations to comply with the proposed version 2.1 of Mozilla’s CA Certificate Policy within the allotted time frame, because <insert reason(s)>. We plan to meet the new requirements by <insert date>.<br />
<br />
2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements.<br />
<br />
The CA/Browser Forum (http://www.cabforum.org) released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which became effective on July 1, 2012. It is our expectation that as of January 2013 CA issuance of SSL certificates will be audited against these Baseline Requirements as well as the acceptable audit criteria that are listed in Mozilla’s CA Certificate Policy.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.<br />
* b) Not applicable, because we do not issue SSL certificates.<br />
* c) We are working towards compliance with the CA/Browser Forum’s Baseline Requirements, but we need to complete <insert list of tasks>. We plan to have this completed by <insert date>.<br />
<br />
3) Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit.<br />
<br />
Due to the recent incident in which a mis-issued intermediate certificate was found (https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates), we are concerned that CAs may have responded to our last communication based on their policies, rather than checking their certificate databases. Therefore, we request that you scan your certificate database and inform Mozilla if you find any un-expired intermediate certificates in your CA hierarchy that should not be trusted. In your reply, please attach all such intermediate certificates, even if you have already revoked them.<br />
<br />
While you are scanning your certificate databases to ensure that all certificates with basicConstraints:CA:TRUE have been issued in accordance with your CPS, please also check for compliance with the following practices.<br />
* All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.<br />
* All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.<br />
* All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration).<br />
* All end-entity certificates with RSA key sizes smaller than 2048 bits expire no later than December 2013.<br />
* Certificates are not issued with sequential serial numbers. If it is found that certificates have been issued with contiguous serial numbers, then the subject of those certificates must contain unpredictable data that is not under the control of the certificate subscriber.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* b) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
* c) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* d) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
<br />
4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name.<br />
<br />
The CA/Browser Forum’s Baseline Requirements state: <br />
“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 Server 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.”<br />
<br />
This practice is being eliminated for security reasons, so we encourage all CAs to begin working with their customers to transition to alternative arrangements, and to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names as soon as possible rather than waiting until the deadline.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names.<br />
* b) We plan to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names by <insert date>.<br />
<br />
5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it. We expect this website to endure for the lifetime of the root, or until you notify us of an alternative URL. The website does not need to support high traffic loads or have greater than 99% uptime.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson, <br />
Module Owner of Mozilla's CA Certificates Module <br />
<br />
=== January 2013 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dHdISmM3c05tb1dMQjlJclJqS21QNmc&output=html CA Responses to January 2013 Communication] -- Contains two spreadsheets: "Action Item Responses" and "Test Website URLs".<br />
<br />
== February 2012 ==<br />
<br />
Subject: Mozilla Communication: Action requested by March 2, 2012<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Please reply by March 2, 2012, to confirm completion of the following actions or state when these actions will be completed.<br />
<br />
1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012. For each subordinate CA that is revoked, send me:<br />
* a) The certificate that signed the subCA. If it is a root certificate in NSS, then the root certificate's subject and SHA1 fingerprint.<br />
* b) The Serial Number of the revoked certificate.<br />
* c) The CRL that contains the serial number of the revoked certificate.<br />
<br />
As a CA in Mozilla’s root program you are ultimately responsible for certificates issued by you and any intermediate CAs that chain up to your roots. After April 27, 2012, if it is found that a subordinate CA is being used for MITM, we will take action to mitigate, including and up to removing the corresponding root certificate. Based on Mozilla’s assessment, we may also remove any of your other root certificates, and root certificates from other organizations that cross-sign your certificates.<br />
<br />
I am planning to publish a compiled list of CA responses to all of the action items in this communication. Therefore, I recommend responding to action item #1 with one of the following choices:<br />
* a) Does not apply, because we do not issue subCA certificates to third parties.<br />
* b) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
* c) We are reviewing all of our subCAs and will take the necessary action by <date>. <br />
* d) We have revoked such subCA certificates, and here is the requested information.<br />
* e) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM. ''(Note: This option was added after the communication was sent.)''<br />
<br />
2) If you issue subordinate CAs to third parties or your CP/CPS permits you to do so in the future, please add a statement to your CP/CPS committing that you will not issue a subordinate certificate that can be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control. Send me the URL to the updated document(s) and the impacted sections or page numbers. <br />
<br />
3) Please scan all of your EV SSL certificates and revoke any that do not meet the EV requirements. This includes, but is not limited to maximum validity period of the certificate, subject naming, minimum key sizes, required extensions, and maximum expiration time of OCSP responses.<br />
<br />
4) Certificates chaining to root certificates in Mozilla’s root program should not have MD5 algorithms or RSA keys shorter than 1024 bits long. Please scan the certificates chaining to your root certificates in NSS, and revoke any certificates that contain small key sizes or MD5 algorithms. <br />
<br />
5) The CA/Browser Forum has released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which is available here: http://www.cabforum.org/. Discussions are in progress in the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate Policy to add a requirement that CAs also meet these baseline requirements for issuance of SSL/TLS certificates. Please contribute to the discussions in the mozilla.dev.security.policy forum, and update your operations and documentation as needed to meet the baseline requirements by the effective date of July 1, 2012.<br />
<br />
The currently proposed updates to Mozilla’s CA Certificate Policy are here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== February 2012 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGxsWlZEdGFDaW9JTlNTUGxBNWhqSlE&output=html CA Responses] -- spreadsheet of the responses to the action items of the CA Communication that was sent on February 17, 2012.<br />
<br />
Response Key:<br />
* IP = "In Progress"<br />
* ? = I need further clarification on the response<br />
* N/A = "Not Applicable"<br />
** N/A for Action #2 means that the CP/CPS does not allow for externally-operated subCAs.<br />
** N/A for Action #3 means that the CA is not issuing EV certs under the roots included in NSS.<br />
* Responses to action #1 can be one or more of the following. If option C is listed, there is also a date by which the CA plans to complete their investigation and provide further information.<br />
** A) Does not apply, because the CA does not have externally-operated subCAs chaining to roots in NSS.<br />
** B) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
** C) The CA is reviewing all of their subCAs and will take the necessary action by <date>.<br />
** D) The CA has revoked such subCA certificates, and provided the requested information.<br />
** E) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
<br />
== September 2011 ==<br />
<br />
Subject: Mozilla Communication: Immediate action requested<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Mozilla recently removed the DigiNotar root certificate in response to their failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates (https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up). If you ever have reason to suspect a security breach or mis-issuance has occurred at your CA or elsewhere, please contact security@mozilla.org immediately.<br />
<br />
Please confirm completion of the following actions or state when these actions will be completed, and provide the requested information no later than September 16, 2011:<br />
<br />
1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs.<br />
<br />
2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included<br />
<br />
3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance.<br />
<br />
4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked.<br />
<br />
5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either:<br />
<br />
a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical)<br />
<br />
OR<br />
<br />
b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public 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 subordinate CA's internal operations.<br />
<br />
Each action requested above applies both to your root and to these third parties.<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your participation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== April 2011 ==<br />
<br />
Subject: Mozilla Communication: Policy Discussions are in Progress that may Impact Your CA<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to three important items that we would like to bring to your attention.<br />
<br />
1) The CA/Browser Forum has published a final draft of the document "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." We are now hosting a discussion about this document in the mozilla.dev.security.policy forum. For more information, see http://cabforum.org/. <br />
The document is here: http://cabforum.org/Baseline_Requirements_Draft_30b.pdf<br />
<br />
Mozilla supports the CA/Browser Forum’s efforts in this area. After version 1.0 of the CA/Browser Forum’s Baseline Requirements document is published, we will have a discussion to add a requirement to the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/) that CAs include the CA/Browser Forum Baseline Requirements in their policies, practices, and audits. Therefore, we urge you to review the draft of the Baseline Requirements, assessing the impact to your CA policies and practices, and participate in the current discussions about these requirements. The CA/Browser Forum has set the duration of this discussion to 45 days from April 11.<br />
<br />
2) Mozilla has begun discussions about the Phase 2 items to be considered for updating the Mozilla CA Certificate Policy, https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. The current discussions are focused on RAs and Subordinate CAs. We recommend that you monitor and contribute to these discussions so that you are aware of how the potential changes to the Mozilla CA Certificate Policy may impact you.<br />
<br />
3) As per previous communications, we will implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== February 2011 ==<br />
<br />
Subject: Mozilla Communication: Version 2.0 of Mozilla CA Certificate Policy has been published<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla has ratified and published Version 2.0 of the Mozilla CA Certificate Policy. <br />
<br />
The new policy is here:<br />
http://www.mozilla.org/projects/security/certs/policy/ <br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than August 8, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. Now that this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== January 2011 ==<br />
<br />
Subject: Mozilla Communication: Major Pending Update to Mozilla CA Certificate Policy<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla is preparing to update the Mozilla CA Certificate Policy. The forthcoming changes will come in multiple phases, and the first phase is nearly complete. Discussion about the first phase of changes has proceeded for several months in the mozilla.dev.security.policy forum. Version 2.0 of the policy, reflecting the first phase of updates, is now under final review. Mozilla expects it to be ratified by January 31, 2011.<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than April 30, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
The current policy (version 1.2) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/<br />
<br />
The new policy (version 2.0) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/<br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945#c3<br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. After this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== October 2010 ==<br />
<br />
Subject: Mozilla Communication to CAs regarding Policy updates, October 2010<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to five important points that we would like to bring to your attention.<br />
<br />
1) Mozilla has started a project to update the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/). The proposed changes may impact the operation of your root certificates that are included in NSS. Therefore, we request that all CAs participate in the discussions, which will be held in the Mozilla.dev.security.policy forum, http://www.mozilla.org/about/forums/#dev-security-policy. For information about the potential changes, please see https://wiki.mozilla.org/CA:CertPolicyUpdates.<br />
<br />
2) As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must provide an OCSP capability for end-entity certificates that are issued after Dec 31, 2010. Mozilla is considering technical ways to enforce this OCSP requirement such that if Firefox cannot obtain a valid response from the OCSP responder, then the certificate will not be given EV treatment. We are considering requiring the end-entity certificate to provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23<br />
Additionally, we urge all CAs to provide OCSP for all certs, even when they are not EV.<br />
<br />
3) We expect that all new certificates contain randomness (preferably in the serial number), especially when using the SHA-1 hash function or an RSA key size smaller than 2048 bits. For more information, please see http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period and serial number prediction”, and section 7, “Countermeasures.”<br />
<br />
4) As per the NIST guidelines, it is our expectation that all CAs are transitioning from issuing certs with RSA key sizes smaller than 2048 bits. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
5) We are planning to implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certs. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== May 2010 ==<br />
<br />
Subject: Mozilla Communication: Acceptable Addresses for Domain Control Validation<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to some changes that we are proposing to make to Mozilla’s CA Certificate Policy.<br />
<br />
Section 7 of the Mozilla CA Certificate Policy states: “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;”<br />
<br />
Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. Offering too many options for the email address prefix increases the risk of issuing a certificate to a subscriber who does not own/control the domain. Therefore, the list of email address prefixes should be limited.<br />
<br />
Mozilla is proposing to restrict the set of verification addresses that may be used for domain validation to the following list or a subset of it. Mozilla’s goal is to strike a balance between flexibility and safety.<br />
<br />
Accepted addresses for domain validation challenge-response email:<br />
* root@domain<br />
* admin@domain<br />
* administrator@domain<br />
* webmaster@domain<br />
* hostmaster@domain<br />
* Plus any address listed in the contact fields of the domain's WHOIS record.<br />
<br />
We hope that this restriction, when implemented consistently across CAs, will not cause discrimination or hardship. We are seeking feedback on whether this is the case. We invite you to contribute your feedback to a discussion about this new restriction in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.<br />
<br />
http://www.mozilla.org/community/developer-forums.html<br />
https://lists.mozilla.org/listinfo/dev-security-policy<br />
news://news.mozilla.org/mozilla.dev.security.policy<br />
<br />
The discussion thread is called “Domain Control validation” and “Acceptable Addresses for Domain Control Validation”.<br />
<br />
We have also added this information to our wiki page:<br />
https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs<br />
<br />
We look forward to your contributions to this discussion.<br />
<br />
Regards,<br />
Kathleen Wilson<br />
<br />
== November 2009 ==<br />
<br />
Subject: Mozilla Communication: SSL certificates issued to internal domain names <br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla I am contacting you in regards to root certificates that you currently have included by default in Mozilla products, such as the Firefox browser. <br />
<br />
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. <br />
<br />
Section 7 of Mozilla’s CA Certificate Policy states that CAs need to take “reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate.” There are different interpretations as to what this means in regards to internal domain names such as non-valid TLDs, hostnames, and IP addresses. However, there is consensus that there are problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks. Mozilla is currently discussing whether the CA Certificate Policy should be updated to add more explicit requirements on this practice, or even to disallow it altogether.<br />
<br />
In the light of the current situation, Mozilla requests that you take the following actions.<br />
<br />
1) Perform an internal audit to look for certificates that have been issued within your CA hierarchy which have .int domain names in the Common Name and/or as DNS Names in the subjectAlternativeName. For each of these certificates, check to see if the certificate subscriber owns/controls that domain name, and revoke the certificate if they do not own/control that domain name.<br />
<br />
2) Review your controls/procedures (both internally and your RAs) for correct identification of internal and external domain names and verification that subscribers own/control the domain name to be included in their certificate. Please refer to these documents:<br />
a) Section 7 of Mozilla’s CA Certificate Policy<br />
(http://www.mozilla.org/projects/security/certs/policy/)<br />
b) https://wiki.mozilla.org/CA:Recommended_Practices<br />
c) https://wiki.mozilla.org/CA:Problematic_Practices<br />
<br />
Mozilla also recommends that you <br />
1) Update your training procedures to ensure that all validation staff are aware of this situation. <br />
2) Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates.<br />
3) Maintain your own list of ICANN approved TLDs that are eligible to be used for domains in certificates issued within your CA hierarchy. If a new TLD is created by IANA, make an explicit decision whether or not to add the new TLD to your list.<br />
http://www.icann.org/en/registries/top-level-domains.htm<br />
<br />
Mozilla strongly encourages you to take prompt action in order to ensure the continued security and trust-ability of your CA service. <br />
<br />
Kathleen Wilson</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Communications&diff=1247828CA/Communications2023-09-02T23:44:35Z<p>Kathleen Wilson: Added context about the communication and v2.9 of MRSP</p>
<hr />
<div>The following are communications that have been sent to Certification Authorities participating in [[CA | Mozilla's root program.]] If you have questions regarding these communications, please first review related discussions in the Mozilla dev-security-policy forum. If your questions cannot be answered in that forum, then please send email to certificates@mozilla.org.<br />
<br />
== August 2023 CA Communication and Survey ==<br />
The purpose of this communication and survey is to ensure that CA operators are aware of and prepared to comply with changes to the Mozilla Root Store Policy (MRSP), which we plan to publish soon as version 2.9 with an effective date of September 1, 2023.<br />
<br />
The most significant changes to v2.9 of MRSP are:<br />
# Retirement of Older Root CA Certificates <br />
#* https://wiki.mozilla.org/CA/Root_CA_Lifecycles<br />
# Compliance with the CABF’s S/MIME BRs <br />
#* https://wiki.mozilla.org/CA/Transition_SMIME_BRs<br />
# Security Vulnerability Reporting<br />
#* https://wiki.mozilla.org/CA/Vulnerability_Disclosure<br />
# Removed duplication with CCADB Policy regarding Audit Requirements<br />
#* https://www.ccadb.org/policy<br />
# Annual Submission of CCADB Compliance Self-Assessment<br />
#* https://www.ccadb.org/cas/self-assessment<br />
# Elimination of SHA-1<br />
<br />
Communication and Survey: <br />
https://docs.google.com/document/d/1ieXSt3rJyOSopJnDp4wFGSugpk6pt5pJFJ55rkpb6Ks/edit?usp=sharing <br />
<br />
Read-only view of the survey: <br />
https://docs.google.com/document/d/1ieXSt3rJyOSopJnDp4wFGSugpk6pt5pJFJ55rkpb6Ks/edit?usp=sharing<br />
<br />
Survey Responses:<br />
https://docs.google.com/spreadsheets/d/16NMWm9No4MFkC-q9pxLCOwJwvV9sKLen17wnwodu4AU/edit?usp=sharing<br />
<br />
== February 2023 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s Root Store Policy (MRSP) was recently updated to version 2.8.1 with an effective date of February 15, 2023, https://github.com/mozilla/pkipolicy/pull/265/files. Version 2.8.1 contains several clarifications and minor changes that may affect your organization. You need to be aware of these clarifications and changes to ensure your continued compliance with the MRSP. The following are summaries only of the actual language in the MRSP, and in the event of any conflicting interpretation, the MRSP takes precedence over these summaries:<br />
<br />
* You are required to follow and be aware of discussions in both the Mozilla dev-security-policy forum, https://groups.google.com/a/mozilla.org/g/dev-security-policy, and the CCADB Public List, https://groups.google.com/a/ccadb.org/g/public;<br />
* Your CP, CPS, or combined CP/CPS MUST clearly explain your CA’s domain validation procedures and indicate which subsection of section 3.2.2.4 of the CA/Browser Forum’s Baseline Requirements you are complying with;<br />
* Your CP, CPS, or combined CP/CPS MUST be updated at least every 365 days (more often is expected), and it must be reported in the CCADB in a “timely manner”, and failure to do either of these things will require that you file an incident report in Bugzilla;<br />
* You MUST maintain links to all historic versions of each CP, CPS, or combined CP/CPS from the creation of included CA certificates until such certificate hierarchies are no longer trusted by the Mozilla root store, and if your CA certificate was included by Mozilla before December 31, 2022, then you still must maintain links for “reasonably available historic versions” of your CPs, CPSes, or combined CP/CPSes; and<br />
* In the CCADB, if you elect to publish a JSON array of partial CRLs (rather than the full CRL), then the JSON Array of Partitioned CRLs must contain a critical Issuing Distribution Point extension, which shall include a URI whose value is derived from either the URI as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5) or the URL included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA.<br />
<br />
Finally, participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard user security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you very much for your continued cooperation in this pursuit.<br />
<br />
Regards,<br />
Ben Wilson<br />
Mozilla CA Program Manager<br />
<br />
<br />
<br />
== May 2022 CA Communication and Survey ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a058Z000013UmsDQAS Read-only copy of May 2022 CA Communication and Survey]<br />
** This link is '''Read Only'''. To submit your responses, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2022 CA Communication and Survey' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
=== May 2022 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00160,Q00161 Responses to Item 1] -- Compliance with MRSP v. 2.8<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00162,Q00163 Responses to Item 2] -- "Incidents" include audit findings<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00164,Q00165 Responses to Item 3] -- Auditor membership in ACAB'c and WebTrust<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00166,Q00167,Q00168 Responses to Item 4] -- Online Archival of CPs and CPSes<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00169,Q00170 Responses to Item 5] -- Full CRLs for Intermediate TLS CAs in CCADB<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00171,Q00172 Responses to Item 6.1] -- Sunsetting of SHA1 for S/MIME Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00173,Q00174 Responses to Item 6.2] -- Sunsetting of SHA1 for Other Types of Signing<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00175,Q00176 Responses to Item 7] -- Publicly Disclose Intermediate CA Certificates capable of Issuing TLS or S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00177,Q00178 Responses to Item 8] -- Misissuance of Certificate Transparency Precertificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00179,Q00180,Q00181 Responses to Item 9] -- CRL Revocation Reasons for TLS Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00182,Q00183 Responses to Item 10] -- Public Review of Unconstrained Externally-Operated Subordinate CAs<br />
<br />
== February 2022 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla is engaged in policy review discussions to sunset the use of SHA1 for signing by CAs of CRLs, OCSP responses, and SMIME certificates.<br />
See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/CnVjV-bFcyI/m/TFuWOy2BAwAJ<br />
<br />
(Server certificate signing is governed by the Baseline Requirements, and effective June 1, 2022, OCSP responses related to server certificates cannot be signed with SHA1.)<br />
<br />
One proposal is to remove SHA1 from the list of allowed signing algorithms altogether, but before we do this, I would like your proposed sunset dates for the different types of SHA1 signing you might currently perform--SMIME certificates, ARLs/CRLs, and OCSP responses for SMIME certificates.<br />
<br />
Please participate in this important topic, which is already underway on the Mozilla dev-security-policy list. Let us know about your specific concerns and hurdles that would need to be overcome.<br />
(Some CAs have expressed willingness to quickly convert over to SHA256, while others have expressed that it is not a simple task and will require additional development work.)<br />
<br />
Thanks,<br />
Ben Wilson (bwilson@mozilla.com)<br />
Mozilla Root Store Program<br />
<br />
== April 2021 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a054o00000EL1Fo Read-only copy of April 2021 CA Communication]<br />
** This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br><br />
<br><br />
Mozilla’s Root Store Policy was recently updated to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ version 2.7.1] with an effective date of 1 May 2021. This version contains [https://github.com/mozilla/pkipolicy/pull/223 several changes] that may affect your organization and the auditors who evaluate your PKI. These changes require you to take action to ensure your continued compliance. <br />
<br><br><br />
Please review version 2.7.1 of [https://www.mozilla.org/projects/security/certs/policy/ Mozilla’s Root Store Policy] internally, and with your auditors as well. After you and your auditors have reviewed these new requirements, complete the April 2021 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your practices. Read all survey questions first before beginning to respond. <br />
<br><br><br />
To respond to this survey, [https://ccadb.org/cas/ log in to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 30-April-2021.<br />
<br><br><br />
A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Ben Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== April 2021 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00129,Q00142 Responses to Item 1] -- Review Version 2.7.1 of Mozilla's Root Store Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00131,Q00149,Q00143 Responses to Item 2] -- 398-day reuse period on domain/IP address validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00132,Q00144 Responses to Item 3] -- Clarification about EV Audit Requirements <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00133,Q00145 Responses to Item 4] -- Annual Audit Covering the CA Key Pair Lifecycle <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00136,Q00146 Responses to Item 5] -- Audit Team Qualifications<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00137,Q00147 Responses to Item 6] -- List of Incidents in Audit Reports<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00140,Q00150,Q00148 Responses to Item 7] -- Methods to Demonstrate Key Compromise<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00141,Q00157,Q00159 Responses to Item 8] -- Removal of Old Root CA Certificates (challenges and alternatives)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00156,Q00151,Q00158 Responses to Item 8 timelines] -- Timelines and strategies to replace old, non-BR compliant CA hierarchies and root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00152,Q00155,Q00153 Responses to Item 9] -- Audit Letter Validation on Intermediate Certificates<br />
<br />
== May 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J000042AUSv Read-only copy of May 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>This survey requests your input on current policy and upcoming policy changes that affect you as a participant in Mozilla's CA Certificate Program. <br />
<br><br />
<br>To respond to this survey, [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 31-May 2020. <br />
<br><br />
<br>A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br><br />
<br>Regards,<br />
<br>Kathleen Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== May 2020 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00099,Q00100 Responses to Item 1] -- Impact of COVID-19 Restrictions<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00101,Q00102, Responses to Item 2] -- Mozilla Root Store Policy version 2.7 Requirements and Deadlines <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00103,Q00104 Responses to Item 3] -- Reducing Maximum Validity Period for TLS Certificates <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107 Responses to Sub Item 3.1] -- Limit TLS Certificates to 398-day validity<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00108,Q00109,Q00110 Responses to Sub Item 3.2] -- Limit re-use of domain name and IP address verification to 398 days<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00111,Q00112 Responses to Item 4] -- CA/Browser Forum Ballot for Browser Alignment <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00113,Q00114,Q00115 Responses to Sub Item 4.1] -- CA/Browser Forum defined-policy OID in Subscriber Cert certificatePolicies<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00116,Q00117,Q00118 Responses to Sub Item 4.2] -- Byte-for-byte Identical Issuer and Subject Distinguished Names<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00119,Q00120,Q00121 Responses to Sub Item 4.3] -- Text-searchable PDF Audit Statements<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00122,Q00123,Q00124 Responses to Sub Item 4.4] -- OCSP Requirements<br />
<br />
== January 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003waNOW Read-only copy of January 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/ updated]. The 2.7 version went into effect on 1-January 2020. This version contains a [https://github.com/mozilla/pkipolicy/pull/199/files number of changes] that may affect your organization and will require you to take action to comply. Please review Mozilla’s updated Root Store Policy and complete the January 2020 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your Certificate Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘January 2020 CA Communication' survey. Please enter your response by 31 January 2020.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== January 2020 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00082,Q00083 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00084,Q00085,Q00098 Responses to Action 2] -- Update CP/CPS <br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00086,Q00087,Q00097 Responses to Action 3] -- Include EKUs in All End-entity Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00088,Q00089 Responses to Action 4] -- Ensure Audit Reports are Properly Formatted<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00090,Q00096,Q00091 Responses to Action 5] -- Resolve Audit Issues with Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00092,Q00093 Responses to Action 6] -- Incident Reporting<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00094,Q00095 Responses to Action 7] -- Compliance with BRs<br />
<br />
== November 2018 CA Communication (Underscores in dNSNames) ==<br />
On November 12, 2018, the following message was sent to all CAs in the Mozilla program, alerting them to CA/Browser Forum SC12 that established a brief sunset period for the use of underscore characters in dNSNames in publicly-trusted TLS certificates.<br />
<br /><br />
<br />
Dear Certification Authority,<br />
<br />
The CA/Browser Forum recently approved [1] a clarification to the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (BRs) that may affect you. Domain names containing underscore (“_”) characters are not permitted to be encoded as dNSName types in the subjectAlternativeName (SAN) field of BR-compliant certificates. This requirement derives from section 4.2.1.6 of RFC 5280 that the BRs require CAs to comply with by reference.<br />
<br />
Section 7.1.4.2.1 of the BRs will add the following language that clarifies the existing requirement and adds a short time in which CAs must discontinue the use of underscore characters in dNSNames:<br />
-----<br />
Prior to April 1, 2019, certificates containing underscore characters (“_”) in domain labels in dNSName entries MAY be issued as follows:<br />
* dNSName entries MAY include underscore characters such that replacing all underscore characters with hyphen characters (“-“) would result in a valid domain label, and;<br />
* Underscore characters MUST NOT be placed in the left most domain label, and;<br />
* Such certificates MUST NOT be valid for longer than 30 days.<br />
<br />
All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019.<br />
<br />
After April 30, 2019, underscore characters (“_”) MUST NOT be present in dNSName entries.<br />
-----<br />
This new language will go into effect on December 10, 2018 when the IPR review period for ballot SC12 [1] is completed. At that time, CAs must be prepared to stop issuing publicly-trusted TLS certificates containing the underscore character in any dNSName with validity periods of more than 30 days.<br />
<br />
As a participant in Mozilla's CA Certificate Program, we want you to be aware of this important change, and ask that you take any necessary steps to comply. No further action related to this change is requested at this time.<br />
<br />
Regards,<br />
<br />
Wayne Thayer<br />
Mozilla CA Program Manager<br />
<br />
[1] https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/<br />
<br />
=== November 2018 Responses ===<br />
* No survey was included in this CA Communication<br />
<br />
== September 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL Read-only copy of September 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'September 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/ updated]. The 2.6.1 version went into effect on 1-July, 2018. This version contains a number of changes that may affect your organization and will require you to take action to comply. This survey also contains information regarding other recent and upcoming changes that may affect your Certification Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘September 2018 CA Communication' survey. Please enter your response by 30-September 2018.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== September 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00068,Q00069 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00070,Q00071 Responses to Action 2] -- Update CP/CPS<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00072,Q00073 Responses to Action 3] -- Transition to Separate Intermediate Certificates for SSL and S/MIME<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00074,Q00075 Responses to Action 4] -- Ensure Audit Reports comply with Mozilla’s Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00076,Q00077 Responses to Action 5] -- Discontinue use of BR Validation Methods 3.2.2.4.1 and 3.2.2.4.5<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00078,Q00079 Responses to Action 6] -- Disclose Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00080,Q00081 Responses to Action 7] -- Submit TLS Certificates to CT Logs for Mozilla's CRLite<br />
<br />
== January 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mqMFN Read-only copy of January 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br /><br /><br />
2018 has already generated some important news for Certification Authorities, and as a result we are sending this message to ensure that every CA in the Mozilla program is aware of current events and impending deadlines.<br />
<br /><br /><br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.<br />
<br /><br /><br />
To respond to this survey, login to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Please enter your response by 9-February 2018.<br />
<br /><br /><br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br /><br /><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br /><br /><br />
Regards,<br /><br />
Wayne Thayer<br /><br />
Mozilla CA Program Manager<br /><br />
<br />
=== January 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00056,Q00057 Responses to Action 1] -- Disclose Use of Methods 3.2.2.4.9 or 3.2.2.4.10 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00058,Q00059 Responses to Action 2] -- Disclose Use of Methods 3.2.2.4.1 or 3.2.2.4.5 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00060,Q00061 Responses to Action 3] -- Disclose All Non-Technically-Constrained Subordinate CA Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00062,Q00063 Responses to Action 4] -- Complete BR Self Assessment<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00064,Q00065 Responses to Action 5] -- Update CP/CPS to Comply with version 2.5 of Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00066,Q00067 Responses to Action 6] -- Reduce SSL Certificate Validity Periods to 825 Days or Less by March 1, 2018<br />
<br />
== November 2017 CA Communication ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7 Read-only copy of November 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority, <br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, login to the [http://ccadb.org/cas Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Please enter your response by December 15, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be [[CA/Communications|automatically and immediately published]] by the CCADB system.<br />
<br />
Participation in [[CA|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== November 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00035,Q00036 Responses to Action 1] -- Full compliance with version 2.5 of [https://www.mozilla.org/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00037,Q00044 Responses to Action 2] -- non-technically-constrained intermediate certificates must be [http://ccadb.org/cas/intermediates disclosed in CCADB] within one week of creation. '''New requirements''' for [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#technically-constrained technical constraints on intermediate certificates issuing S/MIME certificates].<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00038,Q00045 Responses to Action 3] -- Annual updates via [http://ccadb.org/cas/updates CCADB Audit Cases]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00050,Q00051 Responses to Action 4] -- Reiterate [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#audit-parameters audit requirements] and '''penalty for incomplete audit statements'''<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00039,Q00046 Responses to Action 5] -- Perform a [[CA/BR_Self-Assessment|BR Self Assessment]]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00042,Q00048 Responses to Action 6] -- Provide tested email address for [https://ccadb.my.salesforce-sites.com/mozilla/CAInformationReport Problem Reporting Mechanism]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00040,Q00047 Responses to Action 7] -- Follow new developments and effective dates for [http://tools.ietf.org/html/rfc6844 Certification Authority Authorization (CAA)]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00052,Q00053 Responses to Action 8] -- Check [https://groups.google.com/d/msg/mozilla.dev.security.policy/4kj8Jeem0EU/GvqsgIzSAAAJ issuance of certs to .tg domains] from October 25 to November 11, 2017.<br />
<br />
== May 2017 - Announcing CCADB Changes ==<br />
<br /><br />
Subject: Common CA Database (CCADB) changes May 19-21, 2017<br />
<br /><br /><br />
Message:<br /><br /><br />
Dear Certification Authority,<br />
<br /><br />
<br /><br />
The Common CA Database (CCADB) will undergo the following changes this weekend, May 19 to May 21. During this time, the old URLs listed below will stop working, and there will be some time when the CCADB is in read-only mode.<br />
<br /><br />
<br /><br />
On May 19 the following three breaking changes are planned, meaning that the old URLs will no longer work. Any links or bookmarks to these URLs will need to be updated. After these changes are made, I will also update Mozilla's wiki pages to point to the new URLs.<br />
<br /><br />
<br /><br />
1) The CA login page and the domain CAs see when they are logged into the CCADB will change.<br />
<br /><br />
https://mozillacacommunity.force.com/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb.force.com/<br />
<br /><br />
<br /><br />
2) The links to reports that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/CA/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/mozilla/<br />
<br /><br />
<br /><br />
3) The links to CA communication responses that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/Communications<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/Surveys<br />
<br /><br />
<br /><br />
Then on May 21 between 12am and 4am PDT, the CCADB will be in read-only mode while Salesforce performs an instance refresh to upgrade the infrastructure supporting the CCADB instance in their data centers.<br />
<br /><br />
<br /><br />
Regards,<br />
<br /><br />
Kathleen<br />
<br />
== April 2017 ==<br />
<br />
Note: The deadline to reply to this survey has [https://groups.google.com/d/msg/mozilla.dev.security.policy/03rdTdnm7iw/NQUHmWOcEAAJ been extended] by one week, to May 5, 2017.<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000003WrzBC Read-only copy of April 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [https://ccadb.force.com/CustomLogin login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA:IncludedCAs|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, [https://mozillacacommunity.force.com/CustomLogin login to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Please enter your response by April 28, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br />
In addition to responding to the action items in this survey, we are instituting a program requirement that you follow discussions in the [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] forum, which includes discussions about upcoming changes to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy], questions and clarification about policy and expectations, root certificate [[CA|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] or other program requirements. You are not required to contribute to those discussions, only to be aware of them. However, we hope you will participate and help shape the future of Mozilla's CA Certificate Program.<br />
<br />
Participation in [[CA:Overview|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== April 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [[CA:CommonCADatabase|Common CA Database]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00015,Q00030 Responses to Action 1] -- Domain Validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 2 and Action 10] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00022,Q00029 Responses to Action 3] -- Updated Mozilla CA Certificate Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00017,Q00031 Responses to Action 4] -- Audit Statements, annual updates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00018,Q00032 Responses to Action 5] -- Audit Statement Contents<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00021,Q00033 Responses to Action 6] -- Qualified Audit Statements<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00019 Responses to Action 7] -- BR Compliance Bugs<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 Responses to Action 8] -- Confirm Completion of Previous Commitments<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00027 Responses to Action 9] -- Registration Authorities<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 10 and Action 2] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00023 Responses to Action 11] -- Certification Authority Authorization (CAA)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00028 Responses to Action 12] -- Problem Reporting Mechanism<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00024 Responses to Action 13] -- SHA-1 and S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00034 Responses to Action 14] -- Certificate Validity Periods in TLS/SSL Certs<br />
<br />
== March 2016 ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000000iHdtx Read-only copy of March 2016 CA Communication]<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program, by April 22, 2016.<br />
<br />
To respond to this survey, please login to the [[CA:SalesforceCommunity|CA Community in Salesforce]], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'March 2016 CA Communication' survey. Please enter your response by April 22, 2016. <br />
<br />
A compiled list of CA responses to the survey action items will be [[CA:Communications#March_2016_Responses|automatically and immediately published]] by Salesforce.<br />
<br />
In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the [https://groups.google.com/forum/#!forum/mozilla.dev.security.policy mozilla.dev.security.policy] forum, which includes discussions about [[CA:CertificatePolicyV2.3|upcoming changes to Mozilla's CA Certificate Policy]], questions and clarification about policy and expectations, root certificate [[CA:Schedule|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements]. Your contributions to the discussions will help shape the future of [[CA:Overview|Mozilla's CA Certificate Program]].<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Mozilla CA Program Manager<br />
<br />
=== March 2016 Responses ===<br />
<br />
The following links are automatically generated from data in the [[CA:SalesforceCommunity|CA Community in Salesforce]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommSummaryReport?CommunicationID=a05o000000iHdtx CA Responses to March 2016 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00001,Q00013 Responses to Action #1a] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00002,Q00014 Responses to Action #1b] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 Responses to Action #1c] -- SHA-1 Deprecation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 Responses to Action #2] -- Entering intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00005 Responses to Action #3] -- Entering revoked intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00006&QuestionIdForText=Q00007 Responses to Action #4] -- [[SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix|Removing workarounds]] to compatibility issues that were encountered involving certificates that did not conform to the Baseline Requirements. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00008 Responses to Action #5] -- Plans to remove old/retired root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00009 Responses to Action #6] -- Confirmation of understanding that all certificates, including test certificates, must conform to stated policies<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00012 Responses to Action #7] -- [[CA:RootTransferPolicy|Mozilla's Root Transfer Policy]]<br />
<br />
== May 2015 ==<br />
<br />
Dear Certification Authority, <br />
<br />
This email requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by June 5, 2015, with your response to the action items by clicking on the survey link below. A compiled list of CA responses to these action items will be published. <br />
<br />
Certification Authority: <CA Account Name><br />
<br />
Your Survey Link: <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/TakeSurvey?id=a04o000000M89RCAAZ&cId=&caId=none Survey Link] -- '''IMPORTANT: CA's do NOT use the link in this wiki page! This link will NOT record your response. Please use the link that was emailed to you.'''<br />
<br />
Please use the above link to read and respond to the action items. Note that you may access the above link multiple times to update your responses.<br />
<br />
Additionally, we plan to update Mozilla's CA Certificate Policy soon, and will be discussing proposed policy updates in the mozilla.dev.security.policy forum, https://www.mozilla.org/en-US/about/forums/#dev-security-policy. We encourage you to monitor the discussions to see how the updates will impact you, and your participation in the discussions will help shape the policy updates.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, <br />
Mozilla <br />
CA Program Manager<br />
<br />
=== May 2015 Responses ===<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationSummaryReport?CommunicationId=a04o000000M89RCAAZ CA Responses to May 2015 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%233:%20After%20January%201,%202016 Responses to Action #3] -- SHA-1 Deprecation Plans<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%234:%20Workarounds%20were%20implemented Responses to Action #4] -- Removing workarounds implemented to allow mozilla::pkix to handle the things listed here https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%235:%20We%20wish%20to%20understand%20what%20support Responses to Action #5] -- IPv6 survey<br />
<br />
== May 2014 ==<br />
<br />
Subject: Mozilla Communication: Action requested by May 30, 2014<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by May 30, 2014, with your response to these action items. A compiled list of CA responses to the following action items will be published. <br />
<br />
CA Certificate Inclusion Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/<br />
<br />
CA Certificate Maintenance Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/<br />
<br />
Spreadsheet of included root certificates: http://www.mozilla.org/about/governance/policies/security-group/certs/included/<br />
<br />
1) Ensure that Mozilla’s [http://www.mozilla.org/about/governance/policies/security-group/certs/included/ spreadsheet of included root certificates] has the correct link to your most recent audit statement, and that the date of the audit statement is correct. As per [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/ Mozilla's CA Certificate Maintenance Policy], we require that all CAs whose certificates are distributed with our software products provide us an updated statement annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties. To notify us of an updated statement of attestation, send email to certificates@mozilla.org or [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates submit a bug report] into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "mozilla.org" product.<br />
If you are not proactively sending Mozilla your updated audit statements, please create a process to do so.<br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent audit statement, and the audit statement date is correct.<br />
* B) Here is the most recent audit statement for our certificates that are included in Mozilla’s CA program: <insert link here> <br />
* C) We plan to send Mozilla our current audit statement by <insert date here>.<br />
* D) We do not have a current audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
2) Send Mozilla the link to your most recent [https://cabforum.org/about-the-baseline-requirements/ Baseline Requirements] audit statement. Details about Mozilla's audit requirements are listed in section 11 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy]. The Baseline Requirements audit statement should also be proactively sent to Mozilla each year, along with the other audit statements as described in action #1. <br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent Baseline Requirements audit statement.<br />
* B) Here is the most recent Baseline Requirements audit statement for our certificates that are included in Mozilla’s CA program: <insert link here>. <br />
* C) We plan to send Mozilla our current Baseline Requirements audit statement by <insert date here and explain reason for delay>.<br />
* D) The websites (SSL/TLS) trust bit is not enabled for our certificates that are included in Mozilla's CA program.<br />
* E) We do not have a current Baseline Requirements audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
3) Test Mozilla's new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed. <br />
The new Certificate Verification library (mozilla::pkix) was announced here: https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ .<br />
Mozilla::pkix includes some changes in support of current best practices and policies, as listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes .<br />
How to test: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing .<br />
<br />
Please respond with one of the following: <br />
* A) We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix.<br />
* B) We have found the following issues when testing certificates in our CA hierarchy with mozilla::pkix. <descriptions or Bugzilla bug numbers, related URLs and/or certificates><br />
* C) We are testing certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and plan to send Mozilla our results by <insert date here, must be before June 30, 2014>.<br />
<br />
4) Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix<br />
<br />
Please respond with one of the following: <br />
* A) We have not and will not issue certificates with any of the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page.<br />
* B) We have previously issued certificates with the following problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page: <list the problems that needed to be fixed>. The last of those certificates expire <insert dates here, one date per problem>. We will not issue new certificates with the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page as of this date: <date when your operations will be updated, no later than June 30, 2014><br />
<br />
5) Send Mozilla information about your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, as per Items #8, 9, and 10 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy].<br />
<br />
Please provide a URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, and contains the required information according to section 10 of Mozilla's CA Certificate Inclusion Policy. If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificates" component of the "mozilla.org" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates)<br />
<br />
Additionally, please respond with one of the following: <br />
* A) All subordinate CA certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy.<br />
* B) We request an extension for the following specific subordinate CA certificates, because these subordinate CAs need more time to transition from their legacy systems to their new CA hierarchy: <list of issuer hash, issuer public key hash, and certificate serial number>. For each subordinate CA who needs to operate in their legacy design a little longer, the attached document explains the reason that continued operation is needed and their target date for resolution. <attach document(s) to response><br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== May 2014 Responses ===<br />
<br />
[https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml CA Responses to May 2014 Communication]<br />
<br />
== July 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by August 16, 2013<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s CA Certificate Policy has been updated with a few important changes. This update was motivated by security concerns regarding ICANN granting applied-for new gTLD strings. Additionally, we want to make it very clear that there will be serious consequences if it is found that a CA has knowingly or intentionally mis-issued certificates chaining to trust anchors in Mozilla’s program.<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of applications.<br />
<br />
Please carefully review the following wiki page for information about the changes introduced in version 2.2 of Mozilla’s CA Certificate Policy.<br />
<br />
https://wiki.mozilla.org/CA:CertificatePolicyV2.2<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by August 16, 2013, with your response to the following action items. <br />
<br />
1) Update your CA operations and policies to include the CA/Browser Forum’s Baseline Requirement #11.1.4 regarding new gTLD domains, and subscribe to ICANN’s new gTLD Registry Agreement notification mailing list at: https://mm.icann.org/mailman/listinfo/gtldnotification<br />
<br />
Please respond with one of the following:<br />
* A) No action required, because we have not and will not issue SSL certificates with internal or private domain names chaining up to root certificates that are included in Mozilla’s program.<br />
* B) We have issued or may issue SSL certificates with internal or private domain names that chain up to root certificates that are included in Mozilla’s program, so we are implementing Baseline Requirement #11.1.4, and will subscribe to ICANN’s notification service regarding applied-for-gTLD strings. We plan to have this completed by September 16, 2013.<br />
* C) We have already implemented Baseline Requirement #11.1.4, and have subscribed to ICANN’s notification service regarding applied-for-gTLD strings.<br />
<br />
2) Review your CA operations and customers to ensure that there are no certificates chaining up to your trust anchors that are included in Mozilla’s program that may be used for MITM or “traffic management” of domain names or IP addresses that the certificate holder does not own or control. [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla’s CA Certificate Enforcement Policy] has been updated to make it clear that Mozilla will not tolerate this use of publicly trusted certificates. <br />
<br />
Please respond with:<br />
* “We have reviewed Mozilla’s updated CA Certificate Enforcement Policy and understand that knowing or intentional mis-issuance of a certificate is expressly against Mozilla’s CA Certificate Policy and could result in removal of all of our certificates from Mozilla’s products.”<br />
<br />
3) Ensure that your CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current, including links to the CP/CPS documents, audit statements, and test websites. Mozilla will be adding a column to this spreadsheet to indicate the date of the most recent audit statement for each root certificate.<br />
<br />
http://www.mozilla.org/projects/security/certs/included/index.html<br />
<br />
Please respond with one of the following:<br />
* A) Our CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current for all of our included certificates.<br />
* B) Here is the current information for our certificates that are included in Mozilla’s program: <insert data here><br />
<br />
4) Complete the action items from Mozilla’s January CA Communication.<br />
* https://wiki.mozilla.org/CA:Communications#January_10.2C_2013<br />
* https://wiki.mozilla.org/CA:Communications#January_2013_Responses<br />
<br />
Please respond with one of the following:<br />
* A) Our recorded response to the January CA Communication is complete and correct.<br />
* B) We have the following updated status for our response to the January CA Communication: <insert data here><br />
<br />
5) Follow discussion about the changes to policy and code that Mozilla will be making in order to improve how revocation checking is handled in Firefox. Discussions will be held in the mozilla.dev.security.policy forum, and descriptions of the changes that will be considered for both policy and code will be provided here: https://wiki.mozilla.org/CA:ImprovingRevocation<br />
As part of this effort, Mozilla will be implementing a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker. More information will follow, and policy will be added soon to require CAs to send Mozilla revocation information. We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
<br />
=== July 2013 Responses ===<br />
<br />
* [https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGR1TmZLZnJ1RThHRDcwMDJRaXZicFE&output=html CA Responses to July 2013 Communication]<br />
<br />
== January 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by January 31, 2013. <br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by January 31, 2013, with your response to these action items. A compiled list of CA responses to the following action items will be published.<br />
<br />
1) Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations. <br />
<br />
Version 2.1 of Mozilla’s CA Certificate Policy is in final review, and will be ratified and published in Q1 of 2013. There are changes to the policy that may impact your current operations, so we encourage you to review the changes that are indicated in red or bold text here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html<br />
<br />
There will be a transition period for CAs to bring existing customers into compliance with the new policy, as described here:<br />
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1<br />
<br />
Please respond to this action item with one of the following:<br />
* a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.<br />
* b) The proposed changes to Mozilla’s CA Certificate Policy impact our CA operations, but we will be able to complete the transition within the allotted time frame.<br />
* c) We will not be able to update our CA operations to comply with the proposed version 2.1 of Mozilla’s CA Certificate Policy within the allotted time frame, because <insert reason(s)>. We plan to meet the new requirements by <insert date>.<br />
<br />
2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements.<br />
<br />
The CA/Browser Forum (http://www.cabforum.org) released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which became effective on July 1, 2012. It is our expectation that as of January 2013 CA issuance of SSL certificates will be audited against these Baseline Requirements as well as the acceptable audit criteria that are listed in Mozilla’s CA Certificate Policy.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.<br />
* b) Not applicable, because we do not issue SSL certificates.<br />
* c) We are working towards compliance with the CA/Browser Forum’s Baseline Requirements, but we need to complete <insert list of tasks>. We plan to have this completed by <insert date>.<br />
<br />
3) Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit.<br />
<br />
Due to the recent incident in which a mis-issued intermediate certificate was found (https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates), we are concerned that CAs may have responded to our last communication based on their policies, rather than checking their certificate databases. Therefore, we request that you scan your certificate database and inform Mozilla if you find any un-expired intermediate certificates in your CA hierarchy that should not be trusted. In your reply, please attach all such intermediate certificates, even if you have already revoked them.<br />
<br />
While you are scanning your certificate databases to ensure that all certificates with basicConstraints:CA:TRUE have been issued in accordance with your CPS, please also check for compliance with the following practices.<br />
* All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.<br />
* All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.<br />
* All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration).<br />
* All end-entity certificates with RSA key sizes smaller than 2048 bits expire no later than December 2013.<br />
* Certificates are not issued with sequential serial numbers. If it is found that certificates have been issued with contiguous serial numbers, then the subject of those certificates must contain unpredictable data that is not under the control of the certificate subscriber.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* b) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
* c) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* d) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
<br />
4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name.<br />
<br />
The CA/Browser Forum’s Baseline Requirements state: <br />
“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 Server 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.”<br />
<br />
This practice is being eliminated for security reasons, so we encourage all CAs to begin working with their customers to transition to alternative arrangements, and to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names as soon as possible rather than waiting until the deadline.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names.<br />
* b) We plan to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names by <insert date>.<br />
<br />
5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it. We expect this website to endure for the lifetime of the root, or until you notify us of an alternative URL. The website does not need to support high traffic loads or have greater than 99% uptime.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson, <br />
Module Owner of Mozilla's CA Certificates Module <br />
<br />
=== January 2013 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dHdISmM3c05tb1dMQjlJclJqS21QNmc&output=html CA Responses to January 2013 Communication] -- Contains two spreadsheets: "Action Item Responses" and "Test Website URLs".<br />
<br />
== February 2012 ==<br />
<br />
Subject: Mozilla Communication: Action requested by March 2, 2012<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Please reply by March 2, 2012, to confirm completion of the following actions or state when these actions will be completed.<br />
<br />
1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012. For each subordinate CA that is revoked, send me:<br />
* a) The certificate that signed the subCA. If it is a root certificate in NSS, then the root certificate's subject and SHA1 fingerprint.<br />
* b) The Serial Number of the revoked certificate.<br />
* c) The CRL that contains the serial number of the revoked certificate.<br />
<br />
As a CA in Mozilla’s root program you are ultimately responsible for certificates issued by you and any intermediate CAs that chain up to your roots. After April 27, 2012, if it is found that a subordinate CA is being used for MITM, we will take action to mitigate, including and up to removing the corresponding root certificate. Based on Mozilla’s assessment, we may also remove any of your other root certificates, and root certificates from other organizations that cross-sign your certificates.<br />
<br />
I am planning to publish a compiled list of CA responses to all of the action items in this communication. Therefore, I recommend responding to action item #1 with one of the following choices:<br />
* a) Does not apply, because we do not issue subCA certificates to third parties.<br />
* b) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
* c) We are reviewing all of our subCAs and will take the necessary action by <date>. <br />
* d) We have revoked such subCA certificates, and here is the requested information.<br />
* e) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM. ''(Note: This option was added after the communication was sent.)''<br />
<br />
2) If you issue subordinate CAs to third parties or your CP/CPS permits you to do so in the future, please add a statement to your CP/CPS committing that you will not issue a subordinate certificate that can be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control. Send me the URL to the updated document(s) and the impacted sections or page numbers. <br />
<br />
3) Please scan all of your EV SSL certificates and revoke any that do not meet the EV requirements. This includes, but is not limited to maximum validity period of the certificate, subject naming, minimum key sizes, required extensions, and maximum expiration time of OCSP responses.<br />
<br />
4) Certificates chaining to root certificates in Mozilla’s root program should not have MD5 algorithms or RSA keys shorter than 1024 bits long. Please scan the certificates chaining to your root certificates in NSS, and revoke any certificates that contain small key sizes or MD5 algorithms. <br />
<br />
5) The CA/Browser Forum has released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which is available here: http://www.cabforum.org/. Discussions are in progress in the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate Policy to add a requirement that CAs also meet these baseline requirements for issuance of SSL/TLS certificates. Please contribute to the discussions in the mozilla.dev.security.policy forum, and update your operations and documentation as needed to meet the baseline requirements by the effective date of July 1, 2012.<br />
<br />
The currently proposed updates to Mozilla’s CA Certificate Policy are here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== February 2012 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGxsWlZEdGFDaW9JTlNTUGxBNWhqSlE&output=html CA Responses] -- spreadsheet of the responses to the action items of the CA Communication that was sent on February 17, 2012.<br />
<br />
Response Key:<br />
* IP = "In Progress"<br />
* ? = I need further clarification on the response<br />
* N/A = "Not Applicable"<br />
** N/A for Action #2 means that the CP/CPS does not allow for externally-operated subCAs.<br />
** N/A for Action #3 means that the CA is not issuing EV certs under the roots included in NSS.<br />
* Responses to action #1 can be one or more of the following. If option C is listed, there is also a date by which the CA plans to complete their investigation and provide further information.<br />
** A) Does not apply, because the CA does not have externally-operated subCAs chaining to roots in NSS.<br />
** B) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
** C) The CA is reviewing all of their subCAs and will take the necessary action by <date>.<br />
** D) The CA has revoked such subCA certificates, and provided the requested information.<br />
** E) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
<br />
== September 2011 ==<br />
<br />
Subject: Mozilla Communication: Immediate action requested<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Mozilla recently removed the DigiNotar root certificate in response to their failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates (https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up). If you ever have reason to suspect a security breach or mis-issuance has occurred at your CA or elsewhere, please contact security@mozilla.org immediately.<br />
<br />
Please confirm completion of the following actions or state when these actions will be completed, and provide the requested information no later than September 16, 2011:<br />
<br />
1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs.<br />
<br />
2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included<br />
<br />
3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance.<br />
<br />
4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked.<br />
<br />
5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either:<br />
<br />
a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical)<br />
<br />
OR<br />
<br />
b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public 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 subordinate CA's internal operations.<br />
<br />
Each action requested above applies both to your root and to these third parties.<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your participation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== April 2011 ==<br />
<br />
Subject: Mozilla Communication: Policy Discussions are in Progress that may Impact Your CA<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to three important items that we would like to bring to your attention.<br />
<br />
1) The CA/Browser Forum has published a final draft of the document "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." We are now hosting a discussion about this document in the mozilla.dev.security.policy forum. For more information, see http://cabforum.org/. <br />
The document is here: http://cabforum.org/Baseline_Requirements_Draft_30b.pdf<br />
<br />
Mozilla supports the CA/Browser Forum’s efforts in this area. After version 1.0 of the CA/Browser Forum’s Baseline Requirements document is published, we will have a discussion to add a requirement to the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/) that CAs include the CA/Browser Forum Baseline Requirements in their policies, practices, and audits. Therefore, we urge you to review the draft of the Baseline Requirements, assessing the impact to your CA policies and practices, and participate in the current discussions about these requirements. The CA/Browser Forum has set the duration of this discussion to 45 days from April 11.<br />
<br />
2) Mozilla has begun discussions about the Phase 2 items to be considered for updating the Mozilla CA Certificate Policy, https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. The current discussions are focused on RAs and Subordinate CAs. We recommend that you monitor and contribute to these discussions so that you are aware of how the potential changes to the Mozilla CA Certificate Policy may impact you.<br />
<br />
3) As per previous communications, we will implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== February 2011 ==<br />
<br />
Subject: Mozilla Communication: Version 2.0 of Mozilla CA Certificate Policy has been published<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla has ratified and published Version 2.0 of the Mozilla CA Certificate Policy. <br />
<br />
The new policy is here:<br />
http://www.mozilla.org/projects/security/certs/policy/ <br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than August 8, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. Now that this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== January 2011 ==<br />
<br />
Subject: Mozilla Communication: Major Pending Update to Mozilla CA Certificate Policy<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla is preparing to update the Mozilla CA Certificate Policy. The forthcoming changes will come in multiple phases, and the first phase is nearly complete. Discussion about the first phase of changes has proceeded for several months in the mozilla.dev.security.policy forum. Version 2.0 of the policy, reflecting the first phase of updates, is now under final review. Mozilla expects it to be ratified by January 31, 2011.<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than April 30, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
The current policy (version 1.2) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/<br />
<br />
The new policy (version 2.0) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/<br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945#c3<br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. After this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== October 2010 ==<br />
<br />
Subject: Mozilla Communication to CAs regarding Policy updates, October 2010<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to five important points that we would like to bring to your attention.<br />
<br />
1) Mozilla has started a project to update the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/). The proposed changes may impact the operation of your root certificates that are included in NSS. Therefore, we request that all CAs participate in the discussions, which will be held in the Mozilla.dev.security.policy forum, http://www.mozilla.org/about/forums/#dev-security-policy. For information about the potential changes, please see https://wiki.mozilla.org/CA:CertPolicyUpdates.<br />
<br />
2) As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must provide an OCSP capability for end-entity certificates that are issued after Dec 31, 2010. Mozilla is considering technical ways to enforce this OCSP requirement such that if Firefox cannot obtain a valid response from the OCSP responder, then the certificate will not be given EV treatment. We are considering requiring the end-entity certificate to provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23<br />
Additionally, we urge all CAs to provide OCSP for all certs, even when they are not EV.<br />
<br />
3) We expect that all new certificates contain randomness (preferably in the serial number), especially when using the SHA-1 hash function or an RSA key size smaller than 2048 bits. For more information, please see http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period and serial number prediction”, and section 7, “Countermeasures.”<br />
<br />
4) As per the NIST guidelines, it is our expectation that all CAs are transitioning from issuing certs with RSA key sizes smaller than 2048 bits. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
5) We are planning to implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certs. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== May 2010 ==<br />
<br />
Subject: Mozilla Communication: Acceptable Addresses for Domain Control Validation<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to some changes that we are proposing to make to Mozilla’s CA Certificate Policy.<br />
<br />
Section 7 of the Mozilla CA Certificate Policy states: “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;”<br />
<br />
Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. Offering too many options for the email address prefix increases the risk of issuing a certificate to a subscriber who does not own/control the domain. Therefore, the list of email address prefixes should be limited.<br />
<br />
Mozilla is proposing to restrict the set of verification addresses that may be used for domain validation to the following list or a subset of it. Mozilla’s goal is to strike a balance between flexibility and safety.<br />
<br />
Accepted addresses for domain validation challenge-response email:<br />
* root@domain<br />
* admin@domain<br />
* administrator@domain<br />
* webmaster@domain<br />
* hostmaster@domain<br />
* Plus any address listed in the contact fields of the domain's WHOIS record.<br />
<br />
We hope that this restriction, when implemented consistently across CAs, will not cause discrimination or hardship. We are seeking feedback on whether this is the case. We invite you to contribute your feedback to a discussion about this new restriction in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.<br />
<br />
http://www.mozilla.org/community/developer-forums.html<br />
https://lists.mozilla.org/listinfo/dev-security-policy<br />
news://news.mozilla.org/mozilla.dev.security.policy<br />
<br />
The discussion thread is called “Domain Control validation” and “Acceptable Addresses for Domain Control Validation”.<br />
<br />
We have also added this information to our wiki page:<br />
https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs<br />
<br />
We look forward to your contributions to this discussion.<br />
<br />
Regards,<br />
Kathleen Wilson<br />
<br />
== November 2009 ==<br />
<br />
Subject: Mozilla Communication: SSL certificates issued to internal domain names <br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla I am contacting you in regards to root certificates that you currently have included by default in Mozilla products, such as the Firefox browser. <br />
<br />
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. <br />
<br />
Section 7 of Mozilla’s CA Certificate Policy states that CAs need to take “reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate.” There are different interpretations as to what this means in regards to internal domain names such as non-valid TLDs, hostnames, and IP addresses. However, there is consensus that there are problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks. Mozilla is currently discussing whether the CA Certificate Policy should be updated to add more explicit requirements on this practice, or even to disallow it altogether.<br />
<br />
In the light of the current situation, Mozilla requests that you take the following actions.<br />
<br />
1) Perform an internal audit to look for certificates that have been issued within your CA hierarchy which have .int domain names in the Common Name and/or as DNS Names in the subjectAlternativeName. For each of these certificates, check to see if the certificate subscriber owns/controls that domain name, and revoke the certificate if they do not own/control that domain name.<br />
<br />
2) Review your controls/procedures (both internally and your RAs) for correct identification of internal and external domain names and verification that subscribers own/control the domain name to be included in their certificate. Please refer to these documents:<br />
a) Section 7 of Mozilla’s CA Certificate Policy<br />
(http://www.mozilla.org/projects/security/certs/policy/)<br />
b) https://wiki.mozilla.org/CA:Recommended_Practices<br />
c) https://wiki.mozilla.org/CA:Problematic_Practices<br />
<br />
Mozilla also recommends that you <br />
1) Update your training procedures to ensure that all validation staff are aware of this situation. <br />
2) Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates.<br />
3) Maintain your own list of ICANN approved TLDs that are eligible to be used for domains in certificates issued within your CA hierarchy. If a new TLD is created by IANA, make an explicit decision whether or not to add the new TLD to your list.<br />
http://www.icann.org/en/registries/top-level-domains.htm<br />
<br />
Mozilla strongly encourages you to take prompt action in order to ensure the continued security and trust-ability of your CA service. <br />
<br />
Kathleen Wilson</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Communications&diff=1247827CA/Communications2023-09-02T23:35:47Z<p>Kathleen Wilson: minor updates</p>
<hr />
<div>The following are communications that have been sent to Certification Authorities participating in [[CA | Mozilla's root program.]] If you have questions regarding these communications, please first review related discussions in the Mozilla dev-security-policy forum. If your questions cannot be answered in that forum, then please send email to certificates@mozilla.org.<br />
<br />
== August 2023 CA Communication and Survey ==<br />
Communication and Survey: <br />
https://docs.google.com/document/d/1ieXSt3rJyOSopJnDp4wFGSugpk6pt5pJFJ55rkpb6Ks/edit?usp=sharing <br />
<br />
Read-only view of the survey: <br />
https://docs.google.com/document/d/1ieXSt3rJyOSopJnDp4wFGSugpk6pt5pJFJ55rkpb6Ks/edit?usp=sharing<br />
<br />
Survey Responses:<br />
https://docs.google.com/spreadsheets/d/16NMWm9No4MFkC-q9pxLCOwJwvV9sKLen17wnwodu4AU/edit?usp=sharing<br />
<br />
== February 2023 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s Root Store Policy (MRSP) was recently updated to version 2.8.1 with an effective date of February 15, 2023, https://github.com/mozilla/pkipolicy/pull/265/files. Version 2.8.1 contains several clarifications and minor changes that may affect your organization. You need to be aware of these clarifications and changes to ensure your continued compliance with the MRSP. The following are summaries only of the actual language in the MRSP, and in the event of any conflicting interpretation, the MRSP takes precedence over these summaries:<br />
<br />
* You are required to follow and be aware of discussions in both the Mozilla dev-security-policy forum, https://groups.google.com/a/mozilla.org/g/dev-security-policy, and the CCADB Public List, https://groups.google.com/a/ccadb.org/g/public;<br />
* Your CP, CPS, or combined CP/CPS MUST clearly explain your CA’s domain validation procedures and indicate which subsection of section 3.2.2.4 of the CA/Browser Forum’s Baseline Requirements you are complying with;<br />
* Your CP, CPS, or combined CP/CPS MUST be updated at least every 365 days (more often is expected), and it must be reported in the CCADB in a “timely manner”, and failure to do either of these things will require that you file an incident report in Bugzilla;<br />
* You MUST maintain links to all historic versions of each CP, CPS, or combined CP/CPS from the creation of included CA certificates until such certificate hierarchies are no longer trusted by the Mozilla root store, and if your CA certificate was included by Mozilla before December 31, 2022, then you still must maintain links for “reasonably available historic versions” of your CPs, CPSes, or combined CP/CPSes; and<br />
* In the CCADB, if you elect to publish a JSON array of partial CRLs (rather than the full CRL), then the JSON Array of Partitioned CRLs must contain a critical Issuing Distribution Point extension, which shall include a URI whose value is derived from either the URI as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5) or the URL included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA.<br />
<br />
Finally, participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard user security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you very much for your continued cooperation in this pursuit.<br />
<br />
Regards,<br />
Ben Wilson<br />
Mozilla CA Program Manager<br />
<br />
<br />
<br />
== May 2022 CA Communication and Survey ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a058Z000013UmsDQAS Read-only copy of May 2022 CA Communication and Survey]<br />
** This link is '''Read Only'''. To submit your responses, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2022 CA Communication and Survey' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
=== May 2022 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00160,Q00161 Responses to Item 1] -- Compliance with MRSP v. 2.8<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00162,Q00163 Responses to Item 2] -- "Incidents" include audit findings<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00164,Q00165 Responses to Item 3] -- Auditor membership in ACAB'c and WebTrust<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00166,Q00167,Q00168 Responses to Item 4] -- Online Archival of CPs and CPSes<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00169,Q00170 Responses to Item 5] -- Full CRLs for Intermediate TLS CAs in CCADB<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00171,Q00172 Responses to Item 6.1] -- Sunsetting of SHA1 for S/MIME Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00173,Q00174 Responses to Item 6.2] -- Sunsetting of SHA1 for Other Types of Signing<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00175,Q00176 Responses to Item 7] -- Publicly Disclose Intermediate CA Certificates capable of Issuing TLS or S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00177,Q00178 Responses to Item 8] -- Misissuance of Certificate Transparency Precertificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00179,Q00180,Q00181 Responses to Item 9] -- CRL Revocation Reasons for TLS Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00182,Q00183 Responses to Item 10] -- Public Review of Unconstrained Externally-Operated Subordinate CAs<br />
<br />
== February 2022 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla is engaged in policy review discussions to sunset the use of SHA1 for signing by CAs of CRLs, OCSP responses, and SMIME certificates.<br />
See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/CnVjV-bFcyI/m/TFuWOy2BAwAJ<br />
<br />
(Server certificate signing is governed by the Baseline Requirements, and effective June 1, 2022, OCSP responses related to server certificates cannot be signed with SHA1.)<br />
<br />
One proposal is to remove SHA1 from the list of allowed signing algorithms altogether, but before we do this, I would like your proposed sunset dates for the different types of SHA1 signing you might currently perform--SMIME certificates, ARLs/CRLs, and OCSP responses for SMIME certificates.<br />
<br />
Please participate in this important topic, which is already underway on the Mozilla dev-security-policy list. Let us know about your specific concerns and hurdles that would need to be overcome.<br />
(Some CAs have expressed willingness to quickly convert over to SHA256, while others have expressed that it is not a simple task and will require additional development work.)<br />
<br />
Thanks,<br />
Ben Wilson (bwilson@mozilla.com)<br />
Mozilla Root Store Program<br />
<br />
== April 2021 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a054o00000EL1Fo Read-only copy of April 2021 CA Communication]<br />
** This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br><br />
<br><br />
Mozilla’s Root Store Policy was recently updated to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ version 2.7.1] with an effective date of 1 May 2021. This version contains [https://github.com/mozilla/pkipolicy/pull/223 several changes] that may affect your organization and the auditors who evaluate your PKI. These changes require you to take action to ensure your continued compliance. <br />
<br><br><br />
Please review version 2.7.1 of [https://www.mozilla.org/projects/security/certs/policy/ Mozilla’s Root Store Policy] internally, and with your auditors as well. After you and your auditors have reviewed these new requirements, complete the April 2021 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your practices. Read all survey questions first before beginning to respond. <br />
<br><br><br />
To respond to this survey, [https://ccadb.org/cas/ log in to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 30-April-2021.<br />
<br><br><br />
A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Ben Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== April 2021 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00129,Q00142 Responses to Item 1] -- Review Version 2.7.1 of Mozilla's Root Store Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00131,Q00149,Q00143 Responses to Item 2] -- 398-day reuse period on domain/IP address validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00132,Q00144 Responses to Item 3] -- Clarification about EV Audit Requirements <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00133,Q00145 Responses to Item 4] -- Annual Audit Covering the CA Key Pair Lifecycle <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00136,Q00146 Responses to Item 5] -- Audit Team Qualifications<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00137,Q00147 Responses to Item 6] -- List of Incidents in Audit Reports<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00140,Q00150,Q00148 Responses to Item 7] -- Methods to Demonstrate Key Compromise<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00141,Q00157,Q00159 Responses to Item 8] -- Removal of Old Root CA Certificates (challenges and alternatives)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00156,Q00151,Q00158 Responses to Item 8 timelines] -- Timelines and strategies to replace old, non-BR compliant CA hierarchies and root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00152,Q00155,Q00153 Responses to Item 9] -- Audit Letter Validation on Intermediate Certificates<br />
<br />
== May 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J000042AUSv Read-only copy of May 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>This survey requests your input on current policy and upcoming policy changes that affect you as a participant in Mozilla's CA Certificate Program. <br />
<br><br />
<br>To respond to this survey, [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 31-May 2020. <br />
<br><br />
<br>A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br><br />
<br>Regards,<br />
<br>Kathleen Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== May 2020 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00099,Q00100 Responses to Item 1] -- Impact of COVID-19 Restrictions<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00101,Q00102, Responses to Item 2] -- Mozilla Root Store Policy version 2.7 Requirements and Deadlines <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00103,Q00104 Responses to Item 3] -- Reducing Maximum Validity Period for TLS Certificates <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107 Responses to Sub Item 3.1] -- Limit TLS Certificates to 398-day validity<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00108,Q00109,Q00110 Responses to Sub Item 3.2] -- Limit re-use of domain name and IP address verification to 398 days<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00111,Q00112 Responses to Item 4] -- CA/Browser Forum Ballot for Browser Alignment <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00113,Q00114,Q00115 Responses to Sub Item 4.1] -- CA/Browser Forum defined-policy OID in Subscriber Cert certificatePolicies<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00116,Q00117,Q00118 Responses to Sub Item 4.2] -- Byte-for-byte Identical Issuer and Subject Distinguished Names<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00119,Q00120,Q00121 Responses to Sub Item 4.3] -- Text-searchable PDF Audit Statements<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00122,Q00123,Q00124 Responses to Sub Item 4.4] -- OCSP Requirements<br />
<br />
== January 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003waNOW Read-only copy of January 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/ updated]. The 2.7 version went into effect on 1-January 2020. This version contains a [https://github.com/mozilla/pkipolicy/pull/199/files number of changes] that may affect your organization and will require you to take action to comply. Please review Mozilla’s updated Root Store Policy and complete the January 2020 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your Certificate Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘January 2020 CA Communication' survey. Please enter your response by 31 January 2020.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== January 2020 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00082,Q00083 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00084,Q00085,Q00098 Responses to Action 2] -- Update CP/CPS <br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00086,Q00087,Q00097 Responses to Action 3] -- Include EKUs in All End-entity Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00088,Q00089 Responses to Action 4] -- Ensure Audit Reports are Properly Formatted<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00090,Q00096,Q00091 Responses to Action 5] -- Resolve Audit Issues with Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00092,Q00093 Responses to Action 6] -- Incident Reporting<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00094,Q00095 Responses to Action 7] -- Compliance with BRs<br />
<br />
== November 2018 CA Communication (Underscores in dNSNames) ==<br />
On November 12, 2018, the following message was sent to all CAs in the Mozilla program, alerting them to CA/Browser Forum SC12 that established a brief sunset period for the use of underscore characters in dNSNames in publicly-trusted TLS certificates.<br />
<br /><br />
<br />
Dear Certification Authority,<br />
<br />
The CA/Browser Forum recently approved [1] a clarification to the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (BRs) that may affect you. Domain names containing underscore (“_”) characters are not permitted to be encoded as dNSName types in the subjectAlternativeName (SAN) field of BR-compliant certificates. This requirement derives from section 4.2.1.6 of RFC 5280 that the BRs require CAs to comply with by reference.<br />
<br />
Section 7.1.4.2.1 of the BRs will add the following language that clarifies the existing requirement and adds a short time in which CAs must discontinue the use of underscore characters in dNSNames:<br />
-----<br />
Prior to April 1, 2019, certificates containing underscore characters (“_”) in domain labels in dNSName entries MAY be issued as follows:<br />
* dNSName entries MAY include underscore characters such that replacing all underscore characters with hyphen characters (“-“) would result in a valid domain label, and;<br />
* Underscore characters MUST NOT be placed in the left most domain label, and;<br />
* Such certificates MUST NOT be valid for longer than 30 days.<br />
<br />
All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019.<br />
<br />
After April 30, 2019, underscore characters (“_”) MUST NOT be present in dNSName entries.<br />
-----<br />
This new language will go into effect on December 10, 2018 when the IPR review period for ballot SC12 [1] is completed. At that time, CAs must be prepared to stop issuing publicly-trusted TLS certificates containing the underscore character in any dNSName with validity periods of more than 30 days.<br />
<br />
As a participant in Mozilla's CA Certificate Program, we want you to be aware of this important change, and ask that you take any necessary steps to comply. No further action related to this change is requested at this time.<br />
<br />
Regards,<br />
<br />
Wayne Thayer<br />
Mozilla CA Program Manager<br />
<br />
[1] https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/<br />
<br />
=== November 2018 Responses ===<br />
* No survey was included in this CA Communication<br />
<br />
== September 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL Read-only copy of September 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'September 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/ updated]. The 2.6.1 version went into effect on 1-July, 2018. This version contains a number of changes that may affect your organization and will require you to take action to comply. This survey also contains information regarding other recent and upcoming changes that may affect your Certification Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘September 2018 CA Communication' survey. Please enter your response by 30-September 2018.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== September 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00068,Q00069 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00070,Q00071 Responses to Action 2] -- Update CP/CPS<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00072,Q00073 Responses to Action 3] -- Transition to Separate Intermediate Certificates for SSL and S/MIME<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00074,Q00075 Responses to Action 4] -- Ensure Audit Reports comply with Mozilla’s Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00076,Q00077 Responses to Action 5] -- Discontinue use of BR Validation Methods 3.2.2.4.1 and 3.2.2.4.5<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00078,Q00079 Responses to Action 6] -- Disclose Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00080,Q00081 Responses to Action 7] -- Submit TLS Certificates to CT Logs for Mozilla's CRLite<br />
<br />
== January 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mqMFN Read-only copy of January 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br /><br /><br />
2018 has already generated some important news for Certification Authorities, and as a result we are sending this message to ensure that every CA in the Mozilla program is aware of current events and impending deadlines.<br />
<br /><br /><br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.<br />
<br /><br /><br />
To respond to this survey, login to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Please enter your response by 9-February 2018.<br />
<br /><br /><br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br /><br /><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br /><br /><br />
Regards,<br /><br />
Wayne Thayer<br /><br />
Mozilla CA Program Manager<br /><br />
<br />
=== January 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00056,Q00057 Responses to Action 1] -- Disclose Use of Methods 3.2.2.4.9 or 3.2.2.4.10 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00058,Q00059 Responses to Action 2] -- Disclose Use of Methods 3.2.2.4.1 or 3.2.2.4.5 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00060,Q00061 Responses to Action 3] -- Disclose All Non-Technically-Constrained Subordinate CA Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00062,Q00063 Responses to Action 4] -- Complete BR Self Assessment<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00064,Q00065 Responses to Action 5] -- Update CP/CPS to Comply with version 2.5 of Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00066,Q00067 Responses to Action 6] -- Reduce SSL Certificate Validity Periods to 825 Days or Less by March 1, 2018<br />
<br />
== November 2017 CA Communication ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7 Read-only copy of November 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority, <br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, login to the [http://ccadb.org/cas Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Please enter your response by December 15, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be [[CA/Communications|automatically and immediately published]] by the CCADB system.<br />
<br />
Participation in [[CA|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== November 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00035,Q00036 Responses to Action 1] -- Full compliance with version 2.5 of [https://www.mozilla.org/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00037,Q00044 Responses to Action 2] -- non-technically-constrained intermediate certificates must be [http://ccadb.org/cas/intermediates disclosed in CCADB] within one week of creation. '''New requirements''' for [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#technically-constrained technical constraints on intermediate certificates issuing S/MIME certificates].<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00038,Q00045 Responses to Action 3] -- Annual updates via [http://ccadb.org/cas/updates CCADB Audit Cases]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00050,Q00051 Responses to Action 4] -- Reiterate [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#audit-parameters audit requirements] and '''penalty for incomplete audit statements'''<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00039,Q00046 Responses to Action 5] -- Perform a [[CA/BR_Self-Assessment|BR Self Assessment]]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00042,Q00048 Responses to Action 6] -- Provide tested email address for [https://ccadb.my.salesforce-sites.com/mozilla/CAInformationReport Problem Reporting Mechanism]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00040,Q00047 Responses to Action 7] -- Follow new developments and effective dates for [http://tools.ietf.org/html/rfc6844 Certification Authority Authorization (CAA)]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00052,Q00053 Responses to Action 8] -- Check [https://groups.google.com/d/msg/mozilla.dev.security.policy/4kj8Jeem0EU/GvqsgIzSAAAJ issuance of certs to .tg domains] from October 25 to November 11, 2017.<br />
<br />
== May 2017 - Announcing CCADB Changes ==<br />
<br /><br />
Subject: Common CA Database (CCADB) changes May 19-21, 2017<br />
<br /><br /><br />
Message:<br /><br /><br />
Dear Certification Authority,<br />
<br /><br />
<br /><br />
The Common CA Database (CCADB) will undergo the following changes this weekend, May 19 to May 21. During this time, the old URLs listed below will stop working, and there will be some time when the CCADB is in read-only mode.<br />
<br /><br />
<br /><br />
On May 19 the following three breaking changes are planned, meaning that the old URLs will no longer work. Any links or bookmarks to these URLs will need to be updated. After these changes are made, I will also update Mozilla's wiki pages to point to the new URLs.<br />
<br /><br />
<br /><br />
1) The CA login page and the domain CAs see when they are logged into the CCADB will change.<br />
<br /><br />
https://mozillacacommunity.force.com/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb.force.com/<br />
<br /><br />
<br /><br />
2) The links to reports that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/CA/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/mozilla/<br />
<br /><br />
<br /><br />
3) The links to CA communication responses that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/Communications<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/Surveys<br />
<br /><br />
<br /><br />
Then on May 21 between 12am and 4am PDT, the CCADB will be in read-only mode while Salesforce performs an instance refresh to upgrade the infrastructure supporting the CCADB instance in their data centers.<br />
<br /><br />
<br /><br />
Regards,<br />
<br /><br />
Kathleen<br />
<br />
== April 2017 ==<br />
<br />
Note: The deadline to reply to this survey has [https://groups.google.com/d/msg/mozilla.dev.security.policy/03rdTdnm7iw/NQUHmWOcEAAJ been extended] by one week, to May 5, 2017.<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000003WrzBC Read-only copy of April 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [https://ccadb.force.com/CustomLogin login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA:IncludedCAs|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, [https://mozillacacommunity.force.com/CustomLogin login to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Please enter your response by April 28, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br />
In addition to responding to the action items in this survey, we are instituting a program requirement that you follow discussions in the [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] forum, which includes discussions about upcoming changes to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy], questions and clarification about policy and expectations, root certificate [[CA|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] or other program requirements. You are not required to contribute to those discussions, only to be aware of them. However, we hope you will participate and help shape the future of Mozilla's CA Certificate Program.<br />
<br />
Participation in [[CA:Overview|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== April 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [[CA:CommonCADatabase|Common CA Database]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00015,Q00030 Responses to Action 1] -- Domain Validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 2 and Action 10] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00022,Q00029 Responses to Action 3] -- Updated Mozilla CA Certificate Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00017,Q00031 Responses to Action 4] -- Audit Statements, annual updates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00018,Q00032 Responses to Action 5] -- Audit Statement Contents<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00021,Q00033 Responses to Action 6] -- Qualified Audit Statements<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00019 Responses to Action 7] -- BR Compliance Bugs<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 Responses to Action 8] -- Confirm Completion of Previous Commitments<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00027 Responses to Action 9] -- Registration Authorities<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 10 and Action 2] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00023 Responses to Action 11] -- Certification Authority Authorization (CAA)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00028 Responses to Action 12] -- Problem Reporting Mechanism<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00024 Responses to Action 13] -- SHA-1 and S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00034 Responses to Action 14] -- Certificate Validity Periods in TLS/SSL Certs<br />
<br />
== March 2016 ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000000iHdtx Read-only copy of March 2016 CA Communication]<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program, by April 22, 2016.<br />
<br />
To respond to this survey, please login to the [[CA:SalesforceCommunity|CA Community in Salesforce]], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'March 2016 CA Communication' survey. Please enter your response by April 22, 2016. <br />
<br />
A compiled list of CA responses to the survey action items will be [[CA:Communications#March_2016_Responses|automatically and immediately published]] by Salesforce.<br />
<br />
In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the [https://groups.google.com/forum/#!forum/mozilla.dev.security.policy mozilla.dev.security.policy] forum, which includes discussions about [[CA:CertificatePolicyV2.3|upcoming changes to Mozilla's CA Certificate Policy]], questions and clarification about policy and expectations, root certificate [[CA:Schedule|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements]. Your contributions to the discussions will help shape the future of [[CA:Overview|Mozilla's CA Certificate Program]].<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Mozilla CA Program Manager<br />
<br />
=== March 2016 Responses ===<br />
<br />
The following links are automatically generated from data in the [[CA:SalesforceCommunity|CA Community in Salesforce]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommSummaryReport?CommunicationID=a05o000000iHdtx CA Responses to March 2016 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00001,Q00013 Responses to Action #1a] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00002,Q00014 Responses to Action #1b] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 Responses to Action #1c] -- SHA-1 Deprecation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 Responses to Action #2] -- Entering intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00005 Responses to Action #3] -- Entering revoked intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00006&QuestionIdForText=Q00007 Responses to Action #4] -- [[SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix|Removing workarounds]] to compatibility issues that were encountered involving certificates that did not conform to the Baseline Requirements. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00008 Responses to Action #5] -- Plans to remove old/retired root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00009 Responses to Action #6] -- Confirmation of understanding that all certificates, including test certificates, must conform to stated policies<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00012 Responses to Action #7] -- [[CA:RootTransferPolicy|Mozilla's Root Transfer Policy]]<br />
<br />
== May 2015 ==<br />
<br />
Dear Certification Authority, <br />
<br />
This email requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by June 5, 2015, with your response to the action items by clicking on the survey link below. A compiled list of CA responses to these action items will be published. <br />
<br />
Certification Authority: <CA Account Name><br />
<br />
Your Survey Link: <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/TakeSurvey?id=a04o000000M89RCAAZ&cId=&caId=none Survey Link] -- '''IMPORTANT: CA's do NOT use the link in this wiki page! This link will NOT record your response. Please use the link that was emailed to you.'''<br />
<br />
Please use the above link to read and respond to the action items. Note that you may access the above link multiple times to update your responses.<br />
<br />
Additionally, we plan to update Mozilla's CA Certificate Policy soon, and will be discussing proposed policy updates in the mozilla.dev.security.policy forum, https://www.mozilla.org/en-US/about/forums/#dev-security-policy. We encourage you to monitor the discussions to see how the updates will impact you, and your participation in the discussions will help shape the policy updates.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, <br />
Mozilla <br />
CA Program Manager<br />
<br />
=== May 2015 Responses ===<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationSummaryReport?CommunicationId=a04o000000M89RCAAZ CA Responses to May 2015 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%233:%20After%20January%201,%202016 Responses to Action #3] -- SHA-1 Deprecation Plans<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%234:%20Workarounds%20were%20implemented Responses to Action #4] -- Removing workarounds implemented to allow mozilla::pkix to handle the things listed here https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%235:%20We%20wish%20to%20understand%20what%20support Responses to Action #5] -- IPv6 survey<br />
<br />
== May 2014 ==<br />
<br />
Subject: Mozilla Communication: Action requested by May 30, 2014<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by May 30, 2014, with your response to these action items. A compiled list of CA responses to the following action items will be published. <br />
<br />
CA Certificate Inclusion Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/<br />
<br />
CA Certificate Maintenance Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/<br />
<br />
Spreadsheet of included root certificates: http://www.mozilla.org/about/governance/policies/security-group/certs/included/<br />
<br />
1) Ensure that Mozilla’s [http://www.mozilla.org/about/governance/policies/security-group/certs/included/ spreadsheet of included root certificates] has the correct link to your most recent audit statement, and that the date of the audit statement is correct. As per [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/ Mozilla's CA Certificate Maintenance Policy], we require that all CAs whose certificates are distributed with our software products provide us an updated statement annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties. To notify us of an updated statement of attestation, send email to certificates@mozilla.org or [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates submit a bug report] into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "mozilla.org" product.<br />
If you are not proactively sending Mozilla your updated audit statements, please create a process to do so.<br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent audit statement, and the audit statement date is correct.<br />
* B) Here is the most recent audit statement for our certificates that are included in Mozilla’s CA program: <insert link here> <br />
* C) We plan to send Mozilla our current audit statement by <insert date here>.<br />
* D) We do not have a current audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
2) Send Mozilla the link to your most recent [https://cabforum.org/about-the-baseline-requirements/ Baseline Requirements] audit statement. Details about Mozilla's audit requirements are listed in section 11 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy]. The Baseline Requirements audit statement should also be proactively sent to Mozilla each year, along with the other audit statements as described in action #1. <br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent Baseline Requirements audit statement.<br />
* B) Here is the most recent Baseline Requirements audit statement for our certificates that are included in Mozilla’s CA program: <insert link here>. <br />
* C) We plan to send Mozilla our current Baseline Requirements audit statement by <insert date here and explain reason for delay>.<br />
* D) The websites (SSL/TLS) trust bit is not enabled for our certificates that are included in Mozilla's CA program.<br />
* E) We do not have a current Baseline Requirements audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
3) Test Mozilla's new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed. <br />
The new Certificate Verification library (mozilla::pkix) was announced here: https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ .<br />
Mozilla::pkix includes some changes in support of current best practices and policies, as listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes .<br />
How to test: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing .<br />
<br />
Please respond with one of the following: <br />
* A) We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix.<br />
* B) We have found the following issues when testing certificates in our CA hierarchy with mozilla::pkix. <descriptions or Bugzilla bug numbers, related URLs and/or certificates><br />
* C) We are testing certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and plan to send Mozilla our results by <insert date here, must be before June 30, 2014>.<br />
<br />
4) Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix<br />
<br />
Please respond with one of the following: <br />
* A) We have not and will not issue certificates with any of the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page.<br />
* B) We have previously issued certificates with the following problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page: <list the problems that needed to be fixed>. The last of those certificates expire <insert dates here, one date per problem>. We will not issue new certificates with the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page as of this date: <date when your operations will be updated, no later than June 30, 2014><br />
<br />
5) Send Mozilla information about your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, as per Items #8, 9, and 10 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy].<br />
<br />
Please provide a URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, and contains the required information according to section 10 of Mozilla's CA Certificate Inclusion Policy. If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificates" component of the "mozilla.org" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates)<br />
<br />
Additionally, please respond with one of the following: <br />
* A) All subordinate CA certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy.<br />
* B) We request an extension for the following specific subordinate CA certificates, because these subordinate CAs need more time to transition from their legacy systems to their new CA hierarchy: <list of issuer hash, issuer public key hash, and certificate serial number>. For each subordinate CA who needs to operate in their legacy design a little longer, the attached document explains the reason that continued operation is needed and their target date for resolution. <attach document(s) to response><br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== May 2014 Responses ===<br />
<br />
[https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml CA Responses to May 2014 Communication]<br />
<br />
== July 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by August 16, 2013<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s CA Certificate Policy has been updated with a few important changes. This update was motivated by security concerns regarding ICANN granting applied-for new gTLD strings. Additionally, we want to make it very clear that there will be serious consequences if it is found that a CA has knowingly or intentionally mis-issued certificates chaining to trust anchors in Mozilla’s program.<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of applications.<br />
<br />
Please carefully review the following wiki page for information about the changes introduced in version 2.2 of Mozilla’s CA Certificate Policy.<br />
<br />
https://wiki.mozilla.org/CA:CertificatePolicyV2.2<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by August 16, 2013, with your response to the following action items. <br />
<br />
1) Update your CA operations and policies to include the CA/Browser Forum’s Baseline Requirement #11.1.4 regarding new gTLD domains, and subscribe to ICANN’s new gTLD Registry Agreement notification mailing list at: https://mm.icann.org/mailman/listinfo/gtldnotification<br />
<br />
Please respond with one of the following:<br />
* A) No action required, because we have not and will not issue SSL certificates with internal or private domain names chaining up to root certificates that are included in Mozilla’s program.<br />
* B) We have issued or may issue SSL certificates with internal or private domain names that chain up to root certificates that are included in Mozilla’s program, so we are implementing Baseline Requirement #11.1.4, and will subscribe to ICANN’s notification service regarding applied-for-gTLD strings. We plan to have this completed by September 16, 2013.<br />
* C) We have already implemented Baseline Requirement #11.1.4, and have subscribed to ICANN’s notification service regarding applied-for-gTLD strings.<br />
<br />
2) Review your CA operations and customers to ensure that there are no certificates chaining up to your trust anchors that are included in Mozilla’s program that may be used for MITM or “traffic management” of domain names or IP addresses that the certificate holder does not own or control. [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla’s CA Certificate Enforcement Policy] has been updated to make it clear that Mozilla will not tolerate this use of publicly trusted certificates. <br />
<br />
Please respond with:<br />
* “We have reviewed Mozilla’s updated CA Certificate Enforcement Policy and understand that knowing or intentional mis-issuance of a certificate is expressly against Mozilla’s CA Certificate Policy and could result in removal of all of our certificates from Mozilla’s products.”<br />
<br />
3) Ensure that your CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current, including links to the CP/CPS documents, audit statements, and test websites. Mozilla will be adding a column to this spreadsheet to indicate the date of the most recent audit statement for each root certificate.<br />
<br />
http://www.mozilla.org/projects/security/certs/included/index.html<br />
<br />
Please respond with one of the following:<br />
* A) Our CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current for all of our included certificates.<br />
* B) Here is the current information for our certificates that are included in Mozilla’s program: <insert data here><br />
<br />
4) Complete the action items from Mozilla’s January CA Communication.<br />
* https://wiki.mozilla.org/CA:Communications#January_10.2C_2013<br />
* https://wiki.mozilla.org/CA:Communications#January_2013_Responses<br />
<br />
Please respond with one of the following:<br />
* A) Our recorded response to the January CA Communication is complete and correct.<br />
* B) We have the following updated status for our response to the January CA Communication: <insert data here><br />
<br />
5) Follow discussion about the changes to policy and code that Mozilla will be making in order to improve how revocation checking is handled in Firefox. Discussions will be held in the mozilla.dev.security.policy forum, and descriptions of the changes that will be considered for both policy and code will be provided here: https://wiki.mozilla.org/CA:ImprovingRevocation<br />
As part of this effort, Mozilla will be implementing a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker. More information will follow, and policy will be added soon to require CAs to send Mozilla revocation information. We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
<br />
=== July 2013 Responses ===<br />
<br />
* [https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGR1TmZLZnJ1RThHRDcwMDJRaXZicFE&output=html CA Responses to July 2013 Communication]<br />
<br />
== January 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by January 31, 2013. <br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by January 31, 2013, with your response to these action items. A compiled list of CA responses to the following action items will be published.<br />
<br />
1) Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations. <br />
<br />
Version 2.1 of Mozilla’s CA Certificate Policy is in final review, and will be ratified and published in Q1 of 2013. There are changes to the policy that may impact your current operations, so we encourage you to review the changes that are indicated in red or bold text here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html<br />
<br />
There will be a transition period for CAs to bring existing customers into compliance with the new policy, as described here:<br />
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1<br />
<br />
Please respond to this action item with one of the following:<br />
* a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.<br />
* b) The proposed changes to Mozilla’s CA Certificate Policy impact our CA operations, but we will be able to complete the transition within the allotted time frame.<br />
* c) We will not be able to update our CA operations to comply with the proposed version 2.1 of Mozilla’s CA Certificate Policy within the allotted time frame, because <insert reason(s)>. We plan to meet the new requirements by <insert date>.<br />
<br />
2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements.<br />
<br />
The CA/Browser Forum (http://www.cabforum.org) released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which became effective on July 1, 2012. It is our expectation that as of January 2013 CA issuance of SSL certificates will be audited against these Baseline Requirements as well as the acceptable audit criteria that are listed in Mozilla’s CA Certificate Policy.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.<br />
* b) Not applicable, because we do not issue SSL certificates.<br />
* c) We are working towards compliance with the CA/Browser Forum’s Baseline Requirements, but we need to complete <insert list of tasks>. We plan to have this completed by <insert date>.<br />
<br />
3) Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit.<br />
<br />
Due to the recent incident in which a mis-issued intermediate certificate was found (https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates), we are concerned that CAs may have responded to our last communication based on their policies, rather than checking their certificate databases. Therefore, we request that you scan your certificate database and inform Mozilla if you find any un-expired intermediate certificates in your CA hierarchy that should not be trusted. In your reply, please attach all such intermediate certificates, even if you have already revoked them.<br />
<br />
While you are scanning your certificate databases to ensure that all certificates with basicConstraints:CA:TRUE have been issued in accordance with your CPS, please also check for compliance with the following practices.<br />
* All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.<br />
* All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.<br />
* All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration).<br />
* All end-entity certificates with RSA key sizes smaller than 2048 bits expire no later than December 2013.<br />
* Certificates are not issued with sequential serial numbers. If it is found that certificates have been issued with contiguous serial numbers, then the subject of those certificates must contain unpredictable data that is not under the control of the certificate subscriber.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* b) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
* c) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* d) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
<br />
4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name.<br />
<br />
The CA/Browser Forum’s Baseline Requirements state: <br />
“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 Server 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.”<br />
<br />
This practice is being eliminated for security reasons, so we encourage all CAs to begin working with their customers to transition to alternative arrangements, and to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names as soon as possible rather than waiting until the deadline.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names.<br />
* b) We plan to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names by <insert date>.<br />
<br />
5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it. We expect this website to endure for the lifetime of the root, or until you notify us of an alternative URL. The website does not need to support high traffic loads or have greater than 99% uptime.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson, <br />
Module Owner of Mozilla's CA Certificates Module <br />
<br />
=== January 2013 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dHdISmM3c05tb1dMQjlJclJqS21QNmc&output=html CA Responses to January 2013 Communication] -- Contains two spreadsheets: "Action Item Responses" and "Test Website URLs".<br />
<br />
== February 2012 ==<br />
<br />
Subject: Mozilla Communication: Action requested by March 2, 2012<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Please reply by March 2, 2012, to confirm completion of the following actions or state when these actions will be completed.<br />
<br />
1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012. For each subordinate CA that is revoked, send me:<br />
* a) The certificate that signed the subCA. If it is a root certificate in NSS, then the root certificate's subject and SHA1 fingerprint.<br />
* b) The Serial Number of the revoked certificate.<br />
* c) The CRL that contains the serial number of the revoked certificate.<br />
<br />
As a CA in Mozilla’s root program you are ultimately responsible for certificates issued by you and any intermediate CAs that chain up to your roots. After April 27, 2012, if it is found that a subordinate CA is being used for MITM, we will take action to mitigate, including and up to removing the corresponding root certificate. Based on Mozilla’s assessment, we may also remove any of your other root certificates, and root certificates from other organizations that cross-sign your certificates.<br />
<br />
I am planning to publish a compiled list of CA responses to all of the action items in this communication. Therefore, I recommend responding to action item #1 with one of the following choices:<br />
* a) Does not apply, because we do not issue subCA certificates to third parties.<br />
* b) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
* c) We are reviewing all of our subCAs and will take the necessary action by <date>. <br />
* d) We have revoked such subCA certificates, and here is the requested information.<br />
* e) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM. ''(Note: This option was added after the communication was sent.)''<br />
<br />
2) If you issue subordinate CAs to third parties or your CP/CPS permits you to do so in the future, please add a statement to your CP/CPS committing that you will not issue a subordinate certificate that can be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control. Send me the URL to the updated document(s) and the impacted sections or page numbers. <br />
<br />
3) Please scan all of your EV SSL certificates and revoke any that do not meet the EV requirements. This includes, but is not limited to maximum validity period of the certificate, subject naming, minimum key sizes, required extensions, and maximum expiration time of OCSP responses.<br />
<br />
4) Certificates chaining to root certificates in Mozilla’s root program should not have MD5 algorithms or RSA keys shorter than 1024 bits long. Please scan the certificates chaining to your root certificates in NSS, and revoke any certificates that contain small key sizes or MD5 algorithms. <br />
<br />
5) The CA/Browser Forum has released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which is available here: http://www.cabforum.org/. Discussions are in progress in the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate Policy to add a requirement that CAs also meet these baseline requirements for issuance of SSL/TLS certificates. Please contribute to the discussions in the mozilla.dev.security.policy forum, and update your operations and documentation as needed to meet the baseline requirements by the effective date of July 1, 2012.<br />
<br />
The currently proposed updates to Mozilla’s CA Certificate Policy are here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== February 2012 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGxsWlZEdGFDaW9JTlNTUGxBNWhqSlE&output=html CA Responses] -- spreadsheet of the responses to the action items of the CA Communication that was sent on February 17, 2012.<br />
<br />
Response Key:<br />
* IP = "In Progress"<br />
* ? = I need further clarification on the response<br />
* N/A = "Not Applicable"<br />
** N/A for Action #2 means that the CP/CPS does not allow for externally-operated subCAs.<br />
** N/A for Action #3 means that the CA is not issuing EV certs under the roots included in NSS.<br />
* Responses to action #1 can be one or more of the following. If option C is listed, there is also a date by which the CA plans to complete their investigation and provide further information.<br />
** A) Does not apply, because the CA does not have externally-operated subCAs chaining to roots in NSS.<br />
** B) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
** C) The CA is reviewing all of their subCAs and will take the necessary action by <date>.<br />
** D) The CA has revoked such subCA certificates, and provided the requested information.<br />
** E) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
<br />
== September 2011 ==<br />
<br />
Subject: Mozilla Communication: Immediate action requested<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Mozilla recently removed the DigiNotar root certificate in response to their failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates (https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up). If you ever have reason to suspect a security breach or mis-issuance has occurred at your CA or elsewhere, please contact security@mozilla.org immediately.<br />
<br />
Please confirm completion of the following actions or state when these actions will be completed, and provide the requested information no later than September 16, 2011:<br />
<br />
1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs.<br />
<br />
2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included<br />
<br />
3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance.<br />
<br />
4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked.<br />
<br />
5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either:<br />
<br />
a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical)<br />
<br />
OR<br />
<br />
b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public 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 subordinate CA's internal operations.<br />
<br />
Each action requested above applies both to your root and to these third parties.<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your participation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== April 2011 ==<br />
<br />
Subject: Mozilla Communication: Policy Discussions are in Progress that may Impact Your CA<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to three important items that we would like to bring to your attention.<br />
<br />
1) The CA/Browser Forum has published a final draft of the document "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." We are now hosting a discussion about this document in the mozilla.dev.security.policy forum. For more information, see http://cabforum.org/. <br />
The document is here: http://cabforum.org/Baseline_Requirements_Draft_30b.pdf<br />
<br />
Mozilla supports the CA/Browser Forum’s efforts in this area. After version 1.0 of the CA/Browser Forum’s Baseline Requirements document is published, we will have a discussion to add a requirement to the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/) that CAs include the CA/Browser Forum Baseline Requirements in their policies, practices, and audits. Therefore, we urge you to review the draft of the Baseline Requirements, assessing the impact to your CA policies and practices, and participate in the current discussions about these requirements. The CA/Browser Forum has set the duration of this discussion to 45 days from April 11.<br />
<br />
2) Mozilla has begun discussions about the Phase 2 items to be considered for updating the Mozilla CA Certificate Policy, https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. The current discussions are focused on RAs and Subordinate CAs. We recommend that you monitor and contribute to these discussions so that you are aware of how the potential changes to the Mozilla CA Certificate Policy may impact you.<br />
<br />
3) As per previous communications, we will implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== February 2011 ==<br />
<br />
Subject: Mozilla Communication: Version 2.0 of Mozilla CA Certificate Policy has been published<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla has ratified and published Version 2.0 of the Mozilla CA Certificate Policy. <br />
<br />
The new policy is here:<br />
http://www.mozilla.org/projects/security/certs/policy/ <br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than August 8, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. Now that this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== January 2011 ==<br />
<br />
Subject: Mozilla Communication: Major Pending Update to Mozilla CA Certificate Policy<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla is preparing to update the Mozilla CA Certificate Policy. The forthcoming changes will come in multiple phases, and the first phase is nearly complete. Discussion about the first phase of changes has proceeded for several months in the mozilla.dev.security.policy forum. Version 2.0 of the policy, reflecting the first phase of updates, is now under final review. Mozilla expects it to be ratified by January 31, 2011.<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than April 30, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
The current policy (version 1.2) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/<br />
<br />
The new policy (version 2.0) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/<br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945#c3<br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. After this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== October 2010 ==<br />
<br />
Subject: Mozilla Communication to CAs regarding Policy updates, October 2010<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to five important points that we would like to bring to your attention.<br />
<br />
1) Mozilla has started a project to update the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/). The proposed changes may impact the operation of your root certificates that are included in NSS. Therefore, we request that all CAs participate in the discussions, which will be held in the Mozilla.dev.security.policy forum, http://www.mozilla.org/about/forums/#dev-security-policy. For information about the potential changes, please see https://wiki.mozilla.org/CA:CertPolicyUpdates.<br />
<br />
2) As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must provide an OCSP capability for end-entity certificates that are issued after Dec 31, 2010. Mozilla is considering technical ways to enforce this OCSP requirement such that if Firefox cannot obtain a valid response from the OCSP responder, then the certificate will not be given EV treatment. We are considering requiring the end-entity certificate to provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23<br />
Additionally, we urge all CAs to provide OCSP for all certs, even when they are not EV.<br />
<br />
3) We expect that all new certificates contain randomness (preferably in the serial number), especially when using the SHA-1 hash function or an RSA key size smaller than 2048 bits. For more information, please see http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period and serial number prediction”, and section 7, “Countermeasures.”<br />
<br />
4) As per the NIST guidelines, it is our expectation that all CAs are transitioning from issuing certs with RSA key sizes smaller than 2048 bits. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
5) We are planning to implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certs. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== May 2010 ==<br />
<br />
Subject: Mozilla Communication: Acceptable Addresses for Domain Control Validation<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to some changes that we are proposing to make to Mozilla’s CA Certificate Policy.<br />
<br />
Section 7 of the Mozilla CA Certificate Policy states: “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;”<br />
<br />
Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. Offering too many options for the email address prefix increases the risk of issuing a certificate to a subscriber who does not own/control the domain. Therefore, the list of email address prefixes should be limited.<br />
<br />
Mozilla is proposing to restrict the set of verification addresses that may be used for domain validation to the following list or a subset of it. Mozilla’s goal is to strike a balance between flexibility and safety.<br />
<br />
Accepted addresses for domain validation challenge-response email:<br />
* root@domain<br />
* admin@domain<br />
* administrator@domain<br />
* webmaster@domain<br />
* hostmaster@domain<br />
* Plus any address listed in the contact fields of the domain's WHOIS record.<br />
<br />
We hope that this restriction, when implemented consistently across CAs, will not cause discrimination or hardship. We are seeking feedback on whether this is the case. We invite you to contribute your feedback to a discussion about this new restriction in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.<br />
<br />
http://www.mozilla.org/community/developer-forums.html<br />
https://lists.mozilla.org/listinfo/dev-security-policy<br />
news://news.mozilla.org/mozilla.dev.security.policy<br />
<br />
The discussion thread is called “Domain Control validation” and “Acceptable Addresses for Domain Control Validation”.<br />
<br />
We have also added this information to our wiki page:<br />
https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs<br />
<br />
We look forward to your contributions to this discussion.<br />
<br />
Regards,<br />
Kathleen Wilson<br />
<br />
== November 2009 ==<br />
<br />
Subject: Mozilla Communication: SSL certificates issued to internal domain names <br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla I am contacting you in regards to root certificates that you currently have included by default in Mozilla products, such as the Firefox browser. <br />
<br />
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. <br />
<br />
Section 7 of Mozilla’s CA Certificate Policy states that CAs need to take “reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate.” There are different interpretations as to what this means in regards to internal domain names such as non-valid TLDs, hostnames, and IP addresses. However, there is consensus that there are problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks. Mozilla is currently discussing whether the CA Certificate Policy should be updated to add more explicit requirements on this practice, or even to disallow it altogether.<br />
<br />
In the light of the current situation, Mozilla requests that you take the following actions.<br />
<br />
1) Perform an internal audit to look for certificates that have been issued within your CA hierarchy which have .int domain names in the Common Name and/or as DNS Names in the subjectAlternativeName. For each of these certificates, check to see if the certificate subscriber owns/controls that domain name, and revoke the certificate if they do not own/control that domain name.<br />
<br />
2) Review your controls/procedures (both internally and your RAs) for correct identification of internal and external domain names and verification that subscribers own/control the domain name to be included in their certificate. Please refer to these documents:<br />
a) Section 7 of Mozilla’s CA Certificate Policy<br />
(http://www.mozilla.org/projects/security/certs/policy/)<br />
b) https://wiki.mozilla.org/CA:Recommended_Practices<br />
c) https://wiki.mozilla.org/CA:Problematic_Practices<br />
<br />
Mozilla also recommends that you <br />
1) Update your training procedures to ensure that all validation staff are aware of this situation. <br />
2) Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates.<br />
3) Maintain your own list of ICANN approved TLDs that are eligible to be used for domains in certificates issued within your CA hierarchy. If a new TLD is created by IANA, make an explicit decision whether or not to add the new TLD to your list.<br />
http://www.icann.org/en/registries/top-level-domains.htm<br />
<br />
Mozilla strongly encourages you to take prompt action in order to ensure the continued security and trust-ability of your CA service. <br />
<br />
Kathleen Wilson</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/CCADB_Dashboard&diff=1247631CA/CCADB Dashboard2023-08-14T21:04:46Z<p>Kathleen Wilson: minor updates to description of priorities</p>
<hr />
<div>= Dashboard for Common CA Database Updates =<br />
<br />
== CCADB API Access==<br />
Requests for API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert<br />
<br />
To file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB API Access Request], use:<br />
<br /><br />
Product: CA Program <br />
<br /><br />
Component: Common CA Database <br />
<br /><br />
Whiteboard: [ccadb-api] <br />
<br /><br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"status_whiteboard":"ccadb-api",<br />
"include_fields": "whiteboard, id, summary, last_change_time",<br />
"order": "id"<br />
}<br />
</bugzilla><br />
<br />
== Bugs ==<br />
Bugs that unintentionally remove pre-existing functionality or negatively impact CCADB users should have priority over Enhancements, and should be set to P1. Low impact bugs will start at P4 and be considered with ERs. If it's a low LOE bug (less than 4 hours of work) it can go from P4 to P1 without prioritization/design.<br />
<br />
To file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB Bug], use:<br />
<br /><br />
Product: CA Program <br />
<br /><br />
Component: Common CA Database <br />
<br /><br />
Whiteboard: [ccadb-bug] <br />
<br /><br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"whiteboard":"ccadb-bug",<br />
"include_fields": "priority, id, summary, last_change_time",<br />
"order": "priority ASC"<br />
}<br />
</bugzilla><br />
<br />
== Enhancement Requests ==<br />
The Priority values are used as follows:<br />
* P1 - Development in progress<br />
* P2 - Design in progress or complete<br />
* P3 - Prioritized, design document started<br />
* P4 or not set - To be prioritized and scheduled later<br />
<br />
'''Important''': Do not enter a value into the Whiteboard field to file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB Enhancement Request].<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "nowordssubstr",<br />
"v2": "ccadb",<br />
"include_fields": "priority, id, summary,last_change_time",<br />
"order": "priority ASC"<br />
}<br />
</bugzilla><br />
<br />
== Closed ==<br />
A historical view of past CCADB updates (from May 2021 onward) may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_CCADB_Updates</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Bug_Triage&diff=1247548CA/Bug Triage2023-08-09T22:52:16Z<p>Kathleen Wilson: Added section about the CA Security Vulnerability component</p>
<hr />
<div>= CA Program Bugzilla Dashboards = <br />
* CA Inclusion/Update Requests: https://wiki.mozilla.org/CA/Dashboard<br />
* CA Compliance Bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
* Common CA Database (CCADB) Bugs: https://wiki.mozilla.org/CA/CCADB_Dashboard<br />
<br />
= Bug Triage in Mozilla's CA Certificate Program =<br />
Mozilla’s [[CA:Overview|CA Certificate Program]] governs inclusion of root certificates in [https://developer.mozilla.org/en-US/docs/NSS Network Security Services (NSS),] a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The [[CA:IncludedCAs|NSS root certificate store]] is not only used in Mozilla products such as the [https://www.mozilla.org/firefox/ Firefox] browser, but is also used by other companies in a variety of products.<br />
<br /><br /><br />
The [https://bugzilla.mozilla.org/ Bugzilla] products/components related to the CA Certificate Program are:<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Compliance&product=CA%20Program CA Program :: CA Certificate Compliance] - Problems found in certificates issued by Certificate Authorities included in the default certificate store.<br />
** Concerns that are raised about certificates being issued by CAs, and the resulting action items for the CAs.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program CA Program :: CA Certificate Root Program] - For Certificate Authorities to file requests asking for their certificates to be included in the default certificate store.<br />
** [[CA|Root inclusion/change requests]]. When approved, the actual code changes are requested via a new Bugzilla Bug in [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificates%20Code&product=NSS NSS :: CA Certificates Code].<br />
** [[CA:How_to_apply#Enable_EV_for_an_included_root|EV treatment enablement requests]]. When approved, the actual code changes are requested via a new [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=Security%3A%20PSM&product=Core Bugzilla Bug for PSM].<br />
** CA Program-related concerns or action items.<br />
** Requests to [https://www.ccadb.org/cas/intermediates#marking-an-intermediate-certificate-as-revoked add certs to OneCRL]. <br />
* [https://bugzilla.mozilla.org/buglist.cgi?&query_format=advanced&component=CA%20Documents&product=CA%20Program CA Program :: CA Documents] - For CA audit statements, when they are not on the auditor's website.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=Common%20CA%20Database&product=CA%20Program CA Program :: Common CA Database] - For requesting updates to the [https://www.ccadb.org/ Common CA Database (CCADB)].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificates%20Code&product=NSS NSS :: CA Certificates Code] - For actual code changes to NSS. Kathleen should be the only person filing these bugs on behalf of the CA Program.<br />
<br />
The CA Certificate Program deviates from Mozilla's standardized [[Bugmasters/Process/Triage|Bugzilla Bug Triage]] process for bug priorities (P1, P2, P3, P4, P5). Priorities are not used for CA compliance bugs because they do not directly include code changes to Mozilla's [[RapidRelease/Calendar|release trains]] or iterations. Priorities are used, however, for tracking CCADB enhancements and for prioritizing [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program root inclusion requests]. See https://wiki.mozilla.org/CA/Prioritization.<br />
<br />
= Compliance Problems and Incidents =<br />
To report a concern about certificates being issued by a CA in Mozilla's Program, or their audit statements:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance <br />
If the bug concerns CA certificate issuance, then the bug summary should begin with the CA name (followed by a colon and then a space), so that sorting the bugs by Summary will sort the bugs by CA. <br />
<br /><br /><br />
Open CA Compliance bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
<br /><br /><br />
If the bug concerns audit statements not containing expected information, then the bug summary should begin with auditor's name, so that sorting the bugs by Summary will sort the bugs by auditor name.<br />
<br /><br /><br />
Open Auditor Compliance bugs: https://wiki.mozilla.org/CA/Auditor_Compliance<br />
<br /><br /><br />
The whiteboard tags for [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&component=CA%20Certificate%20Compliance CA Program :: CA Certificate Compliance] include:<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-compliance &#91;ca-compliance&#93;] -- For concerns about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and it is not considered to be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=auditor-compliance &#91;auditor-compliance&#93;] -- For concerns about an auditor failing to properly detect and report on CA compliance issues that occurred during one or more periods when the CA was audited.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-revocation-delay &#91;ca-revocation-delay&#93;] or [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=leaf-revocation-delay &#91;leaf-revocation-delay&#93;] -- appended after [ca-compliance] whenever a CA fails to abide by the Baseline Requirements' requirement to revoke certificates in a timely fashion.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=audit-delay &#91;audit-delay&#93;] -- appended after [ca-compliance] when a CA is unable to provide audit statements within one year and 3 months of the previous audit period end date.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=covid-19 &#91;covid-19&#93;] -- appended after [ca-compliance], [audit-delay], or [ca-revocation-delay] when delays are due to mandated restrictions regarding COVID-19.<br />
<br />
New Whiteboard Tags appended to [ca-compliance] include the following:<br />
<br />
* [ca-misissuance] mis-issuance of a CA certificate<br />
* [dv-misissuance] mis-issuance of a DV certificate<br />
* [ov-misissuance] mis-issuance of an OV end-entity certificate<br />
* [ev-misissuance] mis-issuance of an EV end-entity certificate<br />
* [crl-failure] failure to provide certificate status via CRL; malformed, expired CRL<br />
* [ocsp-failure] failure to provide certificate status via OCSP; malformed, expired OCSP<br />
* [policy-failure] failure to update CP/CPS annually, failure to comply with practice in CP/CPS, misunderstanding requirements, failed implementation<br />
* [disclosure-failure] failure to disclose an ICA, failure to report revocation of an ICA, non-disclosure-of-EV-sources, miscommunication, poor communication, etc.<br />
* [audit-failure] failure to perform an audit, failure to upload audits, etc.<br />
* [audit-finding] see https://www.ccadb.org/cas/incident-report#audit-incident-reports<br />
<br />
== Vulnerability and Security Incident Reporting ==<br />
To report a vulnerability or security incident pertaining to a CA in Mozilla's Program:<br />
<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
Additionally, and not in lieu of the requirement to publicly report incidents as outlined in section [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents 2.4 of Mozilla's Root Store Policy], a CA Operator MUST disclose a serious vulnerability or security incident in Bugzilla as a [https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program secure bug] in accordance with guidance found on the [[CA/Vulnerability_Disclosure|Vulnerability Disclosure wiki page]].<br />
<br />
= Root Inclusion/Change requests and EV Treatment Enablement Requests=<br />
A representative of a CA may begin the process of root inclusion, change, or ev-enablement by filing a Bugzilla Bug as described here: <br />
* https://wiki.mozilla.org/CA/Application_Process<br />
Root Inclusion Requests are prioritized as described here:<br />
* https://wiki.mozilla.org/CA/Prioritization<br />
The whiteboard tags for [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program CA Program :: CA Certificate Root Program] are:<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-initial &#91;ca-initial&#93;] -- not enough information to begin the Information Verification phase, or not yet assigned to someone to do the Information Verification<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-verifying &#91;ca-verifying&#93;] -- in [[CA/Application_Verification#Information_Verification|Information Verification]] phase. This is a high-level review to ensure that all [[CA/Information_Checklist|required data]] has been provided in Bugzilla and the CCADB and that the appropriate tests have been run.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-ready-for-discussion &#91;ca-ready-for-discussion yyyy-mm-dd&#93;] -- Information Verification phase is complete. Ready for [[CA/Application_Verification#Public_discussion|public discussion]] and detailed CP/CPS review. <br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-in-discussion &#91;ca-in-discussion&#93;] -- in discussion in the [https://groups.google.com/a/ccadb.org/g/public CCADB public mailing list].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-cps-review &#91;ca-cps-review&#93;] -- [[CA/Application_Verification#Detailed_Review|Detailed Review]], which requires that the relevant CP/CPS and audit documents be [[CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21|thoroughly reviewed]]. As a result of such review(s), the CA may be required to update their CP/CPS to become fully aligned with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-discussion-hold &#91;ca-discussion-hold&#93;] -- discussion on hold, pending CA actions.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-hold &#91;ca-hold&#93;] -- CA's request is on hold, typically because the CA is a super-CA, so all of their subCAs have to achieve inclusion first.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-pending-approval &#91;ca-pending-approval&#93;] -- final notice of intent to approve the CA's request<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-approved &#91;ca-approved&#93;] -- request is approved, pending code changes in NSS, also including certs which are in NSS and pending code changes in PSM<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=CA%20Program&component=CA%20Certificate%20Root%20Program&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=SUPPORT&resolution=EXPIRED&resolution=MOVED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-denied&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1= &#91;ca-denied&#93;] -- request was denied. Under normal circumstances the CA may submit a new root inclusion request for a new root certificate that fully complies with Mozilla's Root Store policy.<br />
<br />
= CA Audit Statement Bugs =<br />
* [https://bugzilla.mozilla.org/buglist.cgi?&query_format=advanced&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-audit &#91;ca-audits&#93;] -- One bug may be created per CA to store audit statements or CP/CPS documents. <br />
** [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Documents Link to create ca-audit bug]<br />
** Make sure the bug has the correct product/component for the CA Certificate Program, which is [https://bugzilla.mozilla.org/buglist.cgi?&query_format=advanced&component=CA%20Documents&product=CA%20Program CA Program :: CA Documents]<br />
** Add [ca-audits] to the Whiteboard<br />
<br />
=CA Program Process or Policy Related Bugs=<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-program &#91;ca-program&#93;] -- bugs related to CA Program process, wiki pages, or policy. Note that most [https://github.com/mozilla/pkipolicy/issues CA Program Policy issues] are tracked on Github.<br />
<br />
=Certificate Revocation Related Bugs=<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-onecrl &#91;ca-onecrl&#93;] -- bugs related to updating entries in OneCRL. Under normal circumstances a Bugzilla Bug is not needed for this. Rather, the CA should [http://ccadb.org/cas/intermediates report the revocation via the Common CA Database].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?short_desc=CCADB%20entries%20generated&short_desc_type=allwordssubstr OneCRL Entries Generated] -- bugs for verifying OneCRL entries before they are pushed to production. These bugs are automatically generated from CCADB for standard revocations of intermediate certificates that are reported by CAs. Otherwise these bugs are generated by manually running the tools for specially requested additions to OneCRL.<br />
<br />
=Common CA Database (CCADB)=<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&status_whiteboard_type=allwordssubstr&status_whiteboard=ccadb-api &#91;ccadb-api&#93;] -- for requesting API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&resolution=---&query_format=advanced&status_whiteboard_type=allwordssubstr&status_whiteboard=ccadb-bug &#91;ccadb-bug&#93;] -- for issues or problems using the CCADB.<br />
* All [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&resolution=---&component=Common%20CA%20Database "CA Program : Common CA Database" Bugzilla Bugs] that do not have a whiteboard tag are considered to be enhancement requests that will be prioritized and schedule by the CCADB Steering Committee. <br />
<br />
The Priority field is used for CCADB Enhancement Requests and bugs as follows:<br />
* P1 - Development in progress<br />
* P2 - Design complete<br />
* P3 - Prioritized<br />
* P4 or not set - To be prioritized and scheduled later<br />
<br />
Bugs that unintentionally remove pre-existing functionality or negatively impact CCADB users should have priority over Enhancements, and should be set to P1. Low impact bugs will start at P4 and be considered with ERs. If it's a low LOE bug (less than 4 hours of work) it can go from P4 to P1 without prioritization/design.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/EV_Processing_for_CAs&diff=1247509CA/EV Processing for CAs2023-08-08T22:28:54Z<p>Kathleen Wilson: Added paragraph about our intent to only recognize the CAB Forum EV policy OID in the future</p>
<hr />
<div>= EV TLS Capable =<br />
Mozilla considers an intermediate certificate to be capable of issuing EV TLS certificates when all of the following are true. The intermediate certificate:<br />
* is signed by an [[CA/EV_Processing_for_CAs#EV_TLS_Capable|EV TLS Capable]] certificate (when not directly signed by the root certificate)<br />
* either directly or transitively chains up to a root certificate included in Mozilla's root store with the TLS (Websites) trust bit turned on, and EV enabled<br />
* is not revoked and not expired<br />
* does not have an Extended Key Usage (EKU) extension or does have an EKU extension containing KeyPurposeIds: anyExtendedKeyUsage or id-kp-serverAuth<br />
* has Policy Identifiers containing one or more of: 2.23.140.1.1 (CABF EV OID), 2.5.29.32.0 (anyPolicy OID), the CA's EV OIDs used by Mozilla in [https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp ExtendedValidation.cpp], or any Policy OIDs listed in [https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp ExtendedValidation.cpp] for the CA certificate.<br />
<br />
= Firefox EV Processing Logic =<br />
<br />
Firefox determines whether or not to display the Extended Validation SSL UI for a given website by performing policy validation during certificate path building and verification. Firefox ships with a list of trust anchors (root certificates), some of which are each trusted for a specific EV policy OID. If Firefox can build a trusted path from the end entity certificate to a root certificate that is trusted for a particular OID and where each certificate in the chain has that policy OID in the certificatePolicies extension (or, for intermediate and root certificates, the anyPolicy OID), then that certificate is considered an EV certificate. Additional details are as follows.<br />
<br />
=== First OID ===<br />
Firefox “recognizes” a set EV policy OIDs associated with some root certificates from some CAs in the Mozilla Root CA Program, plus the CAB Forum EV OID (2.23.140.1.1).<br />
<br />
As of Firefox version 103 and later, Firefox will try to build a path with each recognized EV OID in the end-entity certificate until it finds one that works. (This change was implemented via [https://bugzilla.mozilla.org/show_bug.cgi?id=1769150 Bugzilla #1769150])<br />
<br />
In older Firefox versions (102 or earlier), Firefox was sensitive to the position of OIDs in the certificatePolicies extension of the end-entity certificate. Firefox would only attempt to build a trusted path using the first recognized EV policy OID found in the certificatePolicies extension of the end-entity certificate. Later OIDs, even if recognized by Firefox, were ignored. Thus, if path building does not succeed using that first EV OID, the certificate would not be considered EV.<br />
<br />
=== CA-Specific OIDs ===<br />
<br />
Our long-term goal is to have Firefox only recognize the CAB Forum EV policy OID (2.23.140.1.1). So we stopped adding CA-specific EV OIDs to ExtendedValidation.cpp, and are only adding the 2.23.140.1.1 EV OID for new EV-enablement requests. This page still describes Firefox's treatment of CA-specific EV OIDs because we are not currently planning to go back and change it for root certificates that already had a CA-specific EV OID. Our current plan is to let those pre-existing root certificates expire.<br />
<br />
It is fine for the CA's certificates to also specify their CA-specific OID(s), but the 2.23.140.1.1 OID will also need to be in them.<br />
Firefox matches the EV OID found in the end-entity certificate with one or more EV OIDs associated with the root in the ExtendedValidation.cpp file. In the process of running the [[SecurityEngineering/Certificate_Verification|path building algorithm]], when a potential root certificate has been identified, the recognized EV policy OID(s) found in the end-entity certificate is compared to the EV policy OID(s) associated with the root. If they match, the candidate is a valid trust anchor, and the end-entity will be considered EV if all other checks pass. In addition, if the CAB Forum EV policy OID is a recognized OID in the certificatePolicies extension of the end-entity certificate, EV status is granted if the root is EV-enabled for any OID.<br />
<br />
=== Policy Constraints ===<br />
Any Intermediate certificates in the chain must assert a policy that includes a recognized EV policy OID found in the end-entity certificate. This means that one of the following must be true for each intermediate CA certificate in the chain:<br />
* The certificatePolicies extensions includes the anyPolicy OID (2.5.29.32.0) (Note that if the inhibitAnyPolicy extension is present, Firefox will reject the anyPolicy OID regardless of the value set for inhibitAnyPolicy)<br />
* The certificatePolicies extension includes the same “recognized” policy OID as Firefox chose from the end-entity certificate (either a CA-specific OID or the CAB Forum OID)<br />
<br />
=== Cross-Certification ===<br />
EV certificates that chain to multiple roots via cross-certification follow the rules listed above. Special care should be taken in using CA-specific EV identifiers in this situation because it is possible for there to be a mismatch between the policy Firefox chooses from the end-entity certificate and the policy associated with the root chosen by the [[SecurityEngineering/Certificate_Verification|path building algorithm]]. Best practice is to rely on the CAB Forum EV policy OID by placing it in the first position of all end-entity EV certificates.<br />
<br />
=== Revocation Checking ===<br />
An additional consideration for receiving the EV UI is that revocation checking must succeed via OCSP (or some future revocation checking mechanism) for the end-entity and intermediate CA certificate(s). If the security.OCSP.enabled preference is set to ‘0’, OCSP checking is not performed and the EV UI will not appear for otherwise valid EV certificates.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1247374NSS:Release Versions2023-08-01T18:10:11Z<p>Kathleen Wilson: fixed typo</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.91<br />
|<br />
|<br />
| 2023-04-27<br />
| '''2023-05-04'''<br />
| 2023-05-08<br />
| 114<br />
| 2023-06-06<br />
|-<br />
| 3.92 <br />(ESR)<br />
|<br />
|<br />
| 2023-05-25<br />
| '''2023-06-01'''<br />
| 2023-06-05<br />
| 115<br />
| 2023-07-04<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-06-22<br />
| '''2023-06-29'''<br />
| 2023-07-03<br />
| 116<br />
| 2023-08-01<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-07-20<br />
| '''2023-07-27'''<br />
| 2023-07-31<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.95<br />
|<br />
|<br />
| 2023-08-17<br />
| '''2023-08-24'''<br />
| 2023-08-28<br />
| 118<br />
| 2023-09-26<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1247347NSS:Release Versions2023-07-31T23:22:24Z<p>Kathleen Wilson: Added row for the July 2023 batch of root changes</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.91<br />
|<br />
|<br />
| 2023-04-27<br />
| '''2023-05-04'''<br />
| 2023-05-08<br />
| 114<br />
| 2023-06-06<br />
|-<br />
| 3.92 <br />(ESR)<br />
|<br />
|<br />
| 2023-05-25<br />
| '''2023-06-01'''<br />
| 2023-06-05<br />
| 115<br />
| 2023-07-04<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-06-22<br />
| '''2023-06-29'''<br />
| 2023-07-03<br />
| 116<br />
| 2023-08-01<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-07-20<br />
| '''2023-07-27'''<br />
| 2023-07-31<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.95<br />
|<br />
|<br />
| 2023-08-17<br />
| '''2023-08-24'''<br />
| 2023-08-28<br />
| 118<br />
| 2023-09-26<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<br />
<tr><br />
<td>3.94</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1247346NSS:Release Versions2023-07-31T23:18:33Z<p>Kathleen Wilson: Added row for the April 2023 batch of root changes</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.91<br />
|<br />
|<br />
| 2023-04-27<br />
| '''2023-05-04'''<br />
| 2023-05-08<br />
| 114<br />
| 2023-06-06<br />
|-<br />
| 3.92 <br />(ESR)<br />
|<br />
|<br />
| 2023-05-25<br />
| '''2023-06-01'''<br />
| 2023-06-05<br />
| 115<br />
| 2023-07-04<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-06-22<br />
| '''2023-06-29'''<br />
| 2023-07-03<br />
| 116<br />
| 2023-08-01<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-07-20<br />
| '''2023-07-27'''<br />
| 2023-07-31<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.95<br />
|<br />
|<br />
| 2023-08-17<br />
| '''2023-08-24'''<br />
| 2023-08-28<br />
| 118<br />
| 2023-09-26<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Additional_Trust_Changes&diff=1247331CA/Additional Trust Changes2023-07-31T18:37:22Z<p>Kathleen Wilson: Kamu SM's name-constraints have been updated.</p>
<hr />
<div>The Mozilla Root Program's official repository of the roots it trusts is [https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt certdata.txt]. Some information about the level of trust in each root is included in that file - for example, whether it's trusted for server SSL, S/MIME or both. However, not all restrictions recommended by Mozilla on the roots can be or are encoded in certdata.txt. Some are implemented in our security library, "NSS", or in Firefox and Thunderbird (so-called "PSM").<br />
<br />
Sometimes, other companies and organizations decide to use Mozilla's root store in their products. As the [[CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F|CA FAQ]] notes, Mozilla does not promise to take into account the needs of other users of its root store when making decisions. However, for the benefit of such users and on a best-efforts basis, this page documents the additional trust settings that Mozilla recommends.<br />
<br />
==Extended Validation (EV)==<br />
<br />
The status of whether a root is approved to issue EV certificates or not is [https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp stored in PSM] rather than certdata.txt.<br />
<br />
==OneCRL==<br />
<br />
While not technically a modification to the root store as we don't use it for un-trusting roots, Mozilla's [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL] system is used for communicating information about the revocation of intermediate certificates (and high-profile misissued end-entity certificates) to Firefox clients. Reports are provided about revoked intermediate certificates on the [[CA/Intermediate_Certificates|CA/Intermediate Certificates wiki page]].<br />
<br />
==Distrust After==<br />
For some root certificates Mozilla has set 'Distrust for TLS After Date' or 'Distrust for S/MIME After Date'. For certificates chaining up to those root certificates, Mozilla does not trust end-entity certificates that have a Valid-From date later than the specified distrust-after date. Certificates with a Valid-From date earlier than the distrust-after date will continue to be trusted until the certificate's natural expiration or until the certificate is revoked.<br />
<br />
These root certificates may be identified via the 'Included CA Certificates' reports on the [[CA/Included_Certificates|CA/Included Certificates wiki page]]. Within those reports look for dates in the 'Distrust for TLS After Date' and 'Distrust for S/MIME After Date' columns.<br />
<br />
==Kamu SM==<br />
<br />
The Turkish Government CA is name-constrained to *.tr. ([https://phabricator.services.mozilla.com/D177242 code change])<br />
<br />
==Symantec==<br />
In accordance [https://groups.google.com/d/topic/mozilla.dev.security.policy/FLHRT79e3XE/discussion with the consensus proposal that was adopted in 2017], Mozilla began to distrust Symantec (including GeoTrust, RapidSSL, and Thawte) certificates issued before 1-June 2016 starting in Firefox 60, and plans to distrust Symantec certificates regardless of the date of issuance starting in Firefox 64, unless they are issued by whitelisted subordinate CAs that have the following SHA-256 Subject Public Key hashes (subjectPublicKeyInfo):<br />
<br />
Apple:<br /><br />
<br />
* [https://crt.sh/?spkisha256=c0554bde87a075ec13a61f275983ae023957294b454caf0a9724e3b21b7935bc c0554bde87a075ec13a61f275983ae023957294b454caf0a9724e3b21b7935bc]<br />
* [https://crt.sh/?spkisha256=56e98deac006a729afa2ed79f9e419df69f451242596d2aaf284c74a855e352e 56e98deac006a729afa2ed79f9e419df69f451242596d2aaf284c74a855e352e]<br />
* [https://crt.sh/?spkisha256=7289c06dedd16b71a7dcca66578572e2e109b11d70ad04c2601b6743bc66d07b 7289c06dedd16b71a7dcca66578572e2e109b11d70ad04c2601b6743bc66d07b]<br />
* [https://crt.sh/?spkisha256=fae46000d8f7042558541e98acf351279589f83b6d3001c18442e4403d111849 fae46000d8f7042558541e98acf351279589f83b6d3001c18442e4403d111849]<br />
* [https://crt.sh/?spkisha256=b5cf82d47ef9823f9aa78f123186c52e8879ea84b0f822c91d83e04279b78fd5 b5cf82d47ef9823f9aa78f123186c52e8879ea84b0f822c91d83e04279b78fd5]<br />
* [https://crt.sh/?spkisha256=e24f8e8c2185da2f5e88d4579e817c47bf6eafbc8505f0f960fd5a0df4473ad3 e24f8e8c2185da2f5e88d4579e817c47bf6eafbc8505f0f960fd5a0df4473ad3]<br />
* [https://crt.sh/?spkisha256=3174d9092f9531c06026ba489891016b436d5ec02623f9aafe2009ecc3e4d557 3174d9092f9531c06026ba489891016b436d5ec02623f9aafe2009ecc3e4d557]<br />
<br />
Google:<br /><br />
<br />
* [https://crt.sh/?spkisha256=ec722969cb64200ab6638f68ac538e40abab5b19a6485661042a1061c4612776 ec722969cb64200ab6638f68ac538e40abab5b19a6485661042a1061c4612776]<br />
<br />
DigiCert:<br /><br />
<br />
* [https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26 8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26]<br />
* [https://crt.sh/?spkisha256=b94c198300cec5c057ad0727b70bbe91816992256439a7b32f4598119dda9c97 b94c198300cec5c057ad0727b70bbe91816992256439a7b32f4598119dda9c97]<br />
* [https://crt.sh/?spkisha256=7cac9a0ff315387750ba8bafdb1c2bc29b3f0bba16362ca93a90f84da2df5f3e 7cac9a0ff315387750ba8bafdb1c2bc29b3f0bba16362ca93a90f84da2df5f3e]<br />
* [https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee]<br />
<br />
Note: In some instances, multiple subordinate CAs contain the same public key, necessitating whitelisting by subjectPublicKeyInfo. Refer to ([https://bugzilla.mozilla.org/show_bug.cgi?id=1409257 Bug 1409257]) for more information.<br />
<br />
The [https://support.mozilla.org/en-US/kb/about-config-editor-firefox Firefox preference] "security.pki.distrust_ca_policy" may be set to '2' to enable distrust (regardless of issuance date) and '0' to override these changes. Mozilla plans to remove this preference in Firefox 65.<br />
<br />
In a future Firefox release, we expect to remove the whitelist, and remove the ‘websites’ trust bit from all Symantec roots. The timing of these changes, and any changes to the ‘email’ trust bit (S/MIME) have not yet been determined.<br />
<br />
<br /><br />
'''Update December 2020:''' <br />
<br /><br />
The following 10 root certificates were removed via {{bug|1670769}} from [[NSS:Release_Versions|NSS 3.60]] and [[Release_Management/Calendar|Firefox 85]].<br />
# [https://crt.sh/?id=17 GeoTrust Global CA]<br />
# [https://crt.sh/?id=4350 GeoTrust Primary Certification Authority]<br />
# [https://crt.sh/?id=847444 GeoTrust Primary Certification Authority - G3]<br />
# [https://crt.sh/?id=30 thawte Primary Root CA]<br />
# [https://crt.sh/?id=254193 thawte Primary Root CA - G3]<br />
# [https://crt.sh/?id=2771491 VeriSign Class 3 Public Primary Certification Authority - G4]<br />
# [https://crt.sh/?id=93 VeriSign Class 3 Public Primary Certification Authority - G5]<br />
# [https://crt.sh/?id=3382830 thawte Primary Root CA - G2]<br />
# [https://crt.sh/?id=4174851 GeoTrust Universal CA]<br />
# [https://crt.sh/?id=4175126 GeoTrust Universal CA 2]<br />
<br />
'''Update June 2020:''' <br />
<br /><br />
There is a [https://bugzilla.mozilla.org/show_bug.cgi?id=1465613 new Distrust-After capability] available in [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/nss/lib/ckfw/builtins/certdata.txt certdata.txt], which is enforced as of Firefox 78 ([https://bugzilla.mozilla.org/show_bug.cgi?id=1615438 Bug #1615438]), and will be enforced in Thunderbird at a later date. The following Bugzilla bugs were filed to use this capability. This update was [https://groups.google.com/d/msg/mozilla.dev.security.policy/WpJiD14tiXc/2Waf17XCFQAJ described in the mozilla.dev.security.policy forum]. <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1618404 Symantec root certs - Set CKA_NSS_SERVER_DISTRUST_AFTER]<br />
** Implemented in NSS 3.53, Firefox 78.<br />
** Setting CKA_NSS_SERVER_DISTRUST_AFTER to the specified dates distrusts TLS certs that have “Valid From” newer than the specified date. TLS certificates issued prior to this date will continue to be trusted until the certificate’s natural expiration or until we disable the trust bit or remove the root. <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1618407 Symantec root certs - Set CKA_NSS_EMAIL_DISTRUST_AFTER]<br />
** Setting CKA_NSS_EMAIL_DISTRUST_AFTER to the specified dates distrusts S/MIME certs that have “Valid From” newer than the specified date. S/MIME certificates issued prior to this date will continue to be trusted until the certificate’s natural expiration or until we disable the trust bit or remove the root.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Root_Inclusion_Considerations&diff=1247052CA/Root Inclusion Considerations2023-07-13T16:56:35Z<p>Kathleen Wilson: Updated links regarding Salesforce requirements.</p>
<hr />
<div>= Root Inclusion Considerations = <br />
<br />
This page provides guidance to help make difficult root inclusion decisions more deterministic. This page is intended to be used as a tool for identifying when a CA Operator's root inclusion request should be denied, or when a CA's root certificate should be removed from Mozilla's root store.<br />
<br />
Mozilla’s Root Store Policy says: <br />
* We will determine which CA certificates are included in Mozilla's root store based on the risks of such inclusion to typical users of our products.<br />
* We reserve the right to not include certificates from a particular CA operator in our root store. This includes (but is not limited to) cases where we believe that a CA operator has caused undue risks to users’ security, e.g. by knowingly issuing certificates without the knowledge of the entities whose information is referenced in those certificates ('MITM certificates'). <br />
* Mozilla is under no obligation to explain the reasoning behind any inclusion decision.<br />
<br />
When concerns are raised about a CA operator that currently has root certificates included in Mozilla's root store, Mozilla will take the steps described here: https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Potential_Problems.2C_Prevention.2C_Response<br />
<br />
==Unacceptable Behavior==<br />
For the following circumstances, Mozilla should deny the CA operator's root inclusion request. If the CA operator currently has root certificates in Mozilla's root store, then Mozilla should remove those root certificates or set them to be distrusted after a specified date.<br />
* There is [https://www.merriam-webster.com/legal/reasonable%20suspicion Reasonable suspicion] that the CA is closely tied, through ownership or operation, to a company engaged in any of the following:<br />
** the distribution of [https://en.wikipedia.org/wiki/Malware malware] or [https://en.wikipedia.org/wiki/Spyware spyware];<br />
** [https://en.wikipedia.org/wiki/Computer_and_network_surveillance#Network_surveillance network surveillance] that intercepts/manipulates traffic or collects private information about a person or organization and sends it to another entity without the permission of the person or organization, or in a way that endangers the privacy or device security of the person or organization; or<br />
** [https://en.wikipedia.org/wiki/Cyber_spying cyber espionage] that aims to obtain private information from a person or organization without the knowledge or permission of the person or organization for personal, economic, political or military advantage.<br />
* The CA operator is in a global region that cannot use the CCADB (per the "Export Compliance" section of the [https://a.sfdcstatic.com/content/dam/www/ocms-backup/assets/pdf/misc/salesforce_MSA.pdf Salesforce Master Subscription Agreement]), or is not capable of entering into a contractual agreement with a [https://www.treasury.gov/resource-center/sanctions/Programs/Pages/Programs.aspx US-based] company.<br />
* The CA operator appears to have:<br />
** Deliberately violated the version of [https://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] or other applicable policy that was in effect at the time that the violation occurred; or<br />
** Lied, concealed, or failed to disclose the full extent of a problem; or<br />
** Made [https://www.lawinsider.com/dictionary/intentionally-deceptive intentionally deceptive] or [https://www.lawinsider.com/dictionary/recklessly recklessly] misleading claims relating to operation of the CA or the use of its certificates.<br />
* The CA operator has:<br />
** Repeated incidents of certificate mis-issuance that the CA operator previously claimed to have resolved; <br />
** Failed to identify and remediate the root cause of their incident of certificate mis-issuance; or<br />
** Demonstrated insufficient quality or competence in their CA’s operations by frequently mis-issuing certificates, especially when such mis-issuance would be prevented by pre-issuance lint testing.<br />
<br />
Mozilla may deny a root inclusion request for reasons or behaviors not listed on this page.<br />
<br />
== Concerning Behavior ==<br />
The following situations are concerning '''in aggregate'''; meaning that a concern would be raised when a collection (several) of the main bullet points below happen. These '''concerns in aggregate''' may lead to Mozilla denying the CA operator's root inclusion request. If the CA operator currently has root certificates in Mozilla's root store and these '''concerns in aggregate''' apply, then Mozilla should perform a risk versus value assessment, and may remove those root certificates or set them to be distrusted after a specified date. <br />
<br />
* The CA’s provided address is a P.O. box, mail drop, or an address shared with numerous other companies/entities. (e.g. shell corporate registry)<br />
* The CA is using an auditing organization ([[CA/Audit_Statements#Verifying_ETSI_Auditor_Qualifications|ETSI]], [[CA/Audit_Statements#Verifying_WebTrust_Auditor_Qualifications|WebTrust]]) that has not audited other publicly trusted CAs whose root certificates are included in browser root store programs, and the [[CA/Audit_Statements#Providing_Auditor_Qualifications|Auditor Qualifications]] indicate that the audit team is inexperienced in auditing CA operations, public key infrastructure, trust services or similar information systems.<br />
** New auditors are allowed under the condition that the CA ensures that the Audit Team is lead by third-party specialists or affiliate audit firms who are experienced in auditing publicly trusted CAs, and this information must be provided as part of the Auditor Qualifications.<br />
* The CA's representatives are not fully transparent on matters such as legal domicile and Control.<br />
** "Control" (and its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors ; or (3) vote that portion of voting shares required for "control" under the law of the entity's Jurisdiction of Incorporation or Registration but in no case less than 10%.<br />
* The CA's representative is unable to demonstrate that the CA has implemented anti-corruption mechanisms (e.g. [https://www.iso.org/iso-37001-anti-bribery-management.html ISO 37001 certification]) and the CA has physical, monetary, or business nexus to a government of a country that<br />
** has an [https://freedomhouse.org/countries/freedom-net/scores Internet Freedom Score] less than 50; or<br />
** has a score less than 50 on the [https://www.transparency.org/en/cpi Corruption Perceptions Index]<br />
* The CA is (or the CA's owning entities are) associated with a government that has or is forcing end-users to install a government-issued root certificate on their devices, or the government has used certificates issued by the CA to intercept network communications.<br />
* The CA is (or the CA's owning entities are) owned or funded by an individual or government organization that is known to also own or fund a vendor that has provided software being used for network surveillance or cyber espionage to obtain private information about people or organizations without their knowledge or permission in a way that endangers the privacy or device security of those people or organizations.<br />
* The CA uses a shell company, an acquisition, or other misdirection to divert attention away from their relationship with another organization or government.<br />
<br />
== Warning Signs ==<br />
Warning signs for CA operators who have requested inclusion of their root certificates in Mozilla’s Root Store include but are not limited to the following. CA operators exhibiting these warning signs will have to either improve their operations and demonstrate their ability to maintain the higher level of operations, or their root inclusion request will be denied.<br />
<br />
The CA:<br />
* Has [[CA/Prioritization|Certificate Change Prioritization]] score of P4 or P5.<br />
* Fails to provide prompt, detailed, public, and transparent responses to Mozilla inquiries about their CA operations, root inclusion requests, policy documents, audit statements, and incidents.<br />
* Is not a [https://cabforum.org/information-for-potential-members/ voting member], [https://github.com/cabforum/forum/blob/main/Bylaws.md#31-associate-members associate member], or [https://github.com/cabforum/forum/blob/main/Bylaws.md#32-interested-parties interested party] participating in the CA/Browser Forum (CABF) Server Certificate Working Group (when applying for the Websites trust bit) or the CABF S/MIME Certificate Working Group (when applying for the Email trust bit).<br />
* Is a [[CA/Subordinate_CA_Checklist#Super-CAs|Super-CA]] that signs the certificates of subordinate CAs to only show that they have been accredited or licensed by the signing CA (i.e. the super-CA does not guarantee that their subCAs comply with the BRs and Mozilla’s root store policy.<br />
* Has audit statements from an auditor whose [[CA/Audit_Statements#Auditor_Qualifications|auditor qualifications]] are insufficient or do not pass the verification checks for [[CA/Audit_Statements#Verifying_WebTrust_Auditor_Qualifications|WebTrust auditors]] or [[CA/Audit_Statements#Verifying_ETSI_Auditor_Qualifications|ETSI auditors]].<br />
* Has non-contiguous audit periods; meaning that there is one day or more between consecutive audit periods.<br />
* Does not fully comply with the CABF Baseline Requirements that are relevant to the trust bits they are applying for.<br />
* Does not fully comply with Mozilla’s Root Store Policy or <br />
** https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Required_Practices.<br />
* Does any of the activities listed in https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Forbidden_Practices<br />
* Demonstrates unacceptable behavior in [https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla's dev-security-policy] discussion forum, as per [https://www.mozilla.org/about/governance/policies/participation/ Mozilla’s Community Participation Guidelines].<br />
* Fails to follow the [https://docs.google.com/document/d/19ALqEvHtTE6OUTz2FaOXrU9gruIdvia5EDh3hXeGpZA/ CCADB Public Code of Conduct] when posting in the [https://groups.google.com/a/ccadb.org/g/public CCADB Public] discussion forum.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Communications&diff=1246813CA/Communications2023-06-20T23:48:41Z<p>Kathleen Wilson: The COMMUNICATIONS tab moved to the My CA page in the CCADB</p>
<hr />
<div>The following are communications that have been sent to Certification Authorities participating in [[CA | Mozilla's root program.]] If you have questions regarding these communications, please first review related discussions in the Mozilla dev-security-policy forum. If your questions cannot be answered in that forum, then please send email to certificates@mozilla.org.<br />
<br />
<br />
== February 2023 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s Root Store Policy (MRSP) was recently updated to version 2.8.1 with an effective date of February 15, 2023, https://github.com/mozilla/pkipolicy/pull/265/files. Version 2.8.1 contains several clarifications and minor changes that may affect your organization. You need to be aware of these clarifications and changes to ensure your continued compliance with the MRSP. The following are summaries only of the actual language in the MRSP, and in the event of any conflicting interpretation, the MRSP takes precedence over these summaries:<br />
<br />
* You are required to follow and be aware of discussions in both the Mozilla dev-security-policy forum, https://groups.google.com/a/mozilla.org/g/dev-security-policy, and the CCADB Public List, https://groups.google.com/a/ccadb.org/g/public;<br />
* Your CP, CPS, or combined CP/CPS MUST clearly explain your CA’s domain validation procedures and indicate which subsection of section 3.2.2.4 of the CA/Browser Forum’s Baseline Requirements you are complying with;<br />
* Your CP, CPS, or combined CP/CPS MUST be updated at least every 365 days (more often is expected), and it must be reported in the CCADB in a “timely manner”, and failure to do either of these things will require that you file an incident report in Bugzilla;<br />
* You MUST maintain links to all historic versions of each CP, CPS, or combined CP/CPS from the creation of included CA certificates until such certificate hierarchies are no longer trusted by the Mozilla root store, and if your CA certificate was included by Mozilla before December 31, 2022, then you still must maintain links for “reasonably available historic versions” of your CPs, CPSes, or combined CP/CPSes; and<br />
* In the CCADB, if you elect to publish a JSON array of partial CRLs (rather than the full CRL), then the JSON Array of Partitioned CRLs must contain a critical Issuing Distribution Point extension, which shall include a URI whose value is derived from either the URI as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5) or the URL included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA.<br />
<br />
Finally, participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard user security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you very much for your continued cooperation in this pursuit.<br />
<br />
Regards,<br />
Ben Wilson<br />
Mozilla CA Program Manager<br />
<br />
<br />
<br />
== May 2022 CA Communication and Survey ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a058Z000013UmsDQAS Read-only copy of May 2022 CA Communication and Survey]<br />
** This link is '''Read Only'''. To submit your responses, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2022 CA Communication and Survey' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
=== May 2022 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00160,Q00161 Responses to Item 1] -- Compliance with MRSP v. 2.8<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00162,Q00163 Responses to Item 2] -- "Incidents" include audit findings<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00164,Q00165 Responses to Item 3] -- Auditor membership in ACAB'c and WebTrust<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00166,Q00167,Q00168 Responses to Item 4] -- Online Archival of CPs and CPSes<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00169,Q00170 Responses to Item 5] -- Full CRLs for Intermediate TLS CAs in CCADB<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00171,Q00172 Responses to Item 6.1] -- Sunsetting of SHA1 for S/MIME Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00173,Q00174 Responses to Item 6.2] -- Sunsetting of SHA1 for Other Types of Signing<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00175,Q00176 Responses to Item 7] -- Publicly Disclose Intermediate CA Certificates capable of Issuing TLS or S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00177,Q00178 Responses to Item 8] -- Misissuance of Certificate Transparency Precertificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00179,Q00180,Q00181 Responses to Item 9] -- CRL Revocation Reasons for TLS Certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00182,Q00183 Responses to Item 10] -- Public Review of Unconstrained Externally-Operated Subordinate CAs<br />
<br />
== February 2022 CA Communication ==<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla is engaged in policy review discussions to sunset the use of SHA1 for signing by CAs of CRLs, OCSP responses, and SMIME certificates.<br />
See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/CnVjV-bFcyI/m/TFuWOy2BAwAJ<br />
<br />
(Server certificate signing is governed by the Baseline Requirements, and effective June 1, 2022, OCSP responses related to server certificates cannot be signed with SHA1.)<br />
<br />
One proposal is to remove SHA1 from the list of allowed signing algorithms altogether, but before we do this, I would like your proposed sunset dates for the different types of SHA1 signing you might currently perform--SMIME certificates, ARLs/CRLs, and OCSP responses for SMIME certificates.<br />
<br />
Please participate in this important topic, which is already underway on the Mozilla dev-security-policy list. Let us know about your specific concerns and hurdles that would need to be overcome.<br />
(Some CAs have expressed willingness to quickly convert over to SHA256, while others have expressed that it is not a simple task and will require additional development work.)<br />
<br />
Thanks,<br />
Ben Wilson (bwilson@mozilla.com)<br />
Mozilla Root Store Program<br />
<br />
== April 2021 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a054o00000EL1Fo Read-only copy of April 2021 CA Communication]<br />
** This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. <br />
** Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br><br />
<br><br />
Mozilla’s Root Store Policy was recently updated to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ version 2.7.1] with an effective date of 1 May 2021. This version contains [https://github.com/mozilla/pkipolicy/pull/223 several changes] that may affect your organization and the auditors who evaluate your PKI. These changes require you to take action to ensure your continued compliance. <br />
<br><br><br />
Please review version 2.7.1 of [https://www.mozilla.org/projects/security/certs/policy/ Mozilla’s Root Store Policy] internally, and with your auditors as well. After you and your auditors have reviewed these new requirements, complete the April 2021 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your practices. Read all survey questions first before beginning to respond. <br />
<br><br><br />
To respond to this survey, [https://ccadb.org/cas/ log in to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 30-April-2021.<br />
<br><br><br />
A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Ben Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== April 2021 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00129,Q00142 Responses to Item 1] -- Review Version 2.7.1 of Mozilla's Root Store Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00131,Q00149,Q00143 Responses to Item 2] -- 398-day reuse period on domain/IP address validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00132,Q00144 Responses to Item 3] -- Clarification about EV Audit Requirements <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00133,Q00145 Responses to Item 4] -- Annual Audit Covering the CA Key Pair Lifecycle <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00136,Q00146 Responses to Item 5] -- Audit Team Qualifications<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00137,Q00147 Responses to Item 6] -- List of Incidents in Audit Reports<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00140,Q00150,Q00148 Responses to Item 7] -- Methods to Demonstrate Key Compromise<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00141,Q00157,Q00159 Responses to Item 8] -- Removal of Old Root CA Certificates (challenges and alternatives)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00156,Q00151,Q00158 Responses to Item 8 timelines] -- Timelines and strategies to replace old, non-BR compliant CA hierarchies and root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00152,Q00155,Q00153 Responses to Item 9] -- Audit Letter Validation on Intermediate Certificates<br />
<br />
== May 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J000042AUSv Read-only copy of May 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>This survey requests your input on current policy and upcoming policy changes that affect you as a participant in Mozilla's CA Certificate Program. <br />
<br><br />
<br>To respond to this survey, [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 31-May 2020. <br />
<br><br />
<br>A compiled list of CA responses to the survey will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system. <br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br><br />
<br>Regards,<br />
<br>Kathleen Wilson<br />
<br>Mozilla CA Program Manager<br />
<br />
=== May 2020 Responses ===<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00099,Q00100 Responses to Item 1] -- Impact of COVID-19 Restrictions<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00101,Q00102, Responses to Item 2] -- Mozilla Root Store Policy version 2.7 Requirements and Deadlines <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00103,Q00104 Responses to Item 3] -- Reducing Maximum Validity Period for TLS Certificates <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107 Responses to Sub Item 3.1] -- Limit TLS Certificates to 398-day validity<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00108,Q00109,Q00110 Responses to Sub Item 3.2] -- Limit re-use of domain name and IP address verification to 398 days<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00111,Q00112 Responses to Item 4] -- CA/Browser Forum Ballot for Browser Alignment <br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00113,Q00114,Q00115 Responses to Sub Item 4.1] -- CA/Browser Forum defined-policy OID in Subscriber Cert certificatePolicies<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00116,Q00117,Q00118 Responses to Sub Item 4.2] -- Byte-for-byte Identical Issuer and Subject Distinguished Names<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00119,Q00120,Q00121 Responses to Sub Item 4.3] -- Text-searchable PDF Audit Statements<br />
** [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00122,Q00123,Q00124 Responses to Sub Item 4.4] -- OCSP Requirements<br />
<br />
== January 2020 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003waNOW Read-only copy of January 2020 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2020 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/ updated]. The 2.7 version went into effect on 1-January 2020. This version contains a [https://github.com/mozilla/pkipolicy/pull/199/files number of changes] that may affect your organization and will require you to take action to comply. Please review Mozilla’s updated Root Store Policy and complete the January 2020 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your Certificate Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘January 2020 CA Communication' survey. Please enter your response by 31 January 2020.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== January 2020 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00082,Q00083 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00084,Q00085,Q00098 Responses to Action 2] -- Update CP/CPS <br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00086,Q00087,Q00097 Responses to Action 3] -- Include EKUs in All End-entity Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00088,Q00089 Responses to Action 4] -- Ensure Audit Reports are Properly Formatted<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00090,Q00096,Q00091 Responses to Action 5] -- Resolve Audit Issues with Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00092,Q00093 Responses to Action 6] -- Incident Reporting<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00094,Q00095 Responses to Action 7] -- Compliance with BRs<br />
<br />
== November 2018 CA Communication (Underscores in dNSNames) ==<br />
On November 12, 2018, the following message was sent to all CAs in the Mozilla program, alerting them to CA/Browser Forum SC12 that established a brief sunset period for the use of underscore characters in dNSNames in publicly-trusted TLS certificates.<br />
<br /><br />
<br />
Dear Certification Authority,<br />
<br />
The CA/Browser Forum recently approved [1] a clarification to the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (BRs) that may affect you. Domain names containing underscore (“_”) characters are not permitted to be encoded as dNSName types in the subjectAlternativeName (SAN) field of BR-compliant certificates. This requirement derives from section 4.2.1.6 of RFC 5280 that the BRs require CAs to comply with by reference.<br />
<br />
Section 7.1.4.2.1 of the BRs will add the following language that clarifies the existing requirement and adds a short time in which CAs must discontinue the use of underscore characters in dNSNames:<br />
-----<br />
Prior to April 1, 2019, certificates containing underscore characters (“_”) in domain labels in dNSName entries MAY be issued as follows:<br />
* dNSName entries MAY include underscore characters such that replacing all underscore characters with hyphen characters (“-“) would result in a valid domain label, and;<br />
* Underscore characters MUST NOT be placed in the left most domain label, and;<br />
* Such certificates MUST NOT be valid for longer than 30 days.<br />
<br />
All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019.<br />
<br />
After April 30, 2019, underscore characters (“_”) MUST NOT be present in dNSName entries.<br />
-----<br />
This new language will go into effect on December 10, 2018 when the IPR review period for ballot SC12 [1] is completed. At that time, CAs must be prepared to stop issuing publicly-trusted TLS certificates containing the underscore character in any dNSName with validity periods of more than 30 days.<br />
<br />
As a participant in Mozilla's CA Certificate Program, we want you to be aware of this important change, and ask that you take any necessary steps to comply. No further action related to this change is requested at this time.<br />
<br />
Regards,<br />
<br />
Wayne Thayer<br />
Mozilla CA Program Manager<br />
<br />
[1] https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/<br />
<br />
=== November 2018 Responses ===<br />
* No survey was included in this CA Communication<br />
<br />
== September 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL Read-only copy of September 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'September 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br><br />
<br>Mozilla’s [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] was recently [https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/ updated]. The 2.6.1 version went into effect on 1-July, 2018. This version contains a number of changes that may affect your organization and will require you to take action to comply. This survey also contains information regarding other recent and upcoming changes that may affect your Certification Authority (CA).<br />
<br><br />
<br>As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.<br />
<br><br />
<br>To respond to this survey, [https://ccadb.org/cas/ log in to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘September 2018 CA Communication' survey. Please enter your response by 30-September 2018.<br />
<br><br />
<br>A compiled list of CA responses to the survey action items will be [https://wiki.mozilla.org/CA/Communications automatically and immediately published] by the CCADB system.<br />
<br><br />
<br>Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br><br />
<br>Regards,<br />
<br>Wayne Thayer<br />
<br>Mozilla CA Program Manager<br />
<br />
=== September 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00068,Q00069 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00070,Q00071 Responses to Action 2] -- Update CP/CPS<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00072,Q00073 Responses to Action 3] -- Transition to Separate Intermediate Certificates for SSL and S/MIME<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00074,Q00075 Responses to Action 4] -- Ensure Audit Reports comply with Mozilla’s Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00076,Q00077 Responses to Action 5] -- Discontinue use of BR Validation Methods 3.2.2.4.1 and 3.2.2.4.5<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00078,Q00079 Responses to Action 6] -- Disclose Intermediate Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00080,Q00081 Responses to Action 7] -- Submit TLS Certificates to CT Logs for Mozilla's CRLite<br />
<br />
== January 2018 CA Communication ==<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mqMFN Read-only copy of January 2018 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br /><br />
Dear Certification Authority,<br />
<br /><br /><br />
2018 has already generated some important news for Certification Authorities, and as a result we are sending this message to ensure that every CA in the Mozilla program is aware of current events and impending deadlines.<br />
<br /><br /><br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.<br />
<br /><br /><br />
To respond to this survey, login to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Please enter your response by 9-February 2018.<br />
<br /><br /><br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br /><br /><br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br /><br /><br />
Regards,<br /><br />
Wayne Thayer<br /><br />
Mozilla CA Program Manager<br /><br />
<br />
=== January 2018 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00056,Q00057 Responses to Action 1] -- Disclose Use of Methods 3.2.2.4.9 or 3.2.2.4.10 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00058,Q00059 Responses to Action 2] -- Disclose Use of Methods 3.2.2.4.1 or 3.2.2.4.5 for Domain Validation<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00060,Q00061 Responses to Action 3] -- Disclose All Non-Technically-Constrained Subordinate CA Certificates<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00062,Q00063 Responses to Action 4] -- Complete BR Self Assessment<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00064,Q00065 Responses to Action 5] -- Update CP/CPS to Comply with version 2.5 of Mozilla Root Store Policy<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00066,Q00067 Responses to Action 6] -- Reduce SSL Certificate Validity Periods to 825 Days or Less by March 1, 2018<br />
<br />
== November 2017 CA Communication ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7 Read-only copy of November 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [http://ccadb.org/cas/ login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Make sure you click on the ''''Submit'''' button at the bottom of the survey, and '''make sure you get a good 'survey submitted' response''' -- there are required fields.<br />
<br />
Dear Certification Authority, <br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, login to the [http://ccadb.org/cas Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Please enter your response by December 15, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be [[CA/Communications|automatically and immediately published]] by the CCADB system.<br />
<br />
Participation in [[CA|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== November 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [http://ccadb.org/ Common CA Database (CCADB)].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00035,Q00036 Responses to Action 1] -- Full compliance with version 2.5 of [https://www.mozilla.org/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00037,Q00044 Responses to Action 2] -- non-technically-constrained intermediate certificates must be [http://ccadb.org/cas/intermediates disclosed in CCADB] within one week of creation. '''New requirements''' for [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#technically-constrained technical constraints on intermediate certificates issuing S/MIME certificates].<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00038,Q00045 Responses to Action 3] -- Annual updates via [http://ccadb.org/cas/updates CCADB Audit Cases]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00050,Q00051 Responses to Action 4] -- Reiterate [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#audit-parameters audit requirements] and '''penalty for incomplete audit statements'''<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00039,Q00046 Responses to Action 5] -- Perform a [[CA/BR_Self-Assessment|BR Self Assessment]]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00042,Q00048 Responses to Action 6] -- Provide tested email address for [https://ccadb.my.salesforce-sites.com/mozilla/CAInformationReport Problem Reporting Mechanism]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00040,Q00047 Responses to Action 7] -- Follow new developments and effective dates for [http://tools.ietf.org/html/rfc6844 Certification Authority Authorization (CAA)]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00052,Q00053 Responses to Action 8] -- Check [https://groups.google.com/d/msg/mozilla.dev.security.policy/4kj8Jeem0EU/GvqsgIzSAAAJ issuance of certs to .tg domains] from October 25 to November 11, 2017.<br />
<br />
== May 2017 - Announcing CCADB Changes ==<br />
<br /><br />
Subject: Common CA Database (CCADB) changes May 19-21, 2017<br />
<br /><br /><br />
Message:<br /><br /><br />
Dear Certification Authority,<br />
<br /><br />
<br /><br />
The Common CA Database (CCADB) will undergo the following changes this weekend, May 19 to May 21. During this time, the old URLs listed below will stop working, and there will be some time when the CCADB is in read-only mode.<br />
<br /><br />
<br /><br />
On May 19 the following three breaking changes are planned, meaning that the old URLs will no longer work. Any links or bookmarks to these URLs will need to be updated. After these changes are made, I will also update Mozilla's wiki pages to point to the new URLs.<br />
<br /><br />
<br /><br />
1) The CA login page and the domain CAs see when they are logged into the CCADB will change.<br />
<br /><br />
https://mozillacacommunity.force.com/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb.force.com/<br />
<br /><br />
<br /><br />
2) The links to reports that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/CA/<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/mozilla/<br />
<br /><br />
<br /><br />
3) The links to CA communication responses that are published directly from the CCADB will change.<br />
<br /><br />
https://mozillacaprogram.secure.force.com/Communications<br />
<br /><br />
will be changed to<br />
<br /><br />
https://ccadb-public.secure.force.com/Surveys<br />
<br /><br />
<br /><br />
Then on May 21 between 12am and 4am PDT, the CCADB will be in read-only mode while Salesforce performs an instance refresh to upgrade the infrastructure supporting the CCADB instance in their data centers.<br />
<br /><br />
<br /><br />
Regards,<br />
<br /><br />
Kathleen<br />
<br />
== April 2017 ==<br />
<br />
Note: The deadline to reply to this survey has [https://groups.google.com/d/msg/mozilla.dev.security.policy/03rdTdnm7iw/NQUHmWOcEAAJ been extended] by one week, to May 5, 2017.<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000003WrzBC Read-only copy of April 2017 CA Communication]<br />
** CAs: This link is '''Read Only'''. To submit your response, you must [https://ccadb.force.com/CustomLogin login to the CCADB], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in [[CA:IncludedCAs|Mozilla's CA Certificate Program]].<br />
<br />
To respond to this survey, [https://mozillacacommunity.force.com/CustomLogin login to the Common CA Database (CCADB)], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Please enter your response by April 28, 2017.<br />
<br />
A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.<br />
<br />
In addition to responding to the action items in this survey, we are instituting a program requirement that you follow discussions in the [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] forum, which includes discussions about upcoming changes to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy], questions and clarification about policy and expectations, root certificate [[CA|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] or other program requirements. You are not required to contribute to those discussions, only to be aware of them. However, we hope you will participate and help shape the future of Mozilla's CA Certificate Program.<br />
<br />
Participation in [[CA:Overview|Mozilla's CA Certificate Program]] is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br /><br />
Kathleen Wilson<br /><br />
Mozilla CA Program Manager<br />
<br />
=== April 2017 Responses ===<br />
<br />
The reports in the following links are automatically generated from data in the [[CA:CommonCADatabase|Common CA Database]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00015,Q00030 Responses to Action 1] -- Domain Validation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 2 and Action 10] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00022,Q00029 Responses to Action 3] -- Updated Mozilla CA Certificate Policy<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00017,Q00031 Responses to Action 4] -- Audit Statements, annual updates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00018,Q00032 Responses to Action 5] -- Audit Statement Contents<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00021,Q00033 Responses to Action 6] -- Qualified Audit Statements<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00019 Responses to Action 7] -- BR Compliance Bugs<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 Responses to Action 8] -- Confirm Completion of Previous Commitments<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00027 Responses to Action 9] -- Registration Authorities<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 10 and Action 2] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00023 Responses to Action 11] -- Certification Authority Authorization (CAA)<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00028 Responses to Action 12] -- Problem Reporting Mechanism<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00024 Responses to Action 13] -- SHA-1 and S/MIME<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00034 Responses to Action 14] -- Certificate Validity Periods in TLS/SSL Certs<br />
<br />
== March 2016 ==<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommunicationSurveySample?CACommunicationId=a05o000000iHdtx Read-only copy of March 2016 CA Communication]<br />
<br />
Dear Certification Authority,<br />
<br />
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program, by April 22, 2016.<br />
<br />
To respond to this survey, please login to the [[CA:SalesforceCommunity|CA Community in Salesforce]], then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'March 2016 CA Communication' survey. Please enter your response by April 22, 2016. <br />
<br />
A compiled list of CA responses to the survey action items will be [[CA:Communications#March_2016_Responses|automatically and immediately published]] by Salesforce.<br />
<br />
In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the [https://groups.google.com/forum/#!forum/mozilla.dev.security.policy mozilla.dev.security.policy] forum, which includes discussions about [[CA:CertificatePolicyV2.3|upcoming changes to Mozilla's CA Certificate Policy]], questions and clarification about policy and expectations, root certificate [[CA:Schedule|inclusion/change requests]], and certificates that are found to be non-compliant with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements]. Your contributions to the discussions will help shape the future of [[CA:Overview|Mozilla's CA Certificate Program]].<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Mozilla CA Program Manager<br />
<br />
=== March 2016 Responses ===<br />
<br />
The following links are automatically generated from data in the [[CA:SalesforceCommunity|CA Community in Salesforce]].<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommSummaryReport?CommunicationID=a05o000000iHdtx CA Responses to March 2016 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00001,Q00013 Responses to Action #1a] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00002,Q00014 Responses to Action #1b] -- SHA-1 Deprecation dates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 Responses to Action #1c] -- SHA-1 Deprecation<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 Responses to Action #2] -- Entering intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00005 Responses to Action #3] -- Entering revoked intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00006&QuestionIdForText=Q00007 Responses to Action #4] -- [[SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix|Removing workarounds]] to compatibility issues that were encountered involving certificates that did not conform to the Baseline Requirements. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00008 Responses to Action #5] -- Plans to remove old/retired root certificates<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00009 Responses to Action #6] -- Confirmation of understanding that all certificates, including test certificates, must conform to stated policies<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00012 Responses to Action #7] -- [[CA:RootTransferPolicy|Mozilla's Root Transfer Policy]]<br />
<br />
== May 2015 ==<br />
<br />
Dear Certification Authority, <br />
<br />
This email requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by June 5, 2015, with your response to the action items by clicking on the survey link below. A compiled list of CA responses to these action items will be published. <br />
<br />
Certification Authority: <CA Account Name><br />
<br />
Your Survey Link: <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/TakeSurvey?id=a04o000000M89RCAAZ&cId=&caId=none Survey Link] -- '''IMPORTANT: CA's do NOT use the link in this wiki page! This link will NOT record your response. Please use the link that was emailed to you.'''<br />
<br />
Please use the above link to read and respond to the action items. Note that you may access the above link multiple times to update your responses.<br />
<br />
Additionally, we plan to update Mozilla's CA Certificate Policy soon, and will be discussing proposed policy updates in the mozilla.dev.security.policy forum, https://www.mozilla.org/en-US/about/forums/#dev-security-policy. We encourage you to monitor the discussions to see how the updates will impact you, and your participation in the discussions will help shape the policy updates.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards, <br />
<br />
Kathleen Wilson, <br />
Mozilla <br />
CA Program Manager<br />
<br />
=== May 2015 Responses ===<br />
<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationSummaryReport?CommunicationId=a04o000000M89RCAAZ CA Responses to May 2015 CA Communication]<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%233:%20After%20January%201,%202016 Responses to Action #3] -- SHA-1 Deprecation Plans<br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%234:%20Workarounds%20were%20implemented Responses to Action #4] -- Removing workarounds implemented to allow mozilla::pkix to handle the things listed here https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix. <br />
* [https://ccadb.my.salesforce-sites.com/Surveys/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%235:%20We%20wish%20to%20understand%20what%20support Responses to Action #5] -- IPv6 survey<br />
<br />
== May 2014 ==<br />
<br />
Subject: Mozilla Communication: Action requested by May 30, 2014<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by May 30, 2014, with your response to these action items. A compiled list of CA responses to the following action items will be published. <br />
<br />
CA Certificate Inclusion Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/<br />
<br />
CA Certificate Maintenance Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/<br />
<br />
Spreadsheet of included root certificates: http://www.mozilla.org/about/governance/policies/security-group/certs/included/<br />
<br />
1) Ensure that Mozilla’s [http://www.mozilla.org/about/governance/policies/security-group/certs/included/ spreadsheet of included root certificates] has the correct link to your most recent audit statement, and that the date of the audit statement is correct. As per [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/ Mozilla's CA Certificate Maintenance Policy], we require that all CAs whose certificates are distributed with our software products provide us an updated statement annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties. To notify us of an updated statement of attestation, send email to certificates@mozilla.org or [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates submit a bug report] into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "mozilla.org" product.<br />
If you are not proactively sending Mozilla your updated audit statements, please create a process to do so.<br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent audit statement, and the audit statement date is correct.<br />
* B) Here is the most recent audit statement for our certificates that are included in Mozilla’s CA program: <insert link here> <br />
* C) We plan to send Mozilla our current audit statement by <insert date here>.<br />
* D) We do not have a current audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
2) Send Mozilla the link to your most recent [https://cabforum.org/about-the-baseline-requirements/ Baseline Requirements] audit statement. Details about Mozilla's audit requirements are listed in section 11 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy]. The Baseline Requirements audit statement should also be proactively sent to Mozilla each year, along with the other audit statements as described in action #1. <br />
<br />
Please respond with one of the following: <br />
* A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent Baseline Requirements audit statement.<br />
* B) Here is the most recent Baseline Requirements audit statement for our certificates that are included in Mozilla’s CA program: <insert link here>. <br />
* C) We plan to send Mozilla our current Baseline Requirements audit statement by <insert date here and explain reason for delay>.<br />
* D) The websites (SSL/TLS) trust bit is not enabled for our certificates that are included in Mozilla's CA program.<br />
* E) We do not have a current Baseline Requirements audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.<br />
<br />
3) Test Mozilla's new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed. <br />
The new Certificate Verification library (mozilla::pkix) was announced here: https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ .<br />
Mozilla::pkix includes some changes in support of current best practices and policies, as listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes .<br />
How to test: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing .<br />
<br />
Please respond with one of the following: <br />
* A) We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix.<br />
* B) We have found the following issues when testing certificates in our CA hierarchy with mozilla::pkix. <descriptions or Bugzilla bug numbers, related URLs and/or certificates><br />
* C) We are testing certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and plan to send Mozilla our results by <insert date here, must be before June 30, 2014>.<br />
<br />
4) Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix<br />
<br />
Please respond with one of the following: <br />
* A) We have not and will not issue certificates with any of the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page.<br />
* B) We have previously issued certificates with the following problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page: <list the problems that needed to be fixed>. The last of those certificates expire <insert dates here, one date per problem>. We will not issue new certificates with the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page as of this date: <date when your operations will be updated, no later than June 30, 2014><br />
<br />
5) Send Mozilla information about your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, as per Items #8, 9, and 10 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy].<br />
<br />
Please provide a URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, and contains the required information according to section 10 of Mozilla's CA Certificate Inclusion Policy. If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificates" component of the "mozilla.org" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates)<br />
<br />
Additionally, please respond with one of the following: <br />
* A) All subordinate CA certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy.<br />
* B) We request an extension for the following specific subordinate CA certificates, because these subordinate CAs need more time to transition from their legacy systems to their new CA hierarchy: <list of issuer hash, issuer public key hash, and certificate serial number>. For each subordinate CA who needs to operate in their legacy design a little longer, the attached document explains the reason that continued operation is needed and their target date for resolution. <attach document(s) to response><br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. <br />
<br />
Regards, <br />
<br />
Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== May 2014 Responses ===<br />
<br />
[https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml CA Responses to May 2014 Communication]<br />
<br />
== July 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by August 16, 2013<br />
<br />
Dear Certification Authority,<br />
<br />
Mozilla’s CA Certificate Policy has been updated with a few important changes. This update was motivated by security concerns regarding ICANN granting applied-for new gTLD strings. Additionally, we want to make it very clear that there will be serious consequences if it is found that a CA has knowingly or intentionally mis-issued certificates chaining to trust anchors in Mozilla’s program.<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of applications.<br />
<br />
Please carefully review the following wiki page for information about the changes introduced in version 2.2 of Mozilla’s CA Certificate Policy.<br />
<br />
https://wiki.mozilla.org/CA:CertificatePolicyV2.2<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by August 16, 2013, with your response to the following action items. <br />
<br />
1) Update your CA operations and policies to include the CA/Browser Forum’s Baseline Requirement #11.1.4 regarding new gTLD domains, and subscribe to ICANN’s new gTLD Registry Agreement notification mailing list at: https://mm.icann.org/mailman/listinfo/gtldnotification<br />
<br />
Please respond with one of the following:<br />
* A) No action required, because we have not and will not issue SSL certificates with internal or private domain names chaining up to root certificates that are included in Mozilla’s program.<br />
* B) We have issued or may issue SSL certificates with internal or private domain names that chain up to root certificates that are included in Mozilla’s program, so we are implementing Baseline Requirement #11.1.4, and will subscribe to ICANN’s notification service regarding applied-for-gTLD strings. We plan to have this completed by September 16, 2013.<br />
* C) We have already implemented Baseline Requirement #11.1.4, and have subscribed to ICANN’s notification service regarding applied-for-gTLD strings.<br />
<br />
2) Review your CA operations and customers to ensure that there are no certificates chaining up to your trust anchors that are included in Mozilla’s program that may be used for MITM or “traffic management” of domain names or IP addresses that the certificate holder does not own or control. [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla’s CA Certificate Enforcement Policy] has been updated to make it clear that Mozilla will not tolerate this use of publicly trusted certificates. <br />
<br />
Please respond with:<br />
* “We have reviewed Mozilla’s updated CA Certificate Enforcement Policy and understand that knowing or intentional mis-issuance of a certificate is expressly against Mozilla’s CA Certificate Policy and could result in removal of all of our certificates from Mozilla’s products.”<br />
<br />
3) Ensure that your CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current, including links to the CP/CPS documents, audit statements, and test websites. Mozilla will be adding a column to this spreadsheet to indicate the date of the most recent audit statement for each root certificate.<br />
<br />
http://www.mozilla.org/projects/security/certs/included/index.html<br />
<br />
Please respond with one of the following:<br />
* A) Our CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current for all of our included certificates.<br />
* B) Here is the current information for our certificates that are included in Mozilla’s program: <insert data here><br />
<br />
4) Complete the action items from Mozilla’s January CA Communication.<br />
* https://wiki.mozilla.org/CA:Communications#January_10.2C_2013<br />
* https://wiki.mozilla.org/CA:Communications#January_2013_Responses<br />
<br />
Please respond with one of the following:<br />
* A) Our recorded response to the January CA Communication is complete and correct.<br />
* B) We have the following updated status for our response to the January CA Communication: <insert data here><br />
<br />
5) Follow discussion about the changes to policy and code that Mozilla will be making in order to improve how revocation checking is handled in Firefox. Discussions will be held in the mozilla.dev.security.policy forum, and descriptions of the changes that will be considered for both policy and code will be provided here: https://wiki.mozilla.org/CA:ImprovingRevocation<br />
As part of this effort, Mozilla will be implementing a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker. More information will follow, and policy will be added soon to require CAs to send Mozilla revocation information. We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
<br />
=== July 2013 Responses ===<br />
<br />
* [https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGR1TmZLZnJ1RThHRDcwMDJRaXZicFE&output=html CA Responses to July 2013 Communication]<br />
<br />
== January 2013 ==<br />
<br />
Subject: Mozilla Communication: Action requested by January 31, 2013. <br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by January 31, 2013, with your response to these action items. A compiled list of CA responses to the following action items will be published.<br />
<br />
1) Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations. <br />
<br />
Version 2.1 of Mozilla’s CA Certificate Policy is in final review, and will be ratified and published in Q1 of 2013. There are changes to the policy that may impact your current operations, so we encourage you to review the changes that are indicated in red or bold text here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html<br />
<br />
There will be a transition period for CAs to bring existing customers into compliance with the new policy, as described here:<br />
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1<br />
<br />
Please respond to this action item with one of the following:<br />
* a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.<br />
* b) The proposed changes to Mozilla’s CA Certificate Policy impact our CA operations, but we will be able to complete the transition within the allotted time frame.<br />
* c) We will not be able to update our CA operations to comply with the proposed version 2.1 of Mozilla’s CA Certificate Policy within the allotted time frame, because <insert reason(s)>. We plan to meet the new requirements by <insert date>.<br />
<br />
2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements.<br />
<br />
The CA/Browser Forum (http://www.cabforum.org) released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which became effective on July 1, 2012. It is our expectation that as of January 2013 CA issuance of SSL certificates will be audited against these Baseline Requirements as well as the acceptable audit criteria that are listed in Mozilla’s CA Certificate Policy.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.<br />
* b) Not applicable, because we do not issue SSL certificates.<br />
* c) We are working towards compliance with the CA/Browser Forum’s Baseline Requirements, but we need to complete <insert list of tasks>. We plan to have this completed by <insert date>.<br />
<br />
3) Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit.<br />
<br />
Due to the recent incident in which a mis-issued intermediate certificate was found (https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates), we are concerned that CAs may have responded to our last communication based on their policies, rather than checking their certificate databases. Therefore, we request that you scan your certificate database and inform Mozilla if you find any un-expired intermediate certificates in your CA hierarchy that should not be trusted. In your reply, please attach all such intermediate certificates, even if you have already revoked them.<br />
<br />
While you are scanning your certificate databases to ensure that all certificates with basicConstraints:CA:TRUE have been issued in accordance with your CPS, please also check for compliance with the following practices.<br />
* All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.<br />
* All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.<br />
* All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration).<br />
* All end-entity certificates with RSA key sizes smaller than 2048 bits expire no later than December 2013.<br />
* Certificates are not issued with sequential serial numbers. If it is found that certificates have been issued with contiguous serial numbers, then the subject of those certificates must contain unpredictable data that is not under the control of the certificate subscriber.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* b) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
* c) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.<br />
* d) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.<br />
<br />
4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name.<br />
<br />
The CA/Browser Forum’s Baseline Requirements state: <br />
“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 Server 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.”<br />
<br />
This practice is being eliminated for security reasons, so we encourage all CAs to begin working with their customers to transition to alternative arrangements, and to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names as soon as possible rather than waiting until the deadline.<br />
<br />
Please respond to this action item with one of the following:<br />
* a) We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names.<br />
* b) We plan to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names by <insert date>.<br />
<br />
5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it. We expect this website to endure for the lifetime of the root, or until you notify us of an alternative URL. The website does not need to support high traffic loads or have greater than 99% uptime.<br />
<br />
Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson, <br />
Module Owner of Mozilla's CA Certificates Module <br />
<br />
=== January 2013 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dHdISmM3c05tb1dMQjlJclJqS21QNmc&output=html CA Responses to January 2013 Communication] -- Contains two spreadsheets: "Action Item Responses" and "Test Website URLs".<br />
<br />
== February 2012 ==<br />
<br />
Subject: Mozilla Communication: Action requested by March 2, 2012<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Please reply by March 2, 2012, to confirm completion of the following actions or state when these actions will be completed.<br />
<br />
1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012. For each subordinate CA that is revoked, send me:<br />
* a) The certificate that signed the subCA. If it is a root certificate in NSS, then the root certificate's subject and SHA1 fingerprint.<br />
* b) The Serial Number of the revoked certificate.<br />
* c) The CRL that contains the serial number of the revoked certificate.<br />
<br />
As a CA in Mozilla’s root program you are ultimately responsible for certificates issued by you and any intermediate CAs that chain up to your roots. After April 27, 2012, if it is found that a subordinate CA is being used for MITM, we will take action to mitigate, including and up to removing the corresponding root certificate. Based on Mozilla’s assessment, we may also remove any of your other root certificates, and root certificates from other organizations that cross-sign your certificates.<br />
<br />
I am planning to publish a compiled list of CA responses to all of the action items in this communication. Therefore, I recommend responding to action item #1 with one of the following choices:<br />
* a) Does not apply, because we do not issue subCA certificates to third parties.<br />
* b) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
* c) We are reviewing all of our subCAs and will take the necessary action by <date>. <br />
* d) We have revoked such subCA certificates, and here is the requested information.<br />
* e) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM. ''(Note: This option was added after the communication was sent.)''<br />
<br />
2) If you issue subordinate CAs to third parties or your CP/CPS permits you to do so in the future, please add a statement to your CP/CPS committing that you will not issue a subordinate certificate that can be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control. Send me the URL to the updated document(s) and the impacted sections or page numbers. <br />
<br />
3) Please scan all of your EV SSL certificates and revoke any that do not meet the EV requirements. This includes, but is not limited to maximum validity period of the certificate, subject naming, minimum key sizes, required extensions, and maximum expiration time of OCSP responses.<br />
<br />
4) Certificates chaining to root certificates in Mozilla’s root program should not have MD5 algorithms or RSA keys shorter than 1024 bits long. Please scan the certificates chaining to your root certificates in NSS, and revoke any certificates that contain small key sizes or MD5 algorithms. <br />
<br />
5) The CA/Browser Forum has released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which is available here: http://www.cabforum.org/. Discussions are in progress in the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate Policy to add a requirement that CAs also meet these baseline requirements for issuance of SSL/TLS certificates. Please contribute to the discussions in the mozilla.dev.security.policy forum, and update your operations and documentation as needed to meet the baseline requirements by the effective date of July 1, 2012.<br />
<br />
The currently proposed updates to Mozilla’s CA Certificate Policy are here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
=== February 2012 Responses ===<br />
<br />
[https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGxsWlZEdGFDaW9JTlNTUGxBNWhqSlE&output=html CA Responses] -- spreadsheet of the responses to the action items of the CA Communication that was sent on February 17, 2012.<br />
<br />
Response Key:<br />
* IP = "In Progress"<br />
* ? = I need further clarification on the response<br />
* N/A = "Not Applicable"<br />
** N/A for Action #2 means that the CP/CPS does not allow for externally-operated subCAs.<br />
** N/A for Action #3 means that the CA is not issuing EV certs under the roots included in NSS.<br />
* Responses to action #1 can be one or more of the following. If option C is listed, there is also a date by which the CA plans to complete their investigation and provide further information.<br />
** A) Does not apply, because the CA does not have externally-operated subCAs chaining to roots in NSS.<br />
** B) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
** C) The CA is reviewing all of their subCAs and will take the necessary action by <date>.<br />
** D) The CA has revoked such subCA certificates, and provided the requested information.<br />
** E) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM.<br />
<br />
== September 2011 ==<br />
<br />
Subject: Mozilla Communication: Immediate action requested<br />
<br />
Dear Certification Authority,<br />
<br />
This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program. <br />
<br />
Mozilla recently removed the DigiNotar root certificate in response to their failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates (https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up). If you ever have reason to suspect a security breach or mis-issuance has occurred at your CA or elsewhere, please contact security@mozilla.org immediately.<br />
<br />
Please confirm completion of the following actions or state when these actions will be completed, and provide the requested information no later than September 16, 2011:<br />
<br />
1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs.<br />
<br />
2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included<br />
<br />
3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance.<br />
<br />
4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked.<br />
<br />
5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either:<br />
<br />
a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical)<br />
<br />
OR<br />
<br />
b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public 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 subordinate CA's internal operations.<br />
<br />
Each action requested above applies both to your root and to these third parties.<br />
<br />
Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your participation in this pursuit.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== April 2011 ==<br />
<br />
Subject: Mozilla Communication: Policy Discussions are in Progress that may Impact Your CA<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to three important items that we would like to bring to your attention.<br />
<br />
1) The CA/Browser Forum has published a final draft of the document "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." We are now hosting a discussion about this document in the mozilla.dev.security.policy forum. For more information, see http://cabforum.org/. <br />
The document is here: http://cabforum.org/Baseline_Requirements_Draft_30b.pdf<br />
<br />
Mozilla supports the CA/Browser Forum’s efforts in this area. After version 1.0 of the CA/Browser Forum’s Baseline Requirements document is published, we will have a discussion to add a requirement to the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/) that CAs include the CA/Browser Forum Baseline Requirements in their policies, practices, and audits. Therefore, we urge you to review the draft of the Baseline Requirements, assessing the impact to your CA policies and practices, and participate in the current discussions about these requirements. The CA/Browser Forum has set the duration of this discussion to 45 days from April 11.<br />
<br />
2) Mozilla has begun discussions about the Phase 2 items to be considered for updating the Mozilla CA Certificate Policy, https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. The current discussions are focused on RAs and Subordinate CAs. We recommend that you monitor and contribute to these discussions so that you are aware of how the potential changes to the Mozilla CA Certificate Policy may impact you.<br />
<br />
3) As per previous communications, we will implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== February 2011 ==<br />
<br />
Subject: Mozilla Communication: Version 2.0 of Mozilla CA Certificate Policy has been published<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla has ratified and published Version 2.0 of the Mozilla CA Certificate Policy. <br />
<br />
The new policy is here:<br />
http://www.mozilla.org/projects/security/certs/policy/ <br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than August 8, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. Now that this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== January 2011 ==<br />
<br />
Subject: Mozilla Communication: Major Pending Update to Mozilla CA Certificate Policy<br />
<br />
Dear Certification Authority,<br />
<br />
As per my previous communication, Mozilla is preparing to update the Mozilla CA Certificate Policy. The forthcoming changes will come in multiple phases, and the first phase is nearly complete. Discussion about the first phase of changes has proceeded for several months in the mozilla.dev.security.policy forum. Version 2.0 of the policy, reflecting the first phase of updates, is now under final review. Mozilla expects it to be ratified by January 31, 2011.<br />
<br />
There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than April 30, 2011.<br />
<br />
Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes. <br />
<br />
The current policy (version 1.2) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/<br />
<br />
The new policy (version 2.0) is here:<br />
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/<br />
<br />
A description of the changes to the policy is here:<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=609945#c3<br />
<br />
We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. After this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.<br />
<br />
I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== October 2010 ==<br />
<br />
Subject: Mozilla Communication to CAs regarding Policy updates, October 2010<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to five important points that we would like to bring to your attention.<br />
<br />
1) Mozilla has started a project to update the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/). The proposed changes may impact the operation of your root certificates that are included in NSS. Therefore, we request that all CAs participate in the discussions, which will be held in the Mozilla.dev.security.policy forum, http://www.mozilla.org/about/forums/#dev-security-policy. For information about the potential changes, please see https://wiki.mozilla.org/CA:CertPolicyUpdates.<br />
<br />
2) As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must provide an OCSP capability for end-entity certificates that are issued after Dec 31, 2010. Mozilla is considering technical ways to enforce this OCSP requirement such that if Firefox cannot obtain a valid response from the OCSP responder, then the certificate will not be given EV treatment. We are considering requiring the end-entity certificate to provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23<br />
Additionally, we urge all CAs to provide OCSP for all certs, even when they are not EV.<br />
<br />
3) We expect that all new certificates contain randomness (preferably in the serial number), especially when using the SHA-1 hash function or an RSA key size smaller than 2048 bits. For more information, please see http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period and serial number prediction”, and section 7, “Countermeasures.”<br />
<br />
4) As per the NIST guidelines, it is our expectation that all CAs are transitioning from issuing certs with RSA key sizes smaller than 2048 bits. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
5) We are planning to implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certs. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.<br />
<br />
We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.<br />
<br />
Regards,<br />
Kathleen Wilson,<br />
Module Owner of Mozilla's CA Certificates Module<br />
<br />
== May 2010 ==<br />
<br />
Subject: Mozilla Communication: Acceptable Addresses for Domain Control Validation<br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla, I am contacting you in regards to some changes that we are proposing to make to Mozilla’s CA Certificate Policy.<br />
<br />
Section 7 of the Mozilla CA Certificate Policy states: “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;”<br />
<br />
Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. Offering too many options for the email address prefix increases the risk of issuing a certificate to a subscriber who does not own/control the domain. Therefore, the list of email address prefixes should be limited.<br />
<br />
Mozilla is proposing to restrict the set of verification addresses that may be used for domain validation to the following list or a subset of it. Mozilla’s goal is to strike a balance between flexibility and safety.<br />
<br />
Accepted addresses for domain validation challenge-response email:<br />
* root@domain<br />
* admin@domain<br />
* administrator@domain<br />
* webmaster@domain<br />
* hostmaster@domain<br />
* Plus any address listed in the contact fields of the domain's WHOIS record.<br />
<br />
We hope that this restriction, when implemented consistently across CAs, will not cause discrimination or hardship. We are seeking feedback on whether this is the case. We invite you to contribute your feedback to a discussion about this new restriction in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.<br />
<br />
http://www.mozilla.org/community/developer-forums.html<br />
https://lists.mozilla.org/listinfo/dev-security-policy<br />
news://news.mozilla.org/mozilla.dev.security.policy<br />
<br />
The discussion thread is called “Domain Control validation” and “Acceptable Addresses for Domain Control Validation”.<br />
<br />
We have also added this information to our wiki page:<br />
https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs<br />
<br />
We look forward to your contributions to this discussion.<br />
<br />
Regards,<br />
Kathleen Wilson<br />
<br />
== November 2009 ==<br />
<br />
Subject: Mozilla Communication: SSL certificates issued to internal domain names <br />
<br />
Dear Certification Authority,<br />
<br />
On behalf of Mozilla I am contacting you in regards to root certificates that you currently have included by default in Mozilla products, such as the Firefox browser. <br />
<br />
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. <br />
<br />
Section 7 of Mozilla’s CA Certificate Policy states that CAs need to take “reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate.” There are different interpretations as to what this means in regards to internal domain names such as non-valid TLDs, hostnames, and IP addresses. However, there is consensus that there are problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks. Mozilla is currently discussing whether the CA Certificate Policy should be updated to add more explicit requirements on this practice, or even to disallow it altogether.<br />
<br />
In the light of the current situation, Mozilla requests that you take the following actions.<br />
<br />
1) Perform an internal audit to look for certificates that have been issued within your CA hierarchy which have .int domain names in the Common Name and/or as DNS Names in the subjectAlternativeName. For each of these certificates, check to see if the certificate subscriber owns/controls that domain name, and revoke the certificate if they do not own/control that domain name.<br />
<br />
2) Review your controls/procedures (both internally and your RAs) for correct identification of internal and external domain names and verification that subscribers own/control the domain name to be included in their certificate. Please refer to these documents:<br />
a) Section 7 of Mozilla’s CA Certificate Policy<br />
(http://www.mozilla.org/projects/security/certs/policy/)<br />
b) https://wiki.mozilla.org/CA:Recommended_Practices<br />
c) https://wiki.mozilla.org/CA:Problematic_Practices<br />
<br />
Mozilla also recommends that you <br />
1) Update your training procedures to ensure that all validation staff are aware of this situation. <br />
2) Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates.<br />
3) Maintain your own list of ICANN approved TLDs that are eligible to be used for domains in certificates issued within your CA hierarchy. If a new TLD is created by IANA, make an explicit decision whether or not to add the new TLD to your list.<br />
http://www.icann.org/en/registries/top-level-domains.htm<br />
<br />
Mozilla strongly encourages you to take prompt action in order to ensure the continued security and trust-ability of your CA service. <br />
<br />
Kathleen Wilson</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Removed_Certificates&diff=1246548CA/Removed Certificates2023-05-22T23:48:37Z<p>Kathleen Wilson: Changed ccadb-public.secure.force.com to ccadb.my.salesforce-sites.com</p>
<hr />
<div>= Mozilla Removed CA Certificate List =<br />
<br />
The Mozilla CA Certificate Program's list of included root certificates is stored in a file called [https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt certdata.txt] in the Mozilla source code management system. <br />
<br />
On occasion, we remove certificates from our Root Store; such certificates are listed below. Note that these data sources list only those cert removals that have happened since September 2014, which is when we began using the CCADB to maintain the root store data.<br />
<br /><br />
<big>[https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms CCADB Data Usage Terms]</big><br />
* [https://ccadb.my.salesforce-sites.com/mozilla/RemovedCACertificateReport Removed CA Certificates] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/RemovedCACertificateReportCSVFormat Removed CA Certificates] (CSV)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/RemovedCACertificateReportPEMCSV Removed CA Certificates] (CSV with PEM of raw certificate data)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/UpcomingRootRemovalsReport Upcoming CA Certificate Removals] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/UpcomingRootRemovalsReportCSVFormat Upcoming CA Certificate Removals] (CSV)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/UpcomingRootRemovalsReportPEMCSV Upcoming CA Certificate Removals] (CSV with PEM of raw certificate data)</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Intermediate_Certificates&diff=1246547CA/Intermediate Certificates2023-05-22T23:47:05Z<p>Kathleen Wilson: Changed ccadb-public.secure.force.com to ccadb.my.salesforce-sites.com</p>
<hr />
<div>= Intermediate Certificates =<br />
<br />
[[CA/Included_Certificates|CAs]] are required to provide the data for all of their [[CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F|publicly disclosed and audited intermediate certificates]] which chain up to root certificates in Mozilla's program. They do this using the [[CA:SalesforceCommunity|CCADB]]. <br />
<br />
The following reports are '''generated once per day''' and include valid intermediate certificates and expired intermediate certificates but not revoked intermediate certificates:<br />
<br /><br />
<big>[https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms CCADB Data Usage Terms]</big><br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PublicAllIntermediateCerts Intermediate CA Certificates] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PublicAllIntermediateCertsCSV Intermediate CA Certificates] (CSV)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PublicAllIntermediateCertsWithPEMCSV Intermediate CA Certificates] (CSV with PEM of raw certificate data)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/MozillaIntermediateCertsCSVReport Non-revoked, non-expired Intermediate CA Certificates chaining up to roots in Mozilla's program with the Websites trust bit set] (CSV with PEM of raw certificate data)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/IntermediateCertsSeparateAudits Intermediate CA Certificates with their own audit statements] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/IntermediateCertsSeparateAuditsCSV Intermediate CA Certificates with their own audit statements] (CSV)<br />
<br />
The following reports list revoked intermediate certificates:<br />
<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PublicIntermediateCertsRevoked Revoked Intermediate CA Certificates] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PublicIntermediateCertsRevokedCSVFormat Revoked Intermediate CA Certificates] (CSV)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PublicIntermediateCertsRevokedWithPEMCSV Revoked Intermediate CA Certificates] (CSV with PEM of raw certificate data)<br />
<br />
The following reports list the intermediate certificates that are ready to be added to OneCRL. Some non-revoked intermediate certificates are added to OneCRL because they are not intended to be used for SSL/TLS.<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PublicInterCertsReadyToAddToOneCRL Intermediate CA Certificates Ready to Add to OneCRL] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/PublicInterCertsReadyToAddToOneCRLPEMCSV Intermediate CA Certificates Ready to Add to OneCRL] (CSV with PEM of raw certificate data)<br />
<br />
The following reports list the intermediate certificates that have been added to OneCRL, and their revocation status as indicated by the CA in the CCADB.<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/IntermediateCertsInOneCRLReport Intermediate CA Certificates in OneCRL] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/IntermediateCertsInOneCRLReportCSV Intermediate CA Certificates in OneCRL] (CSV)<br />
<br />
Firefox (version 37 and later) uses the [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL] system, which pushes a list of revoked certificates to the browser. It includes (or should include) all the intermediate certificates in the above report.<br />
<br />
* [https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records OneCRL Raw Data]<br />
* [https://crt.sh/mozilla-onecrl OneCRL data table with links to each certificate in crt.sh]</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Included_Certificates&diff=1246546CA/Included Certificates2023-05-22T23:44:24Z<p>Kathleen Wilson: Change ccadb-public.secure.force.com to ccadb.my.salesforce-sites.com</p>
<hr />
<div>= Mozilla Included CA Certificate List =<br />
<br />
The Mozilla CA Certificate Program's list of included root certificates is stored in a file called [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/nss/lib/ckfw/builtins/certdata.txt certdata.txt] in the Mozilla source code management system.<br />
<br />
If you are '''choosing a CA to provide a certificate for your website''', we have a list of [https://ccadb.my.salesforce-sites.com/mozilla/CACertificatesInFirefoxReport all root certificates that Firefox trusts for SSL/TLS], together with contact information and geographical focus for the owning CA.<br />
<br />
If you are '''embedding our root store''', you need to know that we have imposed some restrictions on certain CAs or certificates which are not encoded in certdata.txt. These are [[CA/Additional_Trust_Changes|documented]] on a best-efforts basis.<br />
<br /><br /><br />
<big>[https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms CCADB Data Usage Terms]</big><br />
* [[CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F|Can I use Mozilla's set of CA certificates?]]<br />
** [https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Websites PEM of Root Certificates in Mozilla's Root Store with the Websites (TLS/SSL) Trust Bit Enabled] (TXT)<br />
** [https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Websites PEM of Root Certificates in Mozilla's Root Store with the Websites (TLS/SSL) Trust Bit Enabled] (CSV)<br />
** [https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email PEM of Root Certificates in Mozilla's Root Store with the Email (S/MIME) Trust Bit Enabled] (TXT)<br />
** [https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Email PEM of Root Certificates in Mozilla's Root Store with the Email (S/MIME) Trust Bit Enabled] (CSV)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/IncludedCACertificateReport Included CA Certificates] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/IncludedCACertificateReportCSVFormat Included CA Certificates] (CSV)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/IncludedCACertificateReportPEMCSV Included CA Certificates] (CSV with PEM of raw certificate data)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/UpcomingRootInclusionsReport Root Inclusions in Progress] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/UpcomingRootInclusionsReportCSVFormat Root Inclusions in Progress] (CSV)</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Included_CAs&diff=1246545CA/Included CAs2023-05-22T23:42:32Z<p>Kathleen Wilson: Change ccadb-public.secure.force.com to ccadb.my.salesforce-sites.com</p>
<hr />
<div>= Mozilla Included CA List =<br />
<br />
These reports list all the CAs who have certificates in Mozilla's root program, together with useful information about them such as their CAA identifiers and the mechanism by which you can report a problem with that CA's certificates.<br />
<br /><br />
<big>[https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms CCADB Data Usage Terms]</big><br />
* [https://ccadb.my.salesforce-sites.com/mozilla/CAInformationReport Participating CAs] (HTML)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/CAInformationReportCSVFormat Participating CAs] (CSV)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/ProblemReportingMechanismsReport Problem Reporting Mechanisms]<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/CAAIdentifiersReport CAA Identifiers]</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/CCADB_Dashboard&diff=1246386CA/CCADB Dashboard2023-05-03T23:36:51Z<p>Kathleen Wilson: cleaned up the ordering</p>
<hr />
<div>= Dashboard for Common CA Database Updates =<br />
<br />
== CCADB API Access==<br />
Requests for API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert<br />
<br />
To file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB API Access Request], use:<br />
<br /><br />
Product: CA Program <br />
<br /><br />
Component: Common CA Database <br />
<br /><br />
Whiteboard: [ccadb-api] <br />
<br /><br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"status_whiteboard":"ccadb-api",<br />
"include_fields": "whiteboard, id, summary, last_change_time",<br />
"order": "id"<br />
}<br />
</bugzilla><br />
<br />
== Bugs ==<br />
Bugs that unintentionally remove pre-existing functionality or negatively impact CCADB users should have priority over Enhancements, and should be set to P1. Low impact bugs will start at P4 and be considered with ERs. If it's a low LOE bug (less than 4 hours of work) it can go from P4 to P1 without prioritization/design.<br />
<br />
To file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB Bug], use:<br />
<br /><br />
Product: CA Program <br />
<br /><br />
Component: Common CA Database <br />
<br /><br />
Whiteboard: [ccadb-bug] <br />
<br /><br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"whiteboard":"ccadb-bug",<br />
"include_fields": "priority, id, summary, last_change_time",<br />
"order": "priority ASC"<br />
}<br />
</bugzilla><br />
<br />
== Enhancement Requests ==<br />
The Priority values are used as follows:<br />
* P1 - Development in progress<br />
* P2 - Design complete<br />
* P3 - Prioritized<br />
* P4 or not set - To be prioritized and scheduled later<br />
<br />
'''Important''': Do not enter a value into the Whiteboard field to file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB Enhancement Request].<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "nowordssubstr",<br />
"v2": "ccadb",<br />
"include_fields": "priority, id, summary,last_change_time",<br />
"order": "priority ASC"<br />
}<br />
</bugzilla><br />
<br />
== Closed ==<br />
A historical view of past CCADB updates (from May 2021 onward) may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_CCADB_Updates</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/CCADB_Dashboard&diff=1246385CA/CCADB Dashboard2023-05-03T22:06:04Z<p>Kathleen Wilson: added instructions for filing these bugs</p>
<hr />
<div>= Dashboard for Common CA Database Updates =<br />
<br />
== CCADB API Access==<br />
Requests for API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert<br />
<br />
To file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB API Access Request], use:<br />
<br /><br />
Product: CA Program <br />
<br /><br />
Component: Common CA Database <br />
<br /><br />
Whiteboard: [ccadb-api] <br />
<br /><br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"status_whiteboard":"ccadb-api",<br />
"include_fields": "whiteboard, id, summary, last_change_time",<br />
"order": "status_whiteboard ASC, assigned_to DESC"<br />
}<br />
</bugzilla><br />
<br />
== Bugs ==<br />
Bugs that unintentionally remove pre-existing functionality or negatively impact CCADB users should have priority over Enhancements, and should be set to P1. Low impact bugs will start at P4 and be considered with ERs. If it's a low LOE bug (less than 4 hours of work) it can go from P4 to P1 without prioritization/design.<br />
<br />
To file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB Bug], use:<br />
<br /><br />
Product: CA Program <br />
<br /><br />
Component: Common CA Database <br />
<br /><br />
Whiteboard: [ccadb-bug] <br />
<br /><br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"whiteboard":"ccadb-bug",<br />
"include_fields": "priority, id, summary, last_change_time",<br />
"order": "priority ASC, assigned_to DESC"<br />
}<br />
</bugzilla><br />
<br />
== Enhancement Requests ==<br />
The Priority values are used as follows:<br />
* P1 - Development in progress<br />
* P2 - Design complete<br />
* P3 - Prioritized<br />
* P4 or not set - To be prioritized and scheduled later<br />
<br />
'''Important''': Do not enter a value into the Whiteboard field to file a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=Common+CA+Database CCADB Enhancement Request].<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "nowordssubstr",<br />
"v2": "ccadb",<br />
"include_fields": "priority, id, summary,last_change_time",<br />
"order": "priority ASC, assigned_to DESC"<br />
}<br />
</bugzilla><br />
<br />
== Closed ==<br />
A historical view of past CCADB updates (from May 2021 onward) may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_CCADB_Updates</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Bug_Triage&diff=1246384CA/Bug Triage2023-05-03T21:51:57Z<p>Kathleen Wilson: filter out resolved bugs</p>
<hr />
<div>= CA Program Bugzilla Dashboards = <br />
* CA Inclusion/Update Requests: https://wiki.mozilla.org/CA/Dashboard<br />
* CA Compliance Bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
* Common CA Database (CCADB) Bugs: https://wiki.mozilla.org/CA/CCADB_Dashboard<br />
<br />
= Bug Triage in Mozilla's CA Certificate Program =<br />
Mozilla’s [[CA:Overview|CA Certificate Program]] governs inclusion of root certificates in [https://developer.mozilla.org/en-US/docs/NSS Network Security Services (NSS),] a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The [[CA:IncludedCAs|NSS root certificate store]] is not only used in Mozilla products such as the [https://www.mozilla.org/firefox/ Firefox] browser, but is also used by other companies in a variety of products.<br />
<br /><br /><br />
The [https://bugzilla.mozilla.org/ Bugzilla] products/components related to the CA Certificate Program are:<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Compliance&product=CA%20Program CA Program :: CA Certificate Compliance] - Problems found in certificates issued by Certificate Authorities included in the default certificate store.<br />
** Concerns that are raised about certificates being issued by CAs, and the resulting action items for the CAs.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program CA Program :: CA Certificate Root Program] - For Certificate Authorities to file requests asking for their certificates to be included in the default certificate store.<br />
** [[CA|Root inclusion/change requests]]. When approved, the actual code changes are requested via a new Bugzilla Bug in [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificates%20Code&product=NSS NSS :: CA Certificates Code].<br />
** [[CA:How_to_apply#Enable_EV_for_an_included_root|EV treatment enablement requests]]. When approved, the actual code changes are requested via a new [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=Security%3A%20PSM&product=Core Bugzilla Bug for PSM].<br />
** CA Program-related concerns or action items.<br />
** Requests to [https://www.ccadb.org/cas/intermediates#marking-an-intermediate-certificate-as-revoked add certs to OneCRL]. <br />
* [https://bugzilla.mozilla.org/buglist.cgi?&query_format=advanced&component=CA%20Documents&product=CA%20Program CA Program :: CA Documents] - For CA audit statements, when they are not on the auditor's website.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=Common%20CA%20Database&product=CA%20Program CA Program :: Common CA Database] - For requesting updates to the [https://www.ccadb.org/ Common CA Database (CCADB)].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificates%20Code&product=NSS NSS :: CA Certificates Code] - For actual code changes to NSS. Kathleen should be the only person filing these bugs on behalf of the CA Program.<br />
<br />
The CA Certificate Program deviates from Mozilla's standardized [[Bugmasters/Process/Triage|Bugzilla Bug Triage]] process for bug priorities (P1, P2, P3, P4, P5). Priorities are not used for CA compliance bugs because they do not directly include code changes to Mozilla's [[RapidRelease/Calendar|release trains]] or iterations. Priorities are used, however, for tracking CCADB enhancements and for prioritizing [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program root inclusion requests]. See https://wiki.mozilla.org/CA/Prioritization.<br />
<br />
= Compliance Problems and Incidents =<br />
To report a concern about certificates being issued by a CA in Mozilla's Program, or their audit statements:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance <br />
If the bug concerns CA certificate issuance, then the bug summary should begin with the CA name (followed by a colon and then a space), so that sorting the bugs by Summary will sort the bugs by CA. <br />
<br /><br /><br />
Open CA Compliance bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
<br /><br /><br />
If the bug concerns audit statements not containing expected information, then the bug summary should begin with auditor's name, so that sorting the bugs by Summary will sort the bugs by auditor name.<br />
<br /><br /><br />
Open Auditor Compliance bugs: https://wiki.mozilla.org/CA/Auditor_Compliance<br />
<br /><br /><br />
The whiteboard tags for [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&component=CA%20Certificate%20Compliance CA Program :: CA Certificate Compliance] include:<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-compliance &#91;ca-compliance&#93;] -- For concerns about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and it is not considered to be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=auditor-compliance &#91;auditor-compliance&#93;] -- For concerns about an auditor failing to properly detect and report on CA compliance issues that occurred during one or more periods when the CA was audited.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-revocation-delay &#91;ca-revocation-delay&#93;] or [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=leaf-revocation-delay &#91;leaf-revocation-delay&#93;] -- appended after [ca-compliance] whenever a CA fails to abide by the Baseline Requirements' requirement to revoke certificates in a timely fashion.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=audit-delay &#91;audit-delay&#93;] -- appended after [ca-compliance] when a CA is unable to provide audit statements within one year and 3 months of the previous audit period end date.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=covid-19 &#91;covid-19&#93;] -- appended after [ca-compliance], [audit-delay], or [ca-revocation-delay] when delays are due to mandated restrictions regarding COVID-19.<br />
<br />
New Whiteboard Tags appended to [ca-compliance] include the following:<br />
<br />
* [ca-misissuance] mis-issuance of a CA certificate<br />
* [dv-misissuance] mis-issuance of a DV certificate<br />
* [ov-misissuance] mis-issuance of an OV end-entity certificate<br />
* [ev-misissuance] mis-issuance of an EV end-entity certificate<br />
* [crl-failure] failure to provide certificate status via CRL; malformed, expired CRL<br />
* [ocsp-failure] failure to provide certificate status via OCSP; malformed, expired OCSP<br />
* [policy-failure] failure to update CP/CPS annually, failure to comply with practice in CP/CPS, misunderstanding requirements, failed implementation<br />
* [disclosure-failure] failure to disclose an ICA, failure to report revocation of an ICA, non-disclosure-of-EV-sources, miscommunication, poor communication, etc.<br />
* [audit-failure] failure to perform an audit, failure to upload audits, etc.<br />
<br />
= Root Inclusion/Change requests and EV Treatment Enablement Requests=<br />
A representative of a CA may begin the process of root inclusion, change, or ev-enablement by filing a Bugzilla Bug as described here: <br />
* https://wiki.mozilla.org/CA/Application_Process<br />
Root Inclusion Requests are prioritized as described here:<br />
* https://wiki.mozilla.org/CA/Prioritization<br />
The whiteboard tags for [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program CA Program :: CA Certificate Root Program] are:<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-initial &#91;ca-initial&#93;] -- not enough information to begin the Information Verification phase, or not yet assigned to someone to do the Information Verification<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-verifying &#91;ca-verifying&#93;] -- in [[CA/Application_Verification#Information_Verification|Information Verification]] phase. This is a high-level review to ensure that all [[CA/Information_Checklist|required data]] has been provided in Bugzilla and the CCADB and that the appropriate tests have been run.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-ready-for-discussion &#91;ca-ready-for-discussion yyyy-mm-dd&#93;] -- Information Verification phase is complete. Ready for [[CA/Application_Verification#Public_discussion|public discussion]] and detailed CP/CPS review. <br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-in-discussion &#91;ca-in-discussion&#93;] -- in discussion in the [https://groups.google.com/a/ccadb.org/g/public CCADB public mailing list].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-cps-review &#91;ca-cps-review&#93;] -- [[CA/Application_Verification#Detailed_Review|Detailed Review]], which requires that the relevant CP/CPS and audit documents be [[CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21|thoroughly reviewed]]. As a result of such review(s), the CA may be required to update their CP/CPS to become fully aligned with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-discussion-hold &#91;ca-discussion-hold&#93;] -- discussion on hold, pending CA actions.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-hold &#91;ca-hold&#93;] -- CA's request is on hold, typically because the CA is a super-CA, so all of their subCAs have to achieve inclusion first.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-pending-approval &#91;ca-pending-approval&#93;] -- final notice of intent to approve the CA's request<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-approved &#91;ca-approved&#93;] -- request is approved, pending code changes in NSS, also including certs which are in NSS and pending code changes in PSM<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=CA%20Program&component=CA%20Certificate%20Root%20Program&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=SUPPORT&resolution=EXPIRED&resolution=MOVED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-denied&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1= &#91;ca-denied&#93;] -- request was denied. Under normal circumstances the CA may submit a new root inclusion request for a new root certificate that fully complies with Mozilla's Root Store policy.<br />
<br />
= CA Audit Statement Bugs =<br />
* [https://bugzilla.mozilla.org/buglist.cgi?&query_format=advanced&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-audit &#91;ca-audits&#93;] -- One bug may be created per CA to store audit statements or CP/CPS documents. <br />
** [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Documents Link to create ca-audit bug]<br />
** Make sure the bug has the correct product/component for the CA Certificate Program, which is [https://bugzilla.mozilla.org/buglist.cgi?&query_format=advanced&component=CA%20Documents&product=CA%20Program CA Program :: CA Documents]<br />
** Add [ca-audits] to the Whiteboard<br />
<br />
=CA Program Process or Policy Related Bugs=<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-program &#91;ca-program&#93;] -- bugs related to CA Program process, wiki pages, or policy. Note that most [https://github.com/mozilla/pkipolicy/issues CA Program Policy issues] are tracked on Github.<br />
<br />
=Certificate Revocation Related Bugs=<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-onecrl &#91;ca-onecrl&#93;] -- bugs related to updating entries in OneCRL. Under normal circumstances a Bugzilla Bug is not needed for this. Rather, the CA should [http://ccadb.org/cas/intermediates report the revocation via the Common CA Database].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?short_desc=CCADB%20entries%20generated&short_desc_type=allwordssubstr OneCRL Entries Generated] -- bugs for verifying OneCRL entries before they are pushed to production. These bugs are automatically generated from CCADB for standard revocations of intermediate certificates that are reported by CAs. Otherwise these bugs are generated by manually running the tools for specially requested additions to OneCRL.<br />
<br />
=Common CA Database (CCADB)=<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&status_whiteboard_type=allwordssubstr&status_whiteboard=ccadb-api &#91;ccadb-api&#93;] -- for requesting API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&resolution=---&query_format=advanced&status_whiteboard_type=allwordssubstr&status_whiteboard=ccadb-bug &#91;ccadb-bug&#93;] -- for issues or problems using the CCADB.<br />
* All [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&resolution=---&component=Common%20CA%20Database "CA Program : Common CA Database" Bugzilla Bugs] that do not have a whiteboard tag are considered to be enhancement requests that will be prioritized and schedule by the CCADB Steering Committee. <br />
<br />
The Priority field is used for CCADB Enhancement Requests and bugs as follows:<br />
* P1 - Development in progress<br />
* P2 - Design complete<br />
* P3 - Prioritized<br />
* P4 or not set - To be prioritized and scheduled later<br />
<br />
Bugs that unintentionally remove pre-existing functionality or negatively impact CCADB users should have priority over Enhancements, and should be set to P1. Low impact bugs will start at P4 and be considered with ERs. If it's a low LOE bug (less than 4 hours of work) it can go from P4 to P1 without prioritization/design.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Bug_Triage&diff=1246383CA/Bug Triage2023-05-03T21:49:47Z<p>Kathleen Wilson: Updated to the new way that CCADB SC uses Bugzilla Bugs to track enhancement requests.</p>
<hr />
<div>= CA Program Bugzilla Dashboards = <br />
* CA Inclusion/Update Requests: https://wiki.mozilla.org/CA/Dashboard<br />
* CA Compliance Bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
* Common CA Database (CCADB) Bugs: https://wiki.mozilla.org/CA/CCADB_Dashboard<br />
<br />
= Bug Triage in Mozilla's CA Certificate Program =<br />
Mozilla’s [[CA:Overview|CA Certificate Program]] governs inclusion of root certificates in [https://developer.mozilla.org/en-US/docs/NSS Network Security Services (NSS),] a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The [[CA:IncludedCAs|NSS root certificate store]] is not only used in Mozilla products such as the [https://www.mozilla.org/firefox/ Firefox] browser, but is also used by other companies in a variety of products.<br />
<br /><br /><br />
The [https://bugzilla.mozilla.org/ Bugzilla] products/components related to the CA Certificate Program are:<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Compliance&product=CA%20Program CA Program :: CA Certificate Compliance] - Problems found in certificates issued by Certificate Authorities included in the default certificate store.<br />
** Concerns that are raised about certificates being issued by CAs, and the resulting action items for the CAs.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program CA Program :: CA Certificate Root Program] - For Certificate Authorities to file requests asking for their certificates to be included in the default certificate store.<br />
** [[CA|Root inclusion/change requests]]. When approved, the actual code changes are requested via a new Bugzilla Bug in [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificates%20Code&product=NSS NSS :: CA Certificates Code].<br />
** [[CA:How_to_apply#Enable_EV_for_an_included_root|EV treatment enablement requests]]. When approved, the actual code changes are requested via a new [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=Security%3A%20PSM&product=Core Bugzilla Bug for PSM].<br />
** CA Program-related concerns or action items.<br />
** Requests to [https://www.ccadb.org/cas/intermediates#marking-an-intermediate-certificate-as-revoked add certs to OneCRL]. <br />
* [https://bugzilla.mozilla.org/buglist.cgi?&query_format=advanced&component=CA%20Documents&product=CA%20Program CA Program :: CA Documents] - For CA audit statements, when they are not on the auditor's website.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=Common%20CA%20Database&product=CA%20Program CA Program :: Common CA Database] - For requesting updates to the [https://www.ccadb.org/ Common CA Database (CCADB)].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificates%20Code&product=NSS NSS :: CA Certificates Code] - For actual code changes to NSS. Kathleen should be the only person filing these bugs on behalf of the CA Program.<br />
<br />
The CA Certificate Program deviates from Mozilla's standardized [[Bugmasters/Process/Triage|Bugzilla Bug Triage]] process for bug priorities (P1, P2, P3, P4, P5). Priorities are not used for CA compliance bugs because they do not directly include code changes to Mozilla's [[RapidRelease/Calendar|release trains]] or iterations. Priorities are used, however, for tracking CCADB enhancements and for prioritizing [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program root inclusion requests]. See https://wiki.mozilla.org/CA/Prioritization.<br />
<br />
= Compliance Problems and Incidents =<br />
To report a concern about certificates being issued by a CA in Mozilla's Program, or their audit statements:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance <br />
If the bug concerns CA certificate issuance, then the bug summary should begin with the CA name (followed by a colon and then a space), so that sorting the bugs by Summary will sort the bugs by CA. <br />
<br /><br /><br />
Open CA Compliance bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
<br /><br /><br />
If the bug concerns audit statements not containing expected information, then the bug summary should begin with auditor's name, so that sorting the bugs by Summary will sort the bugs by auditor name.<br />
<br /><br /><br />
Open Auditor Compliance bugs: https://wiki.mozilla.org/CA/Auditor_Compliance<br />
<br /><br /><br />
The whiteboard tags for [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&component=CA%20Certificate%20Compliance CA Program :: CA Certificate Compliance] include:<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-compliance &#91;ca-compliance&#93;] -- For concerns about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and it is not considered to be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=auditor-compliance &#91;auditor-compliance&#93;] -- For concerns about an auditor failing to properly detect and report on CA compliance issues that occurred during one or more periods when the CA was audited.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-revocation-delay &#91;ca-revocation-delay&#93;] or [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=leaf-revocation-delay &#91;leaf-revocation-delay&#93;] -- appended after [ca-compliance] whenever a CA fails to abide by the Baseline Requirements' requirement to revoke certificates in a timely fashion.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=audit-delay &#91;audit-delay&#93;] -- appended after [ca-compliance] when a CA is unable to provide audit statements within one year and 3 months of the previous audit period end date.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&component=CA%20Certificate%20Compliance&status_whiteboard_type=allwordssubstr&status_whiteboard=covid-19 &#91;covid-19&#93;] -- appended after [ca-compliance], [audit-delay], or [ca-revocation-delay] when delays are due to mandated restrictions regarding COVID-19.<br />
<br />
New Whiteboard Tags appended to [ca-compliance] include the following:<br />
<br />
* [ca-misissuance] mis-issuance of a CA certificate<br />
* [dv-misissuance] mis-issuance of a DV certificate<br />
* [ov-misissuance] mis-issuance of an OV end-entity certificate<br />
* [ev-misissuance] mis-issuance of an EV end-entity certificate<br />
* [crl-failure] failure to provide certificate status via CRL; malformed, expired CRL<br />
* [ocsp-failure] failure to provide certificate status via OCSP; malformed, expired OCSP<br />
* [policy-failure] failure to update CP/CPS annually, failure to comply with practice in CP/CPS, misunderstanding requirements, failed implementation<br />
* [disclosure-failure] failure to disclose an ICA, failure to report revocation of an ICA, non-disclosure-of-EV-sources, miscommunication, poor communication, etc.<br />
* [audit-failure] failure to perform an audit, failure to upload audits, etc.<br />
<br />
= Root Inclusion/Change requests and EV Treatment Enablement Requests=<br />
A representative of a CA may begin the process of root inclusion, change, or ev-enablement by filing a Bugzilla Bug as described here: <br />
* https://wiki.mozilla.org/CA/Application_Process<br />
Root Inclusion Requests are prioritized as described here:<br />
* https://wiki.mozilla.org/CA/Prioritization<br />
The whiteboard tags for [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program CA Program :: CA Certificate Root Program] are:<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-initial &#91;ca-initial&#93;] -- not enough information to begin the Information Verification phase, or not yet assigned to someone to do the Information Verification<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-verifying &#91;ca-verifying&#93;] -- in [[CA/Application_Verification#Information_Verification|Information Verification]] phase. This is a high-level review to ensure that all [[CA/Information_Checklist|required data]] has been provided in Bugzilla and the CCADB and that the appropriate tests have been run.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-ready-for-discussion &#91;ca-ready-for-discussion yyyy-mm-dd&#93;] -- Information Verification phase is complete. Ready for [[CA/Application_Verification#Public_discussion|public discussion]] and detailed CP/CPS review. <br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-in-discussion &#91;ca-in-discussion&#93;] -- in discussion in the [https://groups.google.com/a/ccadb.org/g/public CCADB public mailing list].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-cps-review &#91;ca-cps-review&#93;] -- [[CA/Application_Verification#Detailed_Review|Detailed Review]], which requires that the relevant CP/CPS and audit documents be [[CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21|thoroughly reviewed]]. As a result of such review(s), the CA may be required to update their CP/CPS to become fully aligned with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-discussion-hold &#91;ca-discussion-hold&#93;] -- discussion on hold, pending CA actions.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-hold &#91;ca-hold&#93;] -- CA's request is on hold, typically because the CA is a super-CA, so all of their subCAs have to achieve inclusion first.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-pending-approval &#91;ca-pending-approval&#93;] -- final notice of intent to approve the CA's request<br />
* [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&query_format=advanced&component=CA%20Certificate%20Root%20Program&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-approved &#91;ca-approved&#93;] -- request is approved, pending code changes in NSS, also including certs which are in NSS and pending code changes in PSM<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=CA%20Program&component=CA%20Certificate%20Root%20Program&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=SUPPORT&resolution=EXPIRED&resolution=MOVED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-denied&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1= &#91;ca-denied&#93;] -- request was denied. Under normal circumstances the CA may submit a new root inclusion request for a new root certificate that fully complies with Mozilla's Root Store policy.<br />
<br />
= CA Audit Statement Bugs =<br />
* [https://bugzilla.mozilla.org/buglist.cgi?&query_format=advanced&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-audit &#91;ca-audits&#93;] -- One bug may be created per CA to store audit statements or CP/CPS documents. <br />
** [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Documents Link to create ca-audit bug]<br />
** Make sure the bug has the correct product/component for the CA Certificate Program, which is [https://bugzilla.mozilla.org/buglist.cgi?&query_format=advanced&component=CA%20Documents&product=CA%20Program CA Program :: CA Documents]<br />
** Add [ca-audits] to the Whiteboard<br />
<br />
=CA Program Process or Policy Related Bugs=<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&product=CA%20Program&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-program &#91;ca-program&#93;] -- bugs related to CA Program process, wiki pages, or policy. Note that most [https://github.com/mozilla/pkipolicy/issues CA Program Policy issues] are tracked on Github.<br />
<br />
=Certificate Revocation Related Bugs=<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&status_whiteboard_type=allwordssubstr&status_whiteboard=ca-onecrl &#91;ca-onecrl&#93;] -- bugs related to updating entries in OneCRL. Under normal circumstances a Bugzilla Bug is not needed for this. Rather, the CA should [http://ccadb.org/cas/intermediates report the revocation via the Common CA Database].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?short_desc=CCADB%20entries%20generated&short_desc_type=allwordssubstr OneCRL Entries Generated] -- bugs for verifying OneCRL entries before they are pushed to production. These bugs are automatically generated from CCADB for standard revocations of intermediate certificates that are reported by CAs. Otherwise these bugs are generated by manually running the tools for specially requested additions to OneCRL.<br />
<br />
=Common CA Database (CCADB)=<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&status_whiteboard_type=allwordssubstr&status_whiteboard=ccadb-api &#91;ccadb-api&#93;] -- for requesting API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&query_format=advanced&status_whiteboard_type=allwordssubstr&status_whiteboard=ccadb-bug &#91;ccadb-bug&#93;] -- for issues or problems using the CCADB.<br />
* All [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&resolution=---&component=Common%20CA%20Database "CA Program : Common CA Database" Bugzilla Bugs] that do not have a whiteboard tag are considered to be enhancement requests that will be prioritized and schedule by the CCADB Steering Committee. <br />
<br />
The Priority field is used for CCADB Enhancement Requests and bugs as follows:<br />
* P1 - Development in progress<br />
* P2 - Design complete<br />
* P3 - Prioritized<br />
* P4 or not set - To be prioritized and scheduled later<br />
<br />
Bugs that unintentionally remove pre-existing functionality or negatively impact CCADB users should have priority over Enhancements, and should be set to P1. Low impact bugs will start at P4 and be considered with ERs. If it's a low LOE bug (less than 4 hours of work) it can go from P4 to P1 without prioritization/design.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Closed_CCADB_Updates&diff=1246382CA/Closed CCADB Updates2023-05-03T21:26:08Z<p>Kathleen Wilson: Updated to the new way that CCADB SC uses Bugzilla Bugs to track enhancement requests.</p>
<hr />
<div>= Closed Common CA Database Updates =<br />
<br />
The 'NSS :: Common CA Database' Bugzilla component was created in May, 2021.<br />
<br />
== CCADB API Access ==<br />
Requests for API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert <br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"status": ["CLOSED", "RESOLVED", "VERIFIED"],<br />
"whiteboard":"ccadb-api",<br />
"include_fields": "id, summary, resolution, last_change_time",<br />
"order": "last_change_time DESC"<br />
}<br />
</bugzilla><br />
<br />
== Bugs ==<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"status": ["CLOSED", "RESOLVED", "VERIFIED"],<br />
"whiteboard":"ccadb-bug",<br />
"include_fields": "id, summary, resolution, last_change_time",<br />
"order": "last_change_time DESC"<br />
}<br />
</bugzilla><br />
<br />
== Enhancement Requests ==<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"status": ["CLOSED", "RESOLVED", "VERIFIED"],<br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "nowordssubstr",<br />
"v2": "ccadb",<br />
"include_fields": "id, summary, resolution, last_change_time",<br />
"order": "last_change_time DESC"<br />
}<br />
</bugzilla></div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/CCADB_Dashboard&diff=1246381CA/CCADB Dashboard2023-05-03T21:21:35Z<p>Kathleen Wilson: re-added sort by priority to the enhancement requests table</p>
<hr />
<div>= Dashboard for Common CA Database Updates =<br />
<br />
== CCADB API Access==<br />
Requests for API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"status_whiteboard":"ccadb-api",<br />
"include_fields": "whiteboard, id, summary, last_change_time",<br />
"order": "status_whiteboard ASC, assigned_to DESC"<br />
}<br />
</bugzilla><br />
<br />
== Bugs ==<br />
Bugs that unintentionally remove pre-existing functionality or negatively impact CCADB users should have priority over Enhancements, and should be set to P1. Low impact bugs will start at P4 and be considered with ERs. If it's a low LOE bug (less than 4 hours of work) it can go from P4 to P1 without prioritization/design.<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"whiteboard":"ccadb-bug",<br />
"include_fields": "priority, id, summary, last_change_time",<br />
"order": "priority ASC, assigned_to DESC"<br />
}<br />
</bugzilla><br />
<br />
== Enhancement Requests ==<br />
The Priority values are used as follows:<br />
* P1 - Development in progress<br />
* P2 - Design complete<br />
* P3 - Prioritized<br />
* P4 or not set - To be prioritized and scheduled later<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "nowordssubstr",<br />
"v2": "ccadb",<br />
"include_fields": "priority, id, summary,last_change_time",<br />
"order": "priority ASC, assigned_to DESC"<br />
}<br />
</bugzilla><br />
<br />
== Closed ==<br />
A historical view of past CCADB updates (from May 2021 onward) may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_CCADB_Updates</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/CCADB_Dashboard&diff=1246380CA/CCADB Dashboard2023-05-03T21:12:31Z<p>Kathleen Wilson: Updated to the new way that CCADB SC uses Bugzilla Bugs to track enhancement requests.</p>
<hr />
<div>= Dashboard for Common CA Database Updates =<br />
<br />
== CCADB API Access==<br />
Requests for API access to the CCADB as per https://github.com/mozilla/CCADB-Tools/tree/master/API_AddUpdateIntermediateCert<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"status_whiteboard":"ccadb-api",<br />
"include_fields": "whiteboard, id, summary, last_change_time",<br />
"order": "status_whiteboard ASC, assigned_to DESC"<br />
}<br />
</bugzilla><br />
<br />
== Bugs ==<br />
Bugs that unintentionally remove pre-existing functionality or negatively impact CCADB users should have priority over Enhancements, and should be set to P1. Low impact bugs will start at P4 and be considered with ERs. If it's a low LOE bug (less than 4 hours of work) it can go from P4 to P1 without prioritization/design.<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"whiteboard":"ccadb-bug",<br />
"include_fields": "priority, id, summary, last_change_time",<br />
"order": "priority ASC, assigned_to DESC"<br />
}<br />
</bugzilla><br />
<br />
== Enhancement Requests ==<br />
The Priority values are used as follows:<br />
* P1 - Development in progress<br />
* P2 - Design complete<br />
* P3 - Prioritized<br />
* P4 or not set - To be prioritized and scheduled later<br />
<br />
<bugzilla><br />
{<br />
"component":"Common CA Database",<br />
"resolution": "---",<br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "nowordssubstr",<br />
"v2": "ccadb",<br />
"include_fields": "priority, id, summary,last_change_time"<br />
}<br />
</bugzilla><br />
<br />
== Closed ==<br />
A historical view of past CCADB updates (from May 2021 onward) may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_CCADB_Updates</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Audit_Statements&diff=1246290CA/Audit Statements2023-04-25T18:36:18Z<p>Kathleen Wilson: clean up</p>
<hr />
<div>= Audit Letter Content =<br />
CA Audits are one of the primary mechanisms relied upon by Mozilla to ensure that a CA is operating securely and in compliance with our policies. CA audits and audit statements must comply with the following requirements.<br />
* Section 3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy]<br />
* [https://www.ccadb.org/policy#51-audit-statement-content Section 5.1 of the Common CCADB Policy].<br />
* Section 8 of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements], if the root certificate has the Websites (TLS/SSL) trust bit enabled.<br />
<br />
Format Requirements:<br />
* SHA-256 Fingerprints<br />
** MUST: No colons, no spaces, and no line feeds<br />
** MUST: Uppercase letters<br />
** MUST: be encoded in the document (PDF) as text searchable, not an image<br />
* Dates<br />
** Month DD, YYYY example: May 7, 2016<br />
** DD Month YYYY example: 7 May 2016<br />
** YYYY-MM-DD example: 2016-05-07<br />
** Month names in English<br />
** No extra text within the date, such as “7th” or “the”<br />
<br />
== Audited Locations ==<br />
Both ETSI and WebTrust Audits should:<br />
* Disclose each location (at the state/province level) that was included in the scope of the audit or should have been included in the scope of the audit, whether the inspection was physically carried out in person at each location, and which audit criteria were checked (or not checked) at each location.<br />
** If the CA has more than one location in the same state/province, then use terminology to clarify the number of facilities in that state/province and whether or not all of them were audited. For example: "Facility 1 in Province", "Facility 2 in Province, Facility 3 in Province" '''or''' "Primary Facility in Province", "Secondary Facility in Province", "Tertiary Facility in Province". <br />
*** The public audit statement does not need to identify the type of Facility.<br />
*** "Facility" includes: data center locations, registration authority locations, where IT and business process controls of CA operations are performed, facility hosting an active HSM with CA private keys, facility or bank deposit box storing a deactivated and encrypted copy of a private key.<br />
<br />
= Audit Lifecycle =<br />
Mozilla's Root Store Policy states the following requirements which apply to root certificates and all intermediate certificates that have at least one valid, unrevoked chain up to an included root certificate and which are technically capable of issuing working server or email certificates as described in section 1.1 of Mozilla's [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] . <br />
* Before being included and periodically thereafter, CAs MUST obtain certain audits for their root certificates and all of their intermediate certificates that are technically capable of issuing working server or email certificates. <br />
* Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA certificate is no longer trusted by Mozilla's root store. <br />
** A CA certificate is considered to be trusted by Mozilla's root store as long as it is not expired, not in OneCRL, and either is directly included in Mozilla's root store or chains up (via subject/issuer) to another certificate that is included in Mozilla's root store. <br />
*** A CA certificate that has the Websites trust bit enabled is considered to be trusted by Mozilla's root store as long as Firefox continues to treat is as either a trusted root certificate or a trusted intermediate certificate. Reference: [[SecurityEngineering/Certificate_Verification|How Firefox Performs Certificate Verification and path construction]] <br />
** Note: If a CA stops providing audit statements for a root certificate for any reason, then the certificate may be added to OneCRL in addition to being removed from Mozilla's root store.<br />
* Successive audits MUST be contiguous (no gaps).<br />
* Audit reports which are being supplied to maintain a certificate within the Mozilla root program MUST be provided to Mozilla via the CCADB within three months of the end date of the period.<br />
* For Intermediate Certificates only: If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports.<br />
<br />
Other Audits:<br />
* Point-in-Time Audits: Point-in-time audit statements may be used to confirm that all of the problems that an auditor previously identified in a qualified audit statement have been corrected. However, a point-in-time audit does not replace the period-of-time audit.<br />
* Readiness Assessment: The [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] state: If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in Section 8.1, then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 8.1. The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate.<br />
<br />
= Audit Letter Validation =<br />
The contents of this section and its sub-sections have been moved to https://www.ccadb.org/cas/alv.<br />
== Root Certificates ==<br />
This section has been moved to https://www.ccadb.org/cas/alv#root-certificates<br />
== Intermediate Certificates ==<br />
This section has been moved to https://www.ccadb.org/cas/alv#intermediate-certificates<br />
== Common ALV Findings ==<br />
This section has been moved to https://www.ccadb.org/cas/alv#common-alv-findings<br />
<br />
= Audit Delay =<br />
An Audit Delay is when one or more of the following requirements in section 3.1.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] cannot be met:<br />
* "Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually."<br />
* "... MUST be provided to Mozilla via the CCADB within three months of the point-in-time date or the end date of the period."<br />
<br />
If a CA fails to deliver audit statements to Mozilla when they are due, Mozilla may take action to reduce the risks this presents to our users. The following guidance is intended for CAs in such a situation.<br />
<br /><br /><br />
When a CA realizes that their audits will be delayed by a [https://en.wikipedia.org/wiki/Force_majeure force majeure], Mozilla expects the CA to promptly disclose the issue, to provide regular updates, and to remain fully compliant with all other aspects of the Mozilla Root Store policy. CAs that are unable to deliver timely and complete audit statements should arrange with their auditors to supply Mozilla with partial information whenever possible, via publicly-available audit statements listing qualifications, agreed-upon procedures (AUP) reports, or similar partial reporting mechanisms (described in more detail below).<br />
<br /><br /><br />
The CA must [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other file an incident bug in Bugzilla] to provide an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] explaining the situation with their audits, mitigations that have been or will be implemented, and their plan to move forward in reaching compliance again.<br />
* Whiteboard = [ca-compliance][audit-delay]<br />
* For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
== Minimum Expectations ==<br />
Situations will be considered and treated on a case by case basis. <br />
<br /><br />
The audit statement needs to clearly indicate which [[CA/Audit_Statements#Audited_Locations|audited locations]] were and were not audited, and whether the inspection at each location was physically carried out in person, and which audit criteria were checked (or not checked) at each location.<br />
<br />
=== ETSI Audits ===<br />
[https://groups.google.com/d/msg/mozilla.dev.security.policy/4Q6WAgLAvDo/zMJu6HWkAQAJ Guidance provided in mozilla.dev.security.policy] included the following: <br />
<br /><br />
If facilities can’t be audited by auditors of the CAB in person, possible alternatives are:<br />
* “Network-assisted auditing techniques” are possible (ETSI EN 319 403, 7.4.1.2) or<br />
* CAB may subcontract auditors that do not fall under the restriction, if they fulfil the auditor requirements. The CAB always remains fully responsible for such outsourced activities. (ISO/IEC 17065, 6.2.2 ).<br />
If such alternatives were accepted by the CAB to provide reasonable assurance with regard to the requirements to be audited, this would result in a normal audit conclusion and would not be visible on an audit attestation letter.<br />
<br />
An ETSI audit shall be performed in any case making sure that everything which reasonably can be audited will be audited - there is especially no restriction to do a full Stage 1 document audit. If facilities cannot be audited by auditors of the CAB in person and the two alternatives stated above are not possible or the CAB does not regard them to provide reasonable assurance with regard to the requirements to be audited in order to draw a reasonable audit conclusion this shall be documented in the audit report.<br />
<br /><br />
In any case an ETSI Audit Attestation Letter (AAL) shall be issued for the required audit period clearly stating in case limitations have been encountered by the auditor: the type of the limitation (e.g. control not audited in person or not audited at all) and description of the limitation (e.g. which controls were not covered in person or not covered at all). <br />
<br /><br /><br />
After audit restrictions have been lifted:<br />
An ETSI audit shall be performed as soon as restrictions have been lifted. It is possible to re-use the original audit results and perform an additional audit just with regard to the non audited requirements (ISO/IEC 17065, 7.4). Usually, the period during which this is possible is limited by the CAB (ACAB’c: 6 month). Once the original audit becomes too old, a completely new audit would be necessary.<br />
Therefore, the ETSI audit shall<br />
* either be focused on the parts not covered throughout the previous audit as stated in the AAL and comprise the same audit period as stated in the last report. In this case an amendment AAL for the original period would to be issued even it is dated more than 3 month after the end of the audit period.<br />
* or comprise the full audit scope of an ETSI audit and the audit period starting with the same begin date as stated in the last report. In this case a new AAL will be issued replacing the previous one and resulting in an extend period of more than 12 month.<br />
Please note: Such an extend period would only be possible, if a new full audit has been performed (covering the time of the original period plus the extension till the last day of the audit).<br />
<br />
For more guidance please refer to www.acab-c.com or send your request to cabforum@acab-c.com.<br />
<br />
=== WebTrust Audits ===<br />
[https://groups.google.com/d/msg/mozilla.dev.security.policy/4Q6WAgLAvDo/K7u11d6xAgAJ Guidance provided in mozilla.dev.security.policy] included the following: <br />
<br /><br />
Ultimately, when an auditor is not able to obtain assurance on the entire scope of the engagement, and realizing a carved out approach is not permitted in a WebTrust audit, for example, when a certain data center is not able to be visited to observe controls operating and underlying documentation, the auditor will not be able to provide an unmodified/unqualified/clean opinion and the client would not be able to display the WebTrust seal. In these situations, the auditor would include an explanatory paragraph that details what gave rise to the scope limitation and issue one of the following modified opinions:<br />
* Qualified opinion (when conditions are least severe but significant enough to mention), stating an except for paragraph explaining the condition(s) arising from the scope limitation, such as not being able to test the data center.<br />
* Adverse opinion (when conditions are more severe), stating that the conditions are such that due to the severity of the scope limitation, the auditor states controls are not operating effectively and they were not able to satisfy themselves that the necessary controls were able to operate.<br />
* Disclaimer of opinion (when conditions are most severe), stating that the auditor is unable to form any opinion due to the nature of the scope limitation.<br />
<br />
If the potential threat of a scope limitation is primarily due to an auditor not being able to travel to perform necessary testing, as with the Coronavirus, there are potential remedies for the auditor to consider, including, but not limited to:<br />
* Using the work of another auditor, whereby the lead auditor verifies the independence, qualifications and technical competency of another firm that can do a portion of the work, and the lead auditor directs the work, plans, supervises and reviews the other auditor’s work, taking ultimate responsibility. In this case, no mention of the other firm is made in the report as the lead auditor is taking responsibility for the other firm’s work.<br />
* Using technology to observe physical controls and underlying documents/artifacts via remote means, such as video. In this case, the auditor must ensure the authenticity, integrity, security and confidentiality of the transmission.<br />
<br />
= Auditor Qualifications =<br />
<br />
Section [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#32-auditors 3.2 of Mozilla's Root Store Policy] says: "Mozilla requires that audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2."<br />
<br />
Section 8.2 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements] says:<br />
The CA’s audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:<br />
# Independence from the subject of the audit;<br />
# The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 8.1);<br />
# Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;<br />
# (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO/IEC 17065 applying the requirements specified in ETSI EN 319 403; <br />
# (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;<br />
# Bound by law, government regulation, or professional code of ethics; and<br />
# Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.<br />
<br />
== Providing Auditor Qualifications ==<br />
<br /><br />
Version 2.7.1 of Mozilla's Root Store Policy requires CAs to have their auditor provide information about the auditor's qualifications when they provide audit statements. The information needs to be sufficient for us to see that the requirements listed above have been met by the audit team, but does not need to specifically name the individuals on the team, other than the lead auditor who signs the audit statement. The Audit Team may consist of one person provided that the person meets all criteria set out above and that there is an audit quality reviewer. <br />
<br />
CAs must submit a summary of the Audit Team's qualifications and experience, as outlined below with respect to the audit. The information can also be provided as part of the audit result documentation, like the [https://www.acab-c.com/downloads/ ETSI Audit Attestation Letter (AAL)], or as a supplement to the WebTrust Assurance Report.<br />
<br />
* Date that the audit report was signed<br />
* Full name of the CA that was audited<br />
* Name and address of the audit firm or Conformity Assessment Body (CAB)<br />
* Audit Criteria, e.g. ETSI / WebTrust<br />
* Proof of audit firm or CAB Accreditation (URL), see paragraphs below. <br />
* Name of Lead Auditor (except where prohibited by law or other public policy, in which case, we ask that you not provide any personally identifiable information)<br />
* For the Audit Team and the Audit Quality Reviewer, qualification information such as:<br />
** Number of Audit Team Members<br />
** Academic qualifications or professional training received<br />
** Average Years of Auditing Experience auditing trust services or similar information systems <br />
** Experience, Special Skills, and Qualifications (e.g. audit/assessment principles and functions, information technology, software development, trust services, public key infrastructure, CA operations, and information security including risk assessment/management, network security, physical security, etc.)<br />
** Credentials, Designations, or Certifications (e.g. CPA, CISA, CITP, CISSP, CCSP/CCA/CCP, etc.)<br />
* How the Audit Team and team members are bound by law, regulation or professional standards to render an independent assessment of the CA (e.g.https://pub.aicpa.org/codeofconduct/Ethics.aspx# 0.300.050 Objectivity and Independence; CPA Canada, Rule 204; or Annex A of ETSI EN 319 403/403-1, respectively)<br />
* Whether the Audit Team relied on any third-party specialists or affiliate audit firms, and if so, their names and where they performed services.<br />
<br />
== Verifying WebTrust Auditor Qualifications ==<br />
For WebTrust auditors, a representative of Mozilla confirms that the auditor's name and country are listed in [https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international CPA Canada's Licensed WebTrust practitioners web page]. <br />
<br />
Send email to webtrust@cpacanada.ca for more information about this list or about the process to become a licensed WebTrust practitioner.<br />
<br />
== Verifying ETSI Auditor Qualifications ==<br />
For ETSI auditors, a representative of Mozilla confirms that the auditor's name and [https://european-accreditation.org/ea-%20members/directory-of-ea-members-and-mla-signatories/ Accreditation Attestation] are listed in the [https://www.acab-c.com/members/ ACAB'c CAB-member List]. <br />
<br />
Send email to secretary@acab-c.org for more information about this list or about the process to become a accredited auditor for Trust Services under the EU eIDAS scheme following ETSI normative requirements as applicable to serve the [https://cabforum.org/ CA/B Forum] ecosystem and the [https://www.mozilla.org/projects/security/certs/policy/ Mozilla Browser Root Store Policy].<br />
<br /><br />
<br />
'''Comprehensive Check'''<br /><br />
<br />
The following additional check is only needed if the auditor's name and Accreditation Attestation are not listed in the [https://www.acab-c.com/members/ ACAB'c CAB-member List]. <br />
* Require the ETSI auditor to provide a comprehensive written explanation about why they are not listed in not listed in the [https://www.acab-c.com/members/ ACAB'c CAB-member List].<br />
* The auditor must provide a rationale clearly referring back to all of the following:<br />
** European Accreditation to demonstrate they act under the EU accreditation scheme,<br />
** ISO/IEC 17065 plus ETSI EN 319 403-1 to demonstrate they are accredited/allowed to audit publicly trusted CA/Trust Service Provider according to<br />
*** ETSI EN 319 401 and ETSI EN 319 411-1 and<br />
*** ETSI EN 319 411-2 for QWACS certificates according to the EU eIDAS Regulation 910/2014.<br />
* Review the documents and explanation.<br />
* Request external review from ACAB’c to provide opinion about the CAB's accreditation.</div>Kathleen Wilsonhttps://wiki.mozilla.org/index.php?title=CA/Audit_Statements&diff=1246289CA/Audit Statements2023-04-25T18:33:57Z<p>Kathleen Wilson: updated links</p>
<hr />
<div>= Audit Letter Content =<br />
CA Audits are one of the primary mechanisms relied upon by Mozilla to ensure that a CA is operating securely and in compliance with our policies. CA audits and audit statements must comply with the following requirements.<br />
* Section 3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy]<br />
* [https://www.ccadb.org/policy#51-audit-statement-content Section 5.1 of the Common CCADB Policy].<br />
* Section 8 of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements], if the root certificate has the Websites (TLS/SSL) trust bit enabled.<br />
<br />
Format Requirements:<br />
* SHA-256 Fingerprints<br />
** MUST: No colons, no spaces, and no line feeds<br />
** MUST: Uppercase letters<br />
** MUST: be encoded in the document (PDF) as text searchable, not an image<br />
* Dates<br />
** Month DD, YYYY example: May 7, 2016<br />
** DD Month YYYY example: 7 May 2016<br />
** YYYY-MM-DD example: 2016-05-07<br />
** Month names in English<br />
** No extra text within the date, such as “7th” or “the”<br />
<br />
== Audited Locations ==<br />
Both ETSI and WebTrust Audits should:<br />
* Disclose each location (at the state/province level) that was included in the scope of the audit or should have been included in the scope of the audit, whether the inspection was physically carried out in person at each location, and which audit criteria were checked (or not checked) at each location.<br />
** If the CA has more than one location in the same state/province, then use terminology to clarify the number of facilities in that state/province and whether or not all of them were audited. For example: "Facility 1 in Province", "Facility 2 in Province, Facility 3 in Province" '''or''' "Primary Facility in Province", "Secondary Facility in Province", "Tertiary Facility in Province". <br />
*** The public audit statement does not need to identify the type of Facility.<br />
*** "Facility" includes: data center locations, registration authority locations, where IT and business process controls of CA operations are performed, facility hosting an active HSM with CA private keys, facility or bank deposit box storing a deactivated and encrypted copy of a private key.<br />
<br />
= Audit Lifecycle =<br />
Mozilla's Root Store Policy states the following requirements which apply to root certificates and all intermediate certificates that have at least one valid, unrevoked chain up to an included root certificate and which are technically capable of issuing working server or email certificates as described in section 1.1 of Mozilla's [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] . <br />
* Before being included and periodically thereafter, CAs MUST obtain certain audits for their root certificates and all of their intermediate certificates that are technically capable of issuing working server or email certificates. <br />
* Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA certificate is no longer trusted by Mozilla's root store. <br />
** A CA certificate is considered to be trusted by Mozilla's root store as long as it is not expired, not in OneCRL, and either is directly included in Mozilla's root store or chains up (via subject/issuer) to another certificate that is included in Mozilla's root store. <br />
*** A CA certificate that has the Websites trust bit enabled is considered to be trusted by Mozilla's root store as long as Firefox continues to treat is as either a trusted root certificate or a trusted intermediate certificate. Reference: [[SecurityEngineering/Certificate_Verification|How Firefox Performs Certificate Verification and path construction]] <br />
** Note: If a CA stops providing audit statements for a root certificate for any reason, then the certificate may be added to OneCRL in addition to being removed from Mozilla's root store.<br />
* Successive audits MUST be contiguous (no gaps).<br />
* Audit reports which are being supplied to maintain a certificate within the Mozilla root program MUST be provided to Mozilla via the CCADB within three months of the end date of the period.<br />
* For Intermediate Certificates only: If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports.<br />
<br />
Other Audits:<br />
* Point-in-Time Audits: Point-in-time audit statements may be used to confirm that all of the problems that an auditor previously identified in a qualified audit statement have been corrected. However, a point-in-time audit does not replace the period-of-time audit.<br />
* Readiness Assessment: The [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] state: If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in Section 8.1, then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 8.1. The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate.<br />
<br />
= Audit Letter Validation =<br />
The contents of this section and its sub-sections have been moved to https://www.ccadb.org/cas/alv.<br />
== Root Certificates ==<br />
This section has been moved to https://www.ccadb.org/cas/alv#root-certificates<br />
== Intermediate Certificates ==<br />
This section has been moved to https://www.ccadb.org/cas/alv#intermediate-certificates<br />
== Common ALV Findings ==<br />
This section has been moved to https://www.ccadb.org/cas/alv#common-alv-findings<br />
<br />
= Audit Delay =<br />
An Audit Delay is when one or more of the following requirements in section 3.1.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] cannot be met:<br />
* "Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually."<br />
* "... MUST be provided to Mozilla via the CCADB within three months of the point-in-time date or the end date of the period."<br />
<br />
If a CA fails to deliver audit statements to Mozilla when they are due, Mozilla may take action to reduce the risks this presents to our users. The following guidance is intended for CAs in such a situation.<br />
<br /><br /><br />
When a CA realizes that their audits will be delayed by a [https://en.wikipedia.org/wiki/Force_majeure force majeure], Mozilla expects the CA to promptly disclose the issue, to provide regular updates, and to remain fully compliant with all other aspects of the Mozilla Root Store policy. CAs that are unable to deliver timely and complete audit statements should arrange with their auditors to supply Mozilla with partial information whenever possible, via publicly-available audit statements listing qualifications, agreed-upon procedures (AUP) reports, or similar partial reporting mechanisms (described in more detail below).<br />
<br /><br /><br />
The CA must [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other file an incident bug in Bugzilla] to provide an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] explaining the situation with their audits, mitigations that have been or will be implemented, and their plan to move forward in reaching compliance again.<br />
* Whiteboard = [ca-compliance][audit-delay]<br />
* For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
== Minimum Expectations ==<br />
Situations will be considered and treated on a case by case basis. <br />
<br /><br />
The audit statement needs to clearly indicate which [[CA/Audit_Statements#Audited_Locations|audited locations]] were and were not audited, and whether the inspection at each location was physically carried out in person, and which audit criteria were checked (or not checked) at each location.<br />
<br />
=== ETSI Audits ===<br />
[https://groups.google.com/d/msg/mozilla.dev.security.policy/4Q6WAgLAvDo/zMJu6HWkAQAJ Guidance provided in mozilla.dev.security.policy] included the following: <br />
<br /><br />
If facilities can’t be audited by auditors of the CAB in person, possible alternatives are:<br />
* “Network-assisted auditing techniques” are possible (ETSI EN 319 403, 7.4.1.2) or<br />
* CAB may subcontract auditors that do not fall under the restriction, if they fulfil the auditor requirements. The CAB always remains fully responsible for such outsourced activities. (ISO/IEC 17065, 6.2.2 ).<br />
If such alternatives were accepted by the CAB to provide reasonable assurance with regard to the requirements to be audited, this would result in a normal audit conclusion and would not be visible on an audit attestation letter.<br />
<br />
An ETSI audit shall be performed in any case making sure that everything which reasonably can be audited will be audited - there is especially no restriction to do a full Stage 1 document audit. If facilities cannot be audited by auditors of the CAB in person and the two alternatives stated above are not possible or the CAB does not regard them to provide reasonable assurance with regard to the requirements to be audited in order to draw a reasonable audit conclusion this shall be documented in the audit report.<br />
<br /><br />
In any case an ETSI Audit Attestation Letter (AAL) shall be issued for the required audit period clearly stating in case limitations have been encountered by the auditor: the type of the limitation (e.g. control not audited in person or not audited at all) and description of the limitation (e.g. which controls were not covered in person or not covered at all). <br />
<br /><br /><br />
After audit restrictions have been lifted:<br />
An ETSI audit shall be performed as soon as restrictions have been lifted. It is possible to re-use the original audit results and perform an additional audit just with regard to the non audited requirements (ISO/IEC 17065, 7.4). Usually, the period during which this is possible is limited by the CAB (ACAB’c: 6 month). Once the original audit becomes too old, a completely new audit would be necessary.<br />
Therefore, the ETSI audit shall<br />
* either be focused on the parts not covered throughout the previous audit as stated in the AAL and comprise the same audit period as stated in the last report. In this case an amendment AAL for the original period would to be issued even it is dated more than 3 month after the end of the audit period.<br />
* or comprise the full audit scope of an ETSI audit and the audit period starting with the same begin date as stated in the last report. In this case a new AAL will be issued replacing the previous one and resulting in an extend period of more than 12 month.<br />
Please note: Such an extend period would only be possible, if a new full audit has been performed (covering the time of the original period plus the extension till the last day of the audit).<br />
<br />
For more guidance please refer to www.acab-c.com or send your request to cabforum@acab-c.com.<br />
<br />
=== WebTrust Audits ===<br />
[https://groups.google.com/d/msg/mozilla.dev.security.policy/4Q6WAgLAvDo/K7u11d6xAgAJ Guidance provided in mozilla.dev.security.policy] included the following: <br />
<br /><br />
Ultimately, when an auditor is not able to obtain assurance on the entire scope of the engagement, and realizing a carved out approach is not permitted in a WebTrust audit, for example, when a certain data center is not able to be visited to observe controls operating and underlying documentation, the auditor will not be able to provide an unmodified/unqualified/clean opinion and the client would not be able to display the WebTrust seal. In these situations, the auditor would include an explanatory paragraph that details what gave rise to the scope limitation and issue one of the following modified opinions:<br />
* Qualified opinion (when conditions are least severe but significant enough to mention), stating an except for paragraph explaining the condition(s) arising from the scope limitation, such as not being able to test the data center.<br />
* Adverse opinion (when conditions are more severe), stating that the conditions are such that due to the severity of the scope limitation, the auditor states controls are not operating effectively and they were not able to satisfy themselves that the necessary controls were able to operate.<br />
* Disclaimer of opinion (when conditions are most severe), stating that the auditor is unable to form any opinion due to the nature of the scope limitation.<br />
<br />
If the potential threat of a scope limitation is primarily due to an auditor not being able to travel to perform necessary testing, as with the Coronavirus, there are potential remedies for the auditor to consider, including, but not limited to:<br />
* Using the work of another auditor, whereby the lead auditor verifies the independence, qualifications and technical competency of another firm that can do a portion of the work, and the lead auditor directs the work, plans, supervises and reviews the other auditor’s work, taking ultimate responsibility. In this case, no mention of the other firm is made in the report as the lead auditor is taking responsibility for the other firm’s work.<br />
* Using technology to observe physical controls and underlying documents/artifacts via remote means, such as video. In this case, the auditor must ensure the authenticity, integrity, security and confidentiality of the transmission.<br />
<br />
= Auditor Qualifications =<br />
<br />
Section [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#32-auditors 3.2 of Mozilla's Root Store Policy] says: "Mozilla requires that audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2."<br />
<br />
Section 8.2 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements] says:<br />
The CA’s audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:<br />
# Independence from the subject of the audit;<br />
# The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 8.1);<br />
# Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;<br />
# (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO/IEC 17065 applying the requirements specified in ETSI EN 319 403; <br />
# (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;<br />
# Bound by law, government regulation, or professional code of ethics; and<br />
# Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.<br />
<br />
== Providing Auditor Qualifications ==<br />
<br /><br />
Version 2.7.1 of Mozilla's Root Store Policy requires CAs to have their auditor provide information about the auditor's qualifications when they provide audit statements. The information needs to be sufficient for us to see that the requirements listed above have been met by the audit team, but does not need to specifically name the individuals on the team, other than the lead auditor who signs the audit statement. The Audit Team may consist of one person provided that the person meets all criteria set out above and that there is an audit quality reviewer. <br />
<br />
CAs must submit a summary of the Audit Team's qualifications and experience, as outlined below with respect to the audit. The information can also be provided as part of the audit result documentation, like the [https://www.acab-c.com/downloads/ ETSI Audit Attestation Letter (AAL)], or as a supplement to the WebTrust Assurance Report.<br />
<br />
* Date that the audit report was signed<br />
* Full name of the CA that was audited<br />
* Name and address of the audit firm or Conformity Assessment Body (CAB)<br />
* Audit Criteria, e.g. ETSI / WebTrust<br />
* Proof of audit firm or CAB Accreditation (URL), see paragraphs below. <br />
* Name of Lead Auditor (except where prohibited by law or other public policy, in which case, we ask that you not provide any personally identifiable information)<br />
* For the Audit Team and the Audit Quality Reviewer, qualification information such as:<br />
** Number of Audit Team Members<br />
** Academic qualifications or professional training received<br />
** Average Years of Auditing Experience auditing trust services or similar information systems <br />
** Experience, Special Skills, and Qualifications (e.g. audit/assessment principles and functions, information technology, software development, trust services, public key infrastructure, CA operations, and information security including risk assessment/management, network security, physical security, etc.)<br />
** Credentials, Designations, or Certifications (e.g. CPA, CISA, CITP, CISSP, CCSP/CCA/CCP, etc.)<br />
* How the Audit Team and team members are bound by law, regulation or professional standards to render an independent assessment of the CA (e.g.https://pub.aicpa.org/codeofconduct/Ethics.aspx# 0.300.050 Objectivity and Independence; CPA Canada, Rule 204; or Annex A of ETSI EN 319 403/403-1, respectively)<br />
* Whether the Audit Team relied on any third-party specialists or affiliate audit firms, and if so, their names and where they performed services.<br />
<br />
== Verifying WebTrust Auditor Qualifications ==<br />
For WebTrust auditors, a representative of Mozilla confirms that the auditor's name and country are listed in [https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international CPA Canada's Licensed WebTrust practitioners web page]. <br />
<br />
Send email to webtrust@cpacanada.ca for more information about this list or about the process to become a licensed WebTrust practitioner.<br />
<br />
== Verifying ETSI Auditor Qualifications ==<br />
For ETSI auditors, a representative of Mozilla confirms that the auditor's name and [https://european-accreditation.org/ea-%20members/directory-of-ea-members-and-mla-signatories/ Accreditation Attestation] are listed in the [https://www.acab-c.com/members/ ACAB'c CAB-member List]. <br />
<br />
Send email to secretary@acab-c.org for more information about this list or about the process to become a accredited auditor for Trust Services under the EU eIDAS scheme following ETSI normative requirements as applicable to serve the [https://cabforum.org/ CA/B Forum] ecosystem and the [https://www.mozilla.org/projects/security/certs/policy/ Mozilla Browser Root Store Policy].<br />
<br />
==== Comprehensive Check ====<br />
The following additional check is only needed if the auditor's name and Accreditation Attestation are not listed in the [https://www.acab-c.com/members/ ACAB'c CAB-member List]. <br />
* Require the ETSI auditor to provide a comprehensive written explanation about why they are not listed in not listed in the [https://www.acab-c.com/members/ ACAB'c CAB-member List].<br />
* The auditor must provide a rationale clearly referring back to all of the following:<br />
** European Accreditation to demonstrate they act under the EU accreditation scheme,<br />
** ISO/IEC 17065 plus ETSI EN 319 403-1 to demonstrate they are accredited/allowed to audit publicly trusted CA/Trust Service Provider according to<br />
*** ETSI EN 319 401 and ETSI EN 319 411-1 and<br />
*** ETSI EN 319 411-2 for QWACS certificates according to the EU eIDAS Regulation 910/2014.<br />
* Review the documents and explanation.<br />
* Request external review from ACAB’c to provide opinion about the CAB's accreditation.</div>Kathleen Wilson