https://wiki.mozilla.org/api.php?action=feedcontributions&user=Wthayer&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T12:47:01ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=CA/Required_or_Recommended_Practices&diff=1224308CA/Required or Recommended Practices2020-02-27T15:56:11Z<p>Wthayer: /* CP/CPS Structured According to RFC 3647 */ Reference updated policy</p>
<hr />
<div>This page contains a set of practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are required by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and so are mandatory for a CA to have its root certificate(s) included. They are listed here because they are things CAs often get wrong. In other cases the practices are only recommended, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.<br />
<br />
== Required Practices ==<br />
<br />
=== Publicly Available CP and CPS ===<br />
<br />
CAs must supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.<br />
<br />
* The CP/CPS must be publicly available from the CA's official web site.<br />
* The CP/CPS must clearly indicate which root and subordinate certificates the practices and processes described in those documents apply to.<br />
* The format of the CP/CPS document must be PDF or another suitable format for reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.<br />
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.<br />
* The CA must provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.<br />
<br />
===== CP/CPS Revision Table =====<br />
<br />
Section 3.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] states: "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document."<br />
<br />
===== CAA Domains listed in CP/CPS =====<br />
<br />
Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs] states: "CA's Certificate Policy and/or Certification Practice<br />
Statement ... '''shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA''' "issue" or<br />
"issuewild" records as permitting it to issue.<br />
<br />
===== BR Commitment to Comply statement in CP/CPS =====<br />
<br />
For root certificates with the Websites (TLS/SSL) trust bit enabled, Mozilla requires the corresponding CP/CPS documents to include a statement of commitment to comply with the CA/Browser Forum's Baseline Requirements, as per section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs.]<br />
<br />
===== CP/CPS Structured According to RFC 3647 =====<br />
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements, with the effective of 31 May 2018. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.<br />
* The words "''No Stipulation''" mean that the particular document imposes no requirements related to that section. <br />
** Note that Mozilla's root store policy has been updated to define acceptable usage of "No Stipulation" in CP/CPS documents. <br />
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred. <br />
* Sections should not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional.<br />
** Note that Mozilla's root store policy may be updated soon to forbid blank sections in CP/CPS documents. <br />
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. Cross-referencing between CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.<br />
* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to SSL certificates.<br />
<br />
Examples:<br />
* If your CA does not allow a particular domain validation method to be used, then the CP or CPS should say that, e.g. "This method of domain validation is not used".<br />
* If your CP delegates requirements to one or more CPSs, then the CP should state "Refer to CPS".<br />
* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for SSL certs, and then the other sections related to suspension should say “Not applicable”.<br />
* If your CA does not issue SSL certs containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed; e.g. “No IP address certificates are issued under this CPS.”<br />
* If your CP contains the full description of section 5, then the CPS may say "As stipulated in section 5 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)<br />
<br />
===== CP/CPS Documents will be Reviewed! =====<br />
<br />
During the [[CA/Application_Verification#Detailed_Review|Detailed Review]] phase, <br />
your CP/CPS documentation will be thoroughly reviewed and commented on. Concerns raised by the reviewer must be sufficiently resolved before the request will be allowed to enter [[CA/Application_Verification#Public_discussion|public discussion]]. <br />
<br />
Here are some examples of previous reviews of CP/CPS documents:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1102143#c25 Detailed Review Feedback on Firmaprofesional]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13 Detailed Review Feedback on certSIGN CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1474556#c16 Detailed Review Feedback on Dubai Government CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1448093#c56 Detailed Review Feedback on Microsoft CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1480510#c10 Detailed Review Feedback on Entrust CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]<br />
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]<br />
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.<br />
<br />
=== Audit Criteria ===<br />
<br />
CAs must supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.<br />
<br />
* The CA must indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).<br />
* All documents supplied as evidence must be publicly available.<br />
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).<br />
<br />
==== Complete Audit History ====<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#71-inclusions Mozilla's Root Store Policy] states: "Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements." To meet this requirement CAs must provide public-facing audit statements for all of the audits that have been conducted from the time of root creation, for both the root and the non-[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained technically-constrained] intermediate certificates in the hierarchy. This includes:<br />
* Root key generation report<br />
* Any Point in time audits<br />
* All Period of time audits<br />
<br />
This requirement may be met via one of the following options:<br />
* Providing the sequence of audit statements on the CA's website.<br />
* Attaching the sequence of audit statements to the root inclusion request (Bugzilla Bug).<br />
<br />
=== Revocation of Compromised Certificates ===<br />
<br />
CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.<br />
<br />
=== Verifying Domain Name Ownership ===<br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has registered all domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf. This must be done using one or more of the methods documented in section 3.2.2.4 of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with. CAs are not permitted to use 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address)."<br />
<br />
The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.<br />
<br />
===== Baseline Requirements =====<br />
<br />
It is '''not''' sufficient to simply reference section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements (BR)]. The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 3.2.2.4 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. Section 2.3 of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes '''in detail''' how the CA implements the latest version of these Requirements."<br />
<br />
'''Important:'''<br />
* The CPS should state what the CA actually does, not what it could do. Such as which of the allowed domain validation methods the CA uses.<br />
* BR subsections 3.2.2.4.1 and 3.2.2.4.5 were banned effective 1-August-2018.<br />
** "CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods"<br />
* BR subsection 3.2.2.4.9 was banned by ballot SC15, effective 16-March 2019.<br />
* BR subsection 3.2.2.4.10 contains major vulnerabilities. If the CA uses this method, then the CA should describe how they are mitigating those vulnerabilities. If not using this method, the CPS should say so.<br />
* BR section 3.2.2.5(4) was updated by ballot SC7 to remove "any other method", effective 1-August 2019. Prior to that date:<br />
** Saying the CA follows BR section 3.2.2.5 does not meet [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's disclosure requirements for this method]. The CPS must describe if/how "any other method" is implemented.<br />
** BR subsection 3.2.2.5(4) "any other method" is not permitted in conjunction with 3.2.2.4.8 per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's Root Store Policy]. The CPS should be clear that they do not do that.<br />
<br />
===== WHOIS =====<br />
<br />
[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking <br />
ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.<br />
<br />
It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?<br />
<br />
===== Email Challenge-Response =====<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. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]<br />
<br />
CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to cause and obtain certificates for example.com. Please work with your engineering department to ensure your systems properly handle such cases, as well as handling productions such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.<br />
<br />
=== Verifying Email Address Control === <br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."<br />
<br />
The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.<br />
<br />
The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.<br />
<br />
It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.<br />
<br />
=== DNS names go in SAN ===<br />
<br />
According to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements:]<br />
* Section 7.1.4.2.1 states:<br />
** Certificate Field: '''extensions:subjectAltName'''<br />
** Required/Optional: '''Required'''<br />
** Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.<br />
* Section 7.1.4.2.2 states:<br />
** Certificate Field: '''subject:commonName''' (OID 2.5.4.3)<br />
** Required/Optional: Deprecated ('''Discouraged''', but not prohibited)<br />
** Contents: If present, this field '''MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension''' (see Section 7.1.4.2.1).<br />
<br />
=== OCSP ===<br />
<br />
OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80. <br />
<br />
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements]:<br />
# The OCSP URI must be provided in the certificate, except when OCSP stapling is used. (sections 7.1.2.2, 7.1.2.3)<br />
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (section 4.9.10)<br />
# OCSP Responses shall be updated at least every four days and have a maximum expiration time of ten days (section 4.9.10)<br />
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (section 7.1.3)<br />
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (section 4.9.9)<br />
<br />
You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:<br />
* Go to Firefox -> Preferences... -> Privacy & Security -> Certificates<br />
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"<br />
* You may need to clear your history cache<br />
* Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.<br />
<br />
=== Network Security Controls ===<br />
<br />
CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.<br />
<br />
It is expected that CAs do the following on a regular basis:<br />
* Maintain network security controls that at minimum meet the [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements.]<br />
* Check for mis-issuance of certificates, especially for high-profile domains.<br />
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.<br />
* Ensure Intrusion Detection System and other monitoring software is up-to-date.<br />
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.<br />
<br />
== Recommended Practices ==<br />
<br />
=== CA Hierarchy ===<br />
<br />
A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See [[CA:Recommendations_for_Roots]].<br />
<br />
CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:<br />
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs<br />
* The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.<br />
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.<br />
<br />
We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).<br />
<br />
=== Document Handling of IDNs in CP/CPS ===<br />
<br />
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)<br />
<br />
=== Usage of Appropriate Constraints ===<br />
<br />
Root certificates in Mozilla's program can have either the SSL trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.<br />
<br />
=== Pre-Issuance Linting ===<br />
<br />
Recently, several tools have been developed ([https://github.com/awslabs/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.<br />
<br />
=== Precertificates ===<br />
<br />
The current implementation of [https://www.certificate-transparency.org/ Certificate Transparency] does not provide any way for Relying Parties to determine if a certificate corresponding to a given precertificate has or has not been issued. It is only safe to assume that a certificate corresponding to every precertificate exists.<br />
<br />
[https://tools.ietf.org/html/rfc6962 RFC 6962] states “The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate).”<br />
<br />
However, [https://cabforum.org/baseline-requirements-documents/ BR] section 7.1.2.5 states “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.”<br />
<br />
Mozilla [https://cabforum.org/pipermail/public/2014-January/002694.html interprets] the BR language as a specific exception allowing CAs to issue a precertificate containing the same serial number as the subsequent certificate. Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued.<br />
<br />
This means, for example, that:<br />
* A CA must provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a Precertificate, even if the certificate does not actually exist<br />
* A CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under Mozilla policy, even if the certificate does not actually exist.<br />
* If any corresponding certificate with the same serial number and issuer exists, and can not be verified to match the precertificate using the algorithms in RFC 6962, it will be considered misissued.<br />
* In examining historical issuance, the CA must consider both final certificates and precertificates, even if the precertificate did not ultimately result in the issuance of a certificate.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Communications&diff=1221923CA/Communications2020-01-06T20:17:50Z<p>Wthayer: Add Jan 2020 survey info</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 />
== January 2020 CA Communication ==<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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], click on the 'CA Communications (Page)' tab, 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)], click on the 'CA Communications (Page)' tab, and select the ‘September 2018 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-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00082,Q00083 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00084,Q00085 Responses to Action 2] -- Update CP/CPS <br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00086,Q00087 Responses to Action 3] -- Include EKUs in All End-entity Certificates<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00088,Q00089 Responses to Action 4] -- Ensure Audit Reports are Properly Formatted<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00090,Q00091 Responses to Action 5] -- Resolve Audit Issues with Intermediate Certificates<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00092,Q00093 Responses to Action 6] -- Incident Reporting<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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], click on the 'CA Communications (Page)' tab, 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)], click on the 'CA Communications (Page)' tab, 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-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00068,Q00069 Responses to Action 1] -- Review Mozilla Root Store Policy<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00070,Q00071 Responses to Action 2] -- Update CP/CPS<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00072,Q00073 Responses to Action 3] -- Transition to Separate Intermediate Certificates for SSL and S/MIME<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00074,Q00075 Responses to Action 4] -- Ensure Audit Reports comply with Mozilla’s Root Store Policy<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00078,Q00079 Responses to Action 6] -- Disclose Intermediate Certificates<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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], click on the 'CA Communications (Page)' tab, 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), click on the 'CA Communications (Page)' tab, 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-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00060,Q00061 Responses to Action 3] -- Disclose All Non-Technically-Constrained Subordinate CA Certificates<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003mqMFN&QuestionId=Q00062,Q00063 Responses to Action 4] -- Complete BR Self Assessment<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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], click on the 'CA Communications (Page)' tab, 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)], click on the 'CA Communications (Page)' tab, 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-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00038,Q00045 Responses to Action 3] -- Annual updates via [http://ccadb.org/cas/updates CCADB Audit Cases]<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00039,Q00046 Responses to Action 5] -- Perform a [[CA/BR_Self-Assessment|BR Self Assessment]]<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00042,Q00048 Responses to Action 6] -- Provide tested email address for [https://ccadb-public.secure.force.com/mozilla/CAInformationReport Problem Reporting Mechanism]<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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/mozillacommunications<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-public.secure.force.com/mozillacommunications/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], click on the 'CA Communications (Page)' tab, 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)], click on the 'CA Communications (Page)' tab, 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-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00015,Q00030 Responses to Action 1] -- Domain Validation<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 2 and Action 10] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00022,Q00029 Responses to Action 3] -- Updated Mozilla CA Certificate Policy<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00017,Q00031 Responses to Action 4] -- Audit Statements, annual updates<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00018,Q00032 Responses to Action 5] -- Audit Statement Contents<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00021,Q00033 Responses to Action 6] -- Qualified Audit Statements<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00019 Responses to Action 7] -- BR Compliance Bugs<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 Responses to Action 8] -- Confirm Completion of Previous Commitments<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00027 Responses to Action 9] -- Registration Authorities<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00016,Q00025 Responses to Action 10 and Action 2] -- Yearly CP/CPS Updates, Test Tools<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00023 Responses to Action 11] -- Certification Authority Authorization (CAA)<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00028 Responses to Action 12] -- Problem Reporting Mechanism<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00024 Responses to Action 13] -- SHA-1 and S/MIME<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00034 Responses to Action 14] -- Certificate Validity Periods in TLS/SSL Certs<br />
<br />
== March 2016 ==<br />
<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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]], click on the 'CA Communications (Page)' tab, 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-public.secure.force.com/mozillacommunications/CACommSummaryReport?CommunicationID=a05o000000iHdtx CA Responses to March 2016 CA Communication]<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00001,Q00013 Responses to Action #1a] -- SHA-1 Deprecation dates<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00002,Q00014 Responses to Action #1b] -- SHA-1 Deprecation dates<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 Responses to Action #1c] -- SHA-1 Deprecation<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 Responses to Action #2] -- Entering intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00005 Responses to Action #3] -- Entering revoked intermediate certificate data into the CA Community in Salesforce<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00008 Responses to Action #5] -- Plans to remove old/retired root certificates<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/CommunicationSummaryReport?CommunicationId=a04o000000M89RCAAZ CA Responses to May 2015 CA Communication]<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%233:%20After%20January%201,%202016 Responses to Action #3] -- SHA-1 Deprecation Plans<br />
* [https://ccadb-public.secure.force.com/mozillacommunications/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-public.secure.force.com/mozillacommunications/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>Wthayerhttps://wiki.mozilla.org/index.php?title=User_talk:Wthayer&diff=1221816User talk:Wthayer2020-01-03T23:49:41Z<p>Wthayer: /* "contractually agreed"?? */ response</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:SpikeUK1|SpikeUK1]] ([[User talk:SpikeUK1|talk]]) 19:41, 28 November 2017 (UTC)<br />
<br />
== "contractually agreed"?? ==<br />
<br />
Re. [https://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1221445&oldid=1218678 your edit]. I see ''promises'' in the policies. I don't see anything ''contractually agreed'' to; there's [https://www.google.com/search?client=firefox-b-1-d&q=%22contract+law%22+privacy+policy no contract]. Agreed? Or are there contracts <nowiki>({{fact}})</nowiki>? --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 23:27, 3 January 2020 (UTC)<br />
<br />
There are legal contracts executed between Mozilla and those listed providers.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA&diff=1221776CA2020-01-02T17:01:17Z<p>Wthayer: Update policy version</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/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 />
* [http://www.mozilla.org/projects/security/certs/policy/ Root Store Policy] (current stable version: 2.7)<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 />
<br />
== Lists of CAs and Certificates ==<br />
<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 [http://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/Certificate_Change_Requests|Certificate Change Requests]] as tracked in the CCADB<br />
* [[CA/Incident_Dashboard|Incident and Compliance 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 />
* [http://ccadb.org/cas/ CCADB Login]<br />
* [[CA/Responding_To_An_Incident|Responding to an Incident]] (such as a misissuance)<br />
* [[CA/Application_Process|Application Process for Mozilla's Root Program]]<br />
** [[CA/BR_Self-Assessment|Baseline Requirements Self Assessment]]<br />
** [[CA/Information_Checklist|CA Information Checklist]]<br />
** [[CA/Subordinate_CA_Checklist|Subordinate CA Information Checklist]]<br />
* [[CA/Certificate_Change_Process|Making Changes to Included Roots]]<br />
* [[CA/Required_or_Recommended_Practices|Required or Recommended CA Practices]]<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 />
* [[PSM:EV_Testing_Easy_Version|EV Readiness Test]]<br />
* [https://github.com/awslabs/certlint BR Lint Certificate Test] - 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 />
<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-public.secure.force.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=NSS&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/Upcoming_Distrust_Actions|Significant upcoming CA Distrust Actions]]<br />
* [[CA/Terminology|Glossary of CA and Certificate Terminology]]<br />
* [[PSM:Changing_Trust_Settings|Changing Certificate Trust Settings in Firefox]]<br />
* [https://tls-observatory.services.mozilla.com/static/certsplainer.html Mozilla's Certificate Explainer]<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-public.secure.force.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 Mozilla public forums are relevant to CA evaluation and related issues. Each forum can be accessed either as a mailing list, over the web or as a newsgroup.<br />
<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] (MDSP). This forum is used for discussions of Mozilla policies related to security in general and CAs in particular, and for wider discussions about the WebPKI. Among other things, it is the preferred forum for the public comment phase of CA evaluation. If you are a regular participant in MDSP, then please add your name to the [[CA/Policy_Participants|Policy Participants]] page.<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-tech-crypto mozilla.dev.tech.crypto]. This forum is used for discussions of the [http://www.mozilla.org/projects/security/pki/nss/ NSS] cryptographic library used in Firefox and other Mozilla-based products, as well as the [http://www.mozilla.org/projects/security/pki/psm/ PSM] module that implements higher-level security protocols for Firefox.<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-security mozilla.dev.security]. This forum is used for discussions of Mozilla security issues in general.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident&diff=1221572CA/Responding To An Incident2019-12-19T20:11:25Z<p>Wthayer: /* Incident Report */ add separate report guidance</p>
<hr />
<div>The page gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. <br />
<br />
For the purposes of this page, a "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. Researchers who report CA incidents such as misissuances are welcome to include a link to this page in their report to the CA, reminding the CA that Mozilla has the following expectations. This document is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained therein.<br />
<br />
Other examples of incidents include misconfigured OCSP responders, un-revocations, and any other event affecting trust in the WebPKI which does not involve the actual contents of certificates.<br />
<br />
While some forms of incident may be seen as less serious than others, opinions vary on which these are. Mozilla sees all incidents as good opportunities for the CA to test that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity.<br />
<br />
To be clear on the status of this document: this is a best practices document, not an official policy, and does not use normative language. Therefore, failure to follow one or more of the recommendations here is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response. <br />
<br />
= Immediate Actions =<br />
<br />
In misussuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI until you have diagnosed the source of the problem, or explain why this has not been done.<br />
<br />
Once the problem is diagnosed, you may restart issuance even if a full fix is not rolled out, if you are able to put in place temporary or manual procedures to prevent the problem from re-occurring. You should not restart issuance until you are confident that the problem will not re-occur.<br />
<br />
= Revocation =<br />
<br />
It is normal practice for CAs to revoke misissued certificates. But that leaves the question about '''when''' this should be done, particularly if it's not possible to contact the customer immediately, or if they are unable to replace their certificate quickly. Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements currently states (version 1.6.3):<br />
<br />
<blockquote><br />
“The CA SHOULD revoke a Certificate within 24 hours and MUST revoke a Certificate with 5 days if one or more of the following occurs: …<br><br />
7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;<br><br />
8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; …<br><br />
10. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or<br><br />
11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the Private Key was flawed."<br />
</blockquote><br />
<br />
This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 5 days.<br />
<br />
Mozilla recognizes that in some '''exceptional''' circumstances, revoking misissued certificates within the prescribed deadline may cause significant harm, such as when the certificate is used in critical infrastructure and cannot be safely replaced prior to the revocation deadline, or when the volume of revocations in a short period of time would result in a large cumulative impact to the web. However, Mozilla does not grant exceptions to the BR revocation requirements. It is our position that your CA is ultimately responsible for deciding if the harm caused by following the requirements of BR section 4.9.1 outweighs the risks that are passed on to individuals who rely on the web PKI by choosing not to meet this requirement.<br />
<br />
If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that:<br />
<br />
* The decision and rationale for delaying revocation will be disclosed to Mozilla in the form of a preliminary incident report immediately; preferably before the BR mandated revocation deadline. The rationale must include an explanation for why the situation is exceptional. Responses similar to “we deem this misissuance not to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.<br />
* Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a clear timeline describing if and when the problematic certificates will be revoked or expire naturally, and supported by the rationale to delay revocation.<br />
* The issue will need to be listed as a finding in your CA’s next BR audit statement.<br />
* Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.<br />
* That you will perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays.<br />
<br />
If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.<br />
<br />
= Follow-Up Actions =<br />
<br />
* Work out how the bug or problem was introduced. For a code bug, were the code review processes sufficient? Does your code have automated tests, and if so, why did they not catch this case?<br />
<br />
* Work out why the problem was not detected earlier. Were these certificates missed by your self-audits? Or is the code or process you use for such audits insufficiently frequent or rigorous?<br />
<br />
* If the problem is lack of compliance to an RFC, Baseline Requirement or Mozilla Policy requirement: were you aware of this requirement? If not, why not? If so, was an attempt made to meet it? If not, why not? If so, why was that attempt flawed? Do any processes need updating for making sure your CA complies with the latest version of the various requirements placed upon it?<br />
<br />
* Scan your corpus of certificates to look for others with the same issue. It does not look good for a CA to claim they have revoked all affected certificates and resolved the issue, and then for a researcher to discover another set of certificates with the same or a similar problem.<br />
<br />
* Examine whether there are potential related problems which you can also remediate at the same time. For example, if the problem was bad data in a particular field, consider improving the validation of all fields in the certificate prior to issuance. You should be proactively looking for [https://crt.sh/linttbscert ways] to harden your issuance pipeline against further problems.<br />
<br />
* If, as happens in a regrettably large number of cases, a problem report was sent to your CA but action in accordance with BR section 9.4.5 was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate.<br />
<br />
= Incident Report =<br />
<br />
The purpose of incident reporting is to help all of us work together to build a more<br />
secure web. Therefore, the incident report should share lessons learned that could be helpful to all CAs to build better systems. The incident report should explain how the systems failed, how was the mis-issuance or incident possible, and why the problem was not detected earlier. In addition to the timeline of responding to and resolving the incident, the incident report should explain how the CA's systems will be made more robust, and how other CAs may learn from the incident.<br />
<br />
Each incident should result in an incident report, written as soon as the problem is fully diagnosed and (temporary or permanent) measures have been put in place to make sure it will not re-occur. If the permanent fix is going to take significant time to implement, you should not wait until this is done before issuing the report. We expect to see incident reports as soon as possible, and certainly within two weeks of the initial issue report. While remediation work may still be ongoing, a satisfactory incident report will serve to resolve the issue from a Mozilla perspective. <br />
<br />
CAs should submit a separate incident report when:<br />
* Mozilla policy requires that the CA revoke one or more certificates by a certain deadline, such as those in BR section 4.9, but that deadline is not met by the CA.<br />
* In the process of researching one incident, another incident with a distinct root cause and/or remediation is discovered.<br />
* After an incident bug is marked resolved, the incident reoccurs.<br />
<br />
The incident report may well repeat things which have been said previously in discussions or bug comments. This is entirely expected. The report should be a summary of previous findings. The existence of data in discussions or bug comments does not excuse a CA from the task of compiling a proper incident report.<br />
<br />
Your CA may submit an incident report by [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other creating a bug in Bugzilla under the NSS:CA Certificate Compliance component], or by posting the report to the mozilla.dev.security.policy mailing list. If an incident report is sent to the list without a corresponding bug, a new one will be created to track the incident.<br />
<br />
The incident report should cover at least the following topics:<br />
<br />
# How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.<br />
# A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.<br />
# Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.<br />
# A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.<br />
# The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.<br />
# Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.<br />
# List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.<br />
<br />
= Keeping Us Informed =<br />
<br />
Once the report is posted, you should respond promptly to questions that are asked, and in no circumstances should a question linger without a response for more than one week, even if the response is only to acknowledge the question and provide a later date when an answer will be delivered. You should also provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless Mozilla representatives agree to a different schedule by setting a “Next Update” date in the “Whiteboard” field of the bug. Such updates should be posted to the m.d.s.p. thread, if there is one, and the Bugzilla bug. The bug will be closed when remediation is completed.<br />
<br />
= Examples of Good Practice =<br />
<br />
Here are some examples of good practice, where a CA did most or all of the things recommended above.<br />
<br />
== Let's Encrypt Unicode Normalization Compliance Incident ==<br />
<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g6_zGA2exXw Initial Public Problem Report], 2017-08-10 20:23 UTC (apparently LE were made aware of the problem privately earlier that day)<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/_tXldrbIBwAJ Initial Public Response from CA], 2017-08-10 21:53 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJY Final Report from CA], 2017-08-11 03:00 UTC<br />
<br />
In this case, the CA managed to diagnose the problem, remediate it, and deploy the fix to production within 24 hours.<br />
<br />
== PKIOverheid Short Serial Number Incident ==<br />
<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ Initial Public Problem Report], 2017-07-18 22:26 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/TzH5eI9dAQAJ Initial Public Response from CA], 2017-07-25 19:20 UTC<br />
* [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ Final Report from CA], 2017-08-11 14:39 UTC<br />
<br />
While the CA could have provided interim updates, and the final report was a little delayed, the contents of it were excellent.<br />
<br />
== SecureTrust "Some-State" in stateOrProvinceName ==<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374 Initial Public Problem Report], 2019-05-14 00:49 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c1 Initial Public Response from CA], 2017-05-15 19:40 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c8 Final Report from CA], 2017-06-14 9:43 UTC<br />
<br />
The level of detail provided by the CA in both the initial report and follow-up responses is comprehensive, as is the work performed to identify additional occurrences and to remediate the issue.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1221445Security/DOH-resolver-policy2019-12-17T18:32:33Z<p>Wthayer: Add Conforming Resolvers section</p>
<hr />
<div>== Mozilla Policy Requirements for DNS over HTTPs Partners ==<br />
<br />
This document describes the minimum set of policy requirements that a party must satisfy to be considered as a potential partner for Mozilla’s Trusted Recursive Resolver (TRR) program. It specifically describes data collection and retention, transparency, and blocking policies and is in addition to any contractual, technical or operational requirements necessary to operate the resolver service. <br />
<br />
==== Privacy Requirements ====<br />
<br />
Mozilla’s TRR is intended to provide better, minimum privacy guarantees to Firefox users than current, ad hoc provisioning of DNS services. As such, resolvers must strictly limit data collection and sharing from the resolver. More specifically:<br />
<br />
::1. The resolver may retain user data (including identifiable data, data associated with user IP addresses, and any non-aggregate anonymized data) but should do so only for the purpose of operating the service and must not retain that data for longer than 24 hours. <br />
:::* Only aggregate data that does not identify individual users or requests may be retained beyond 24 hours. <br />
::2. The resolver must not retain, sell, or transfer to any third party (except as may be required by law) any personal information, IP addresses or other user identifiers, or user query patterns from the DNS queries sent from the Firefox browser.<br /><br />
<br />
::3. The resolver must not combine the data that it collects from queries with any other data in any way that can be used to identify individual end users.<br /><br />
<br />
::4. The resolver must not sell, license, sublicense, or grant any rights to user data to any other person or entity.<br /><br />
<br />
::5. The resolver must support DNS Query Name Minimisation as defined in RFC 7816.<br /><br />
<br />
::6. The resolver must not propagate unnecessary information about queries to authoritative name servers. In particular, the client subnet DNS extension in RFC 7871 must not be sent to servers unless the connection to the authoritative server is encrypted and only to authoritative name servers operated by the domain owner directly or by a DNS provider pursuant to its contract with the domain owner.<br /><br />
<br />
==== Transparency Requirements ====<br />
<br />
The party operating the resolver must be transparent about any data collection and sharing that does occur in accordance with the above requirements. More specifically:<br />
<br />
::1. Privacy Notice. There must be a public privacy notice specifically for the resolver service that documents the specific fields for data that will be retained for 24 hours and that documents specific fields for aggregate data that will be retained beyond 24 hours. The notice should also attest to requirements 2 - 4 above. <br /><br />
<br />
::2. Transparency Report. There must be a transparency report published at least yearly that documents the policy for how the party operating the resolver will handle law enforcement requests for user data and that documents the types and number of requests received and answered, except to the extent such disclosure is prohibited by law.<br />
<br />
==== Blocking & Modification Prohibitions ==== <br />
<br />
::1. The party operating the resolver should not by default block or filter domains unless specifically required by law in the jurisdiction in which the resolver operates. Mozilla will generally seek to work with DNS resolvers that provide unfiltered DNS responses and, at its discretion, may remove from consideration resolvers subject to legal filtering obligations, depending on the scope and nature of those obligations. <br />
:::* Resolvers may block or filter content with the user’s explicit consent.<br />
::2. For any filtering that does occur under the above requirement, the party must maintain public documentation of all domains that are blocked and a log of when particular domains are added and removed from any blocklist.<br /><br />
<br />
::3. When a domain requested by the user is not present, the party operating the resolver should provide an accurate NXDOMAIN response and must not modify the response or provide inaccurate responses that direct the user to alternative content. <br />
<br />
== Enforcement ==<br />
The decision of who to include in (or remove from) Mozilla’s Trusted Recursive Resolver (TRR) program is at Mozilla’s sole discretion, and we may evaluate additional factors such as abusive practices or other security concerns not specifically identified here. We intend to publicly document violations of this Policy and take additional actions if necessary.<br />
<br />
== Conforming Resolvers ==<br />
The following providers have contractually agreed to abide by these policy requirements:<br />
<br />
{| class="wikitable"<br />
|Cloudflare || [https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/ Privacy policy] || https://mozilla.cloudflare-dns.com/dns-query<br />
|-<br />
|NextDNS || [https://nextdns.io/privacy Privacy policy] || https://dns.nextdns.io <br />
|}</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1221231CA/Incident Dashboard2019-12-11T23:40:21Z<p>Wthayer: /* Revocation Delays */ Clarifications</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 />
<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 />
"include_fields": ["id", "summary", "status", "assigned_to", "whiteboard", "last_change_time"]<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": ["id", "summary", "status", "assigned_to", "whiteboard", "last_change_time"]<br />
}<br />
</bugzilla><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>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Root_Store_Policy_Archive&diff=1221215CA/Root Store Policy Archive2019-12-11T15:27:05Z<p>Wthayer: /* 2.7 */ Update diff URL</p>
<hr />
<div>__NOTOC__<br />
==2.7==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.7/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: December 10, 2019<br />
* Effective (compliance) date: January 1, 2020, except:<br />
** April 1, 2020: CPs and CPSes published after this date MUST be structured according to RFC 3647 and MUST:<br />
*** Include at least every section and subsection defined in RFC 3647; and,<br />
*** Only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and,<br />
*** Contain no sections that are blank and have no subsections.<br />
** July 1, 2020: End-entity certificates MUST include an Extended Key Usage (EKU) extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.<br />
* [https://github.com/mozilla/pkipolicy/pull/199/files List of changes and diff]<br />
<br />
==2.6.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.6/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: August 13, 2018<br />
* Effective (compliance) date: August 13, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/commit/a8353e12db6128d9a01de7ab94949180115a2d92 List of changes and diff]<br />
<br />
==2.6==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/0fef6af7ea0455bd350c489c3d35be4ee2ce2567/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: June 29, 2018<br />
* Effective (compliance) date: July 1, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/pull/143/files List of changes and diff]<br />
<br />
==2.5==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.5/ccadb/policy.md Common CCADB Policy]<br />
* The "Mozilla CCADB Policy" document is now part of the main Policy<br />
* Publication date: June 23, 2017<br />
* Compliance date: June 23, 2017, except:<br />
** Technical constraints for email intermediates, which is ('''erratum''') November 15, 2017 for existing non-qualifying intermediates to cease issuing, and April 15 2018 for them to be revoked or audited<br />
** Using the Ten Blessed Methods for domain validation, which is July 21, 2017<br />
* [https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 List of changes and diff]<br />
<br />
==2.4.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: March 31, 2017<br />
* Compliance date: March 31, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* This version has no changes in normative requirements over version 2.4; it is a rearrangement and reordering of the existing policy.<br />
<br />
==2.4==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: February 28, 2017<br />
* Compliance date: February 28, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* [https://github.com/mozilla/pkipolicy/compare/2.3...2.4 List of changes and diff]<br />
<br />
==2.3==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md Policy document]<br />
* Publication date: December 19, 2016<br />
* Compliance date: December 19, 2016<br />
* [https://github.com/mozilla/pkipolicy/compare/2.2...2.3 List of changes and diff]<br />
<br />
==2.2==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.2/rootstore/policy.md Policy document]<br />
* Publication date: July 26, 2013<br />
* Compliance date: July 26, 2013 ([[CA:CertificatePolicyV2.2#Time_Frames_for_included_CAs_to_comply_with_version_2.2_of_the_policy|more specific details]])<br />
* List of changes: {{Bug|868144}}<br />
<br />
==2.1==<br />
<br />
* [[CA:CertPolicyV2.1|Policy document]]<br />
* Publication date: February 14, 2013<br />
* Compliance date: February 14, 2014 ([[CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy|more specific details]])<br />
* Items considered: [[CA:PolicyVersion2.1]]<br />
* List of changes: {{Bug|763758}}<br />
<br />
==2.0==<br />
<br />
* [[CA:CertificatePolicyV2.0|Policy document]]<br />
* Publication date: February 2, 2011<br />
* Compliance date: August 8, 2011 (Feb 2, 2011 for new root inclusions)<br />
* Items considered: [[CA:PolicyVersion2.0]]<br />
* List of changes: {{Bug|609945}}<br />
<br />
==Earlier==<br />
<br />
* [[CA:CertificatePolicyV1.2|Version 1.2]] -- January 2008<br />
* [[CA:CertificatePolicyV1.1|Version 1.1]] -- November 2007<br />
* [[CA:CertificatePolicyV1.0|Version 1.0]] -- November 2005<br />
* [[CA:CertificatePolicyV0.4|Version 0.4]] -- March 2004</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Root_Store_Policy_Archive&diff=1221214CA/Root Store Policy Archive2019-12-11T15:25:58Z<p>Wthayer: /* 2.7 */ Update diff link</p>
<hr />
<div>__NOTOC__<br />
==2.7==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.7/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: December 10, 2019<br />
* Effective (compliance) date: January 1, 2020, except:<br />
** April 1, 2020: CPs and CPSes published after this date MUST be structured according to RFC 3647 and MUST:<br />
*** Include at least every section and subsection defined in RFC 3647; and,<br />
*** Only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and,<br />
*** Contain no sections that are blank and have no subsections.<br />
** July 1, 2020: End-entity certificates MUST include an Extended Key Usage (EKU) extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.<br />
* [https://github.com/mozilla/pkipolicy/pull/199 List of changes and diff]<br />
<br />
==2.6.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.6/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: August 13, 2018<br />
* Effective (compliance) date: August 13, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/commit/a8353e12db6128d9a01de7ab94949180115a2d92 List of changes and diff]<br />
<br />
==2.6==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/0fef6af7ea0455bd350c489c3d35be4ee2ce2567/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: June 29, 2018<br />
* Effective (compliance) date: July 1, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/pull/143/files List of changes and diff]<br />
<br />
==2.5==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.5/ccadb/policy.md Common CCADB Policy]<br />
* The "Mozilla CCADB Policy" document is now part of the main Policy<br />
* Publication date: June 23, 2017<br />
* Compliance date: June 23, 2017, except:<br />
** Technical constraints for email intermediates, which is ('''erratum''') November 15, 2017 for existing non-qualifying intermediates to cease issuing, and April 15 2018 for them to be revoked or audited<br />
** Using the Ten Blessed Methods for domain validation, which is July 21, 2017<br />
* [https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 List of changes and diff]<br />
<br />
==2.4.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: March 31, 2017<br />
* Compliance date: March 31, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* This version has no changes in normative requirements over version 2.4; it is a rearrangement and reordering of the existing policy.<br />
<br />
==2.4==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: February 28, 2017<br />
* Compliance date: February 28, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* [https://github.com/mozilla/pkipolicy/compare/2.3...2.4 List of changes and diff]<br />
<br />
==2.3==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md Policy document]<br />
* Publication date: December 19, 2016<br />
* Compliance date: December 19, 2016<br />
* [https://github.com/mozilla/pkipolicy/compare/2.2...2.3 List of changes and diff]<br />
<br />
==2.2==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.2/rootstore/policy.md Policy document]<br />
* Publication date: July 26, 2013<br />
* Compliance date: July 26, 2013 ([[CA:CertificatePolicyV2.2#Time_Frames_for_included_CAs_to_comply_with_version_2.2_of_the_policy|more specific details]])<br />
* List of changes: {{Bug|868144}}<br />
<br />
==2.1==<br />
<br />
* [[CA:CertPolicyV2.1|Policy document]]<br />
* Publication date: February 14, 2013<br />
* Compliance date: February 14, 2014 ([[CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy|more specific details]])<br />
* Items considered: [[CA:PolicyVersion2.1]]<br />
* List of changes: {{Bug|763758}}<br />
<br />
==2.0==<br />
<br />
* [[CA:CertificatePolicyV2.0|Policy document]]<br />
* Publication date: February 2, 2011<br />
* Compliance date: August 8, 2011 (Feb 2, 2011 for new root inclusions)<br />
* Items considered: [[CA:PolicyVersion2.0]]<br />
* List of changes: {{Bug|609945}}<br />
<br />
==Earlier==<br />
<br />
* [[CA:CertificatePolicyV1.2|Version 1.2]] -- January 2008<br />
* [[CA:CertificatePolicyV1.1|Version 1.1]] -- November 2007<br />
* [[CA:CertificatePolicyV1.0|Version 1.0]] -- November 2005<br />
* [[CA:CertificatePolicyV0.4|Version 0.4]] -- March 2004</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Root_Store_Policy_Archive&diff=1221213CA/Root Store Policy Archive2019-12-11T15:22:27Z<p>Wthayer: Update 2.7 section</p>
<hr />
<div>__NOTOC__<br />
==2.7==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.7/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: December 10, 2019<br />
* Effective (compliance) date: January 1, 2020, except:<br />
** April 1, 2020: CPs and CPSes published after this date MUST be structured according to RFC 3647 and MUST:<br />
*** Include at least every section and subsection defined in RFC 3647; and,<br />
*** Only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and,<br />
*** Contain no sections that are blank and have no subsections.<br />
** July 1, 2020: End-entity certificates MUST include an Extended Key Usage (EKU) extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.<br />
* [https://github.com/mozilla/pkipolicy/compare/master@{12-09-19}...2.7 List of changes and diff]<br />
<br />
==2.6.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.6/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: August 13, 2018<br />
* Effective (compliance) date: August 13, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/commit/a8353e12db6128d9a01de7ab94949180115a2d92 List of changes and diff]<br />
<br />
==2.6==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/0fef6af7ea0455bd350c489c3d35be4ee2ce2567/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: June 29, 2018<br />
* Effective (compliance) date: July 1, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/pull/143/files List of changes and diff]<br />
<br />
==2.5==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.5/ccadb/policy.md Common CCADB Policy]<br />
* The "Mozilla CCADB Policy" document is now part of the main Policy<br />
* Publication date: June 23, 2017<br />
* Compliance date: June 23, 2017, except:<br />
** Technical constraints for email intermediates, which is ('''erratum''') November 15, 2017 for existing non-qualifying intermediates to cease issuing, and April 15 2018 for them to be revoked or audited<br />
** Using the Ten Blessed Methods for domain validation, which is July 21, 2017<br />
* [https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 List of changes and diff]<br />
<br />
==2.4.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: March 31, 2017<br />
* Compliance date: March 31, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* This version has no changes in normative requirements over version 2.4; it is a rearrangement and reordering of the existing policy.<br />
<br />
==2.4==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: February 28, 2017<br />
* Compliance date: February 28, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* [https://github.com/mozilla/pkipolicy/compare/2.3...2.4 List of changes and diff]<br />
<br />
==2.3==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md Policy document]<br />
* Publication date: December 19, 2016<br />
* Compliance date: December 19, 2016<br />
* [https://github.com/mozilla/pkipolicy/compare/2.2...2.3 List of changes and diff]<br />
<br />
==2.2==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.2/rootstore/policy.md Policy document]<br />
* Publication date: July 26, 2013<br />
* Compliance date: July 26, 2013 ([[CA:CertificatePolicyV2.2#Time_Frames_for_included_CAs_to_comply_with_version_2.2_of_the_policy|more specific details]])<br />
* List of changes: {{Bug|868144}}<br />
<br />
==2.1==<br />
<br />
* [[CA:CertPolicyV2.1|Policy document]]<br />
* Publication date: February 14, 2013<br />
* Compliance date: February 14, 2014 ([[CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy|more specific details]])<br />
* Items considered: [[CA:PolicyVersion2.1]]<br />
* List of changes: {{Bug|763758}}<br />
<br />
==2.0==<br />
<br />
* [[CA:CertificatePolicyV2.0|Policy document]]<br />
* Publication date: February 2, 2011<br />
* Compliance date: August 8, 2011 (Feb 2, 2011 for new root inclusions)<br />
* Items considered: [[CA:PolicyVersion2.0]]<br />
* List of changes: {{Bug|609945}}<br />
<br />
==Earlier==<br />
<br />
* [[CA:CertificatePolicyV1.2|Version 1.2]] -- January 2008<br />
* [[CA:CertificatePolicyV1.1|Version 1.1]] -- November 2007<br />
* [[CA:CertificatePolicyV1.0|Version 1.0]] -- November 2005<br />
* [[CA:CertificatePolicyV0.4|Version 0.4]] -- March 2004</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Root_Store_Policy_Archive&diff=1221196CA/Root Store Policy Archive2019-12-11T02:00:47Z<p>Wthayer: Update diff</p>
<hr />
<div>__NOTOC__<br />
==2.7==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.7/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: December 10, 2019<br />
* Effective (compliance) date: January 1, 2020, except:<br />
** April 1, 2020: CPs and CPSes MUST be structured according to RFC 3647 and MUST:<br />
* Include at least every section and subsection defined in RFC 3647; and,<br />
* Only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and,<br />
* Contain no sections that are blank and have no subsections.<br />
** July 1, 2020: End-entity certificates MUST include an Extended Key Usage (EKU) extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.<br />
* [https://github.com/mozilla/pkipolicy/compare/master@{12-09-19}...2.7 List of changes and diff]<br />
<br />
==2.6.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.6/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: August 13, 2018<br />
* Effective (compliance) date: August 13, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/commit/a8353e12db6128d9a01de7ab94949180115a2d92 List of changes and diff]<br />
<br />
==2.6==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/0fef6af7ea0455bd350c489c3d35be4ee2ce2567/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: June 29, 2018<br />
* Effective (compliance) date: July 1, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/pull/143/files List of changes and diff]<br />
<br />
==2.5==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.5/ccadb/policy.md Common CCADB Policy]<br />
* The "Mozilla CCADB Policy" document is now part of the main Policy<br />
* Publication date: June 23, 2017<br />
* Compliance date: June 23, 2017, except:<br />
** Technical constraints for email intermediates, which is ('''erratum''') November 15, 2017 for existing non-qualifying intermediates to cease issuing, and April 15 2018 for them to be revoked or audited<br />
** Using the Ten Blessed Methods for domain validation, which is July 21, 2017<br />
* [https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 List of changes and diff]<br />
<br />
==2.4.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: March 31, 2017<br />
* Compliance date: March 31, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* This version has no changes in normative requirements over version 2.4; it is a rearrangement and reordering of the existing policy.<br />
<br />
==2.4==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: February 28, 2017<br />
* Compliance date: February 28, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* [https://github.com/mozilla/pkipolicy/compare/2.3...2.4 List of changes and diff]<br />
<br />
==2.3==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md Policy document]<br />
* Publication date: December 19, 2016<br />
* Compliance date: December 19, 2016<br />
* [https://github.com/mozilla/pkipolicy/compare/2.2...2.3 List of changes and diff]<br />
<br />
==2.2==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.2/rootstore/policy.md Policy document]<br />
* Publication date: July 26, 2013<br />
* Compliance date: July 26, 2013 ([[CA:CertificatePolicyV2.2#Time_Frames_for_included_CAs_to_comply_with_version_2.2_of_the_policy|more specific details]])<br />
* List of changes: {{Bug|868144}}<br />
<br />
==2.1==<br />
<br />
* [[CA:CertPolicyV2.1|Policy document]]<br />
* Publication date: February 14, 2013<br />
* Compliance date: February 14, 2014 ([[CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy|more specific details]])<br />
* Items considered: [[CA:PolicyVersion2.1]]<br />
* List of changes: {{Bug|763758}}<br />
<br />
==2.0==<br />
<br />
* [[CA:CertificatePolicyV2.0|Policy document]]<br />
* Publication date: February 2, 2011<br />
* Compliance date: August 8, 2011 (Feb 2, 2011 for new root inclusions)<br />
* Items considered: [[CA:PolicyVersion2.0]]<br />
* List of changes: {{Bug|609945}}<br />
<br />
==Earlier==<br />
<br />
* [[CA:CertificatePolicyV1.2|Version 1.2]] -- January 2008<br />
* [[CA:CertificatePolicyV1.1|Version 1.1]] -- November 2007<br />
* [[CA:CertificatePolicyV1.0|Version 1.0]] -- November 2005<br />
* [[CA:CertificatePolicyV0.4|Version 0.4]] -- March 2004</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Root_Store_Policy_Archive&diff=1221195CA/Root Store Policy Archive2019-12-11T01:57:29Z<p>Wthayer: Add version 2.7</p>
<hr />
<div>__NOTOC__<br />
==2.7==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.7/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: December 10, 2019<br />
* Effective (compliance) date: January 1, 2020, except:<br />
** April 1, 2020: CPs and CPSes MUST be structured according to RFC 3647 and MUST:<br />
* Include at least every section and subsection defined in RFC 3647; and,<br />
* Only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and,<br />
* Contain no sections that are blank and have no subsections.<br />
** July 1, 2020: End-entity certificates MUST include an Extended Key Usage (EKU) extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.<br />
* [https://github.com/mozilla/pkipolicy/compare/master...2.7 List of changes and diff]<br />
<br />
==2.6.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.6/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: August 13, 2018<br />
* Effective (compliance) date: August 13, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/commit/a8353e12db6128d9a01de7ab94949180115a2d92 List of changes and diff]<br />
<br />
==2.6==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/0fef6af7ea0455bd350c489c3d35be4ee2ce2567/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy]<br />
* Publication date: June 29, 2018<br />
* Effective (compliance) date: July 1, 2018, except:<br />
** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3<br />
* [https://github.com/mozilla/pkipolicy/pull/143/files List of changes and diff]<br />
<br />
==2.5==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.5/ccadb/policy.md Common CCADB Policy]<br />
* The "Mozilla CCADB Policy" document is now part of the main Policy<br />
* Publication date: June 23, 2017<br />
* Compliance date: June 23, 2017, except:<br />
** Technical constraints for email intermediates, which is ('''erratum''') November 15, 2017 for existing non-qualifying intermediates to cease issuing, and April 15 2018 for them to be revoked or audited<br />
** Using the Ten Blessed Methods for domain validation, which is July 21, 2017<br />
* [https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 List of changes and diff]<br />
<br />
==2.4.1==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: March 31, 2017<br />
* Compliance date: March 31, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* This version has no changes in normative requirements over version 2.4; it is a rearrangement and reordering of the existing policy.<br />
<br />
==2.4==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.4/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/mozilla.md Mozilla CCADB Policy]<br />
* Publication date: February 28, 2017<br />
* Compliance date: February 28, 2017 (except "CP/CPS in English", which is June 1, 2017)<br />
* [https://github.com/mozilla/pkipolicy/compare/2.3...2.4 List of changes and diff]<br />
<br />
==2.3==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md Policy document]<br />
* Publication date: December 19, 2016<br />
* Compliance date: December 19, 2016<br />
* [https://github.com/mozilla/pkipolicy/compare/2.2...2.3 List of changes and diff]<br />
<br />
==2.2==<br />
<br />
* [https://github.com/mozilla/pkipolicy/blob/2.2/rootstore/policy.md Policy document]<br />
* Publication date: July 26, 2013<br />
* Compliance date: July 26, 2013 ([[CA:CertificatePolicyV2.2#Time_Frames_for_included_CAs_to_comply_with_version_2.2_of_the_policy|more specific details]])<br />
* List of changes: {{Bug|868144}}<br />
<br />
==2.1==<br />
<br />
* [[CA:CertPolicyV2.1|Policy document]]<br />
* Publication date: February 14, 2013<br />
* Compliance date: February 14, 2014 ([[CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy|more specific details]])<br />
* Items considered: [[CA:PolicyVersion2.1]]<br />
* List of changes: {{Bug|763758}}<br />
<br />
==2.0==<br />
<br />
* [[CA:CertificatePolicyV2.0|Policy document]]<br />
* Publication date: February 2, 2011<br />
* Compliance date: August 8, 2011 (Feb 2, 2011 for new root inclusions)<br />
* Items considered: [[CA:PolicyVersion2.0]]<br />
* List of changes: {{Bug|609945}}<br />
<br />
==Earlier==<br />
<br />
* [[CA:CertificatePolicyV1.2|Version 1.2]] -- January 2008<br />
* [[CA:CertificatePolicyV1.1|Version 1.1]] -- November 2007<br />
* [[CA:CertificatePolicyV1.0|Version 1.0]] -- November 2005<br />
* [[CA:CertificatePolicyV0.4|Version 0.4]] -- March 2004</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Required_or_Recommended_Practices&diff=1218575CA/Required or Recommended Practices2019-10-03T17:17:06Z<p>Wthayer: Move Precertificates to recommended</p>
<hr />
<div>This page contains a set of practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are required by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and so are mandatory for a CA to have its root certificate(s) included. They are listed here because they are things CAs often get wrong. In other cases the practices are only recommended, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.<br />
<br />
== Required Practices ==<br />
<br />
=== Publicly Available CP and CPS ===<br />
<br />
CAs must supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.<br />
<br />
* The CP/CPS must be publicly available from the CA's official web site.<br />
* The CP/CPS must clearly indicate which root and subordinate certificates the practices and processes described in those documents apply to.<br />
* The format of the CP/CPS document must be PDF or another suitable format for reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.<br />
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.<br />
* The CA must provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.<br />
<br />
===== CP/CPS Revision Table =====<br />
<br />
Section 3.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] states: "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document."<br />
<br />
===== CAA Domains listed in CP/CPS =====<br />
<br />
Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs] states: "CA's Certificate Policy and/or Certification Practice<br />
Statement ... '''shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA''' "issue" or<br />
"issuewild" records as permitting it to issue.<br />
<br />
===== BR Commitment to Comply statement in CP/CPS =====<br />
<br />
For root certificates with the Websites (TLS/SSL) trust bit enabled, Mozilla requires the corresponding CP/CPS documents to include a statement of commitment to comply with the CA/Browser Forum's Baseline Requirements, as per section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs.]<br />
<br />
===== CP/CPS Structured According to RFC 3647 =====<br />
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements, with the effective of 31 May 2018. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.<br />
* The words "''No Stipulation''" mean that the particular document imposes no requirements related to that section. <br />
** Note that Mozilla's root store policy may be updated soon to forbid the use of "No Stipulation" in CP/CPS documents. <br />
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred. <br />
* Sections should not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional.<br />
** Note that Mozilla's root store policy may be updated soon to forbid blank sections in CP/CPS documents. <br />
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. Cross-referencing between CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.<br />
* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to SSL certificates.<br />
<br />
Examples:<br />
* If your CA does not allow a particular domain validation method to be used, then the CP or CPS should say that, e.g. "This method of domain validation is not used".<br />
* If your CP delegates requirements to one or more CPSs, then the CP should state "Refer to CPS".<br />
* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for SSL certs, and then the other sections related to suspension should say “Not applicable”.<br />
* If your CA does not issue SSL certs containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed; e.g. “No IP address certificates are issued under this CPS.”<br />
* If your CP contains the full description of section 5, then the CPS may say "As stipulated in section 5 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)<br />
<br />
===== CP/CPS Documents will be Reviewed! =====<br />
<br />
During the [[CA/Application_Verification#Detailed_Review|Detailed Review]] phase, <br />
your CP/CPS documentation will be thoroughly reviewed and commented on. Concerns raised by the reviewer must be sufficiently resolved before the request will be allowed to enter [[CA/Application_Verification#Public_discussion|public discussion]]. <br />
<br />
Here are some examples of previous reviews of CP/CPS documents:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1474556#c16 Detailed Review Feedback on Dubai Government CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1448093#c56 Detailed Review Feedback on Microsoft CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1480510#c10 Detailed Review Feedback on Entrust CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]<br />
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]<br />
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.<br />
<br />
=== Audit Criteria ===<br />
<br />
CAs must supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.<br />
<br />
* The CA must indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).<br />
* All documents supplied as evidence must be publicly available.<br />
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).<br />
<br />
==== Complete Audit History ====<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#71-inclusions Mozilla's Root Store Policy] states: "Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements."<br />
<br />
This requirement may be met via one of the following options:<br />
* Providing the sequence of audit statements on the CA's website.<br />
* Attaching the sequence of audit statements to the root inclusion request (Bugzilla Bug).<br />
<br />
=== Revocation of Compromised Certificates ===<br />
<br />
CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.<br />
<br />
=== Verifying Domain Name Ownership ===<br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has registered all domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf. This must be done using one or more of the methods documented in section 3.2.2.4 of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with. CAs are not permitted to use 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address)."<br />
<br />
The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.<br />
<br />
===== Baseline Requirements =====<br />
<br />
It is '''not''' sufficient to simply reference section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements (BR)]. The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 3.2.2.4 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. Section 2.3 of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes '''in detail''' how the CA implements the latest version of these Requirements."<br />
<br />
'''Important:'''<br />
* The CPS should state what the CA actually does, not what it could do. Such as which of the allowed domain validation methods the CA uses.<br />
* BR subsections 3.2.2.4.1 and 3.2.2.4.5 were banned effective 1-August-2018.<br />
** "CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods"<br />
* BR subsection 3.2.2.4.9 was banned by ballot SC15, effective 16-March 2019.<br />
* BR subsection 3.2.2.4.10 contains major vulnerabilities. If the CA uses this method, then the CA should describe how they are mitigating those vulnerabilities. If not using this method, the CPS should say so.<br />
* BR section 3.2.2.5(4) was updated by ballot SC7 to remove "any other method", effective 1-August 2019. Prior to that date:<br />
** Saying the CA follows BR section 3.2.2.5 does not meet [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's disclosure requirements for this method]. The CPS must describe if/how "any other method" is implemented.<br />
** BR subsection 3.2.2.5(4) "any other method" is not permitted in conjunction with 3.2.2.4.8 per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's Root Store Policy]. The CPS should be clear that they do not do that.<br />
<br />
===== WHOIS =====<br />
<br />
[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking <br />
ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.<br />
<br />
It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?<br />
<br />
===== Email Challenge-Response =====<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. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]<br />
<br />
CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to cause and obtain certificates for example.com. Please work with your engineering department to ensure your systems properly handle such cases, as well as handling productions such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.<br />
<br />
=== Verifying Email Address Control === <br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."<br />
<br />
The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.<br />
<br />
The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.<br />
<br />
It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.<br />
<br />
=== DNS names go in SAN ===<br />
<br />
According to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements:]<br />
* Section 7.1.4.2.1 states:<br />
** Certificate Field: '''extensions:subjectAltName'''<br />
** Required/Optional: '''Required'''<br />
** Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.<br />
* Section 7.1.4.2.2 states:<br />
** Certificate Field: '''subject:commonName''' (OID 2.5.4.3)<br />
** Required/Optional: Deprecated ('''Discouraged''', but not prohibited)<br />
** Contents: If present, this field '''MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension''' (see Section 7.1.4.2.1).<br />
<br />
=== OCSP ===<br />
<br />
OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80. <br />
<br />
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements]:<br />
# The OCSP URI must be provided in the certificate, except when OCSP stapling is used. (sections 7.1.2.2, 7.1.2.3)<br />
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (section 4.9.10)<br />
# OCSP Responses shall be updated at least every four days and have a maximum expiration time of ten days (section 4.9.10)<br />
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (section 7.1.3)<br />
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (section 4.9.9)<br />
<br />
You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:<br />
* Go to Firefox -> Preferences... -> Privacy & Security -> Certificates<br />
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"<br />
* You may need to clear your history cache<br />
* Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.<br />
<br />
=== Network Security Controls ===<br />
<br />
CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.<br />
<br />
It is expected that CAs do the following on a regular basis:<br />
* Maintain network security controls that at minimum meet the [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements.]<br />
* Check for mis-issuance of certificates, especially for high-profile domains.<br />
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.<br />
* Ensure Intrusion Detection System and other monitoring software is up-to-date.<br />
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.<br />
<br />
== Recommended Practices ==<br />
<br />
=== CA Hierarchy ===<br />
<br />
A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See [[CA:Recommendations_for_Roots]].<br />
<br />
CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:<br />
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs<br />
* The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.<br />
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.<br />
<br />
We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).<br />
<br />
=== Document Handling of IDNs in CP/CPS ===<br />
<br />
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)<br />
<br />
=== Usage of Appropriate Constraints ===<br />
<br />
Root certificates in Mozilla's program can have either the SSL trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.<br />
<br />
=== Pre-Issuance Linting ===<br />
<br />
Recently, several tools have been developed ([https://github.com/awslabs/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.<br />
<br />
=== Precertificates ===<br />
<br />
The current implementation of [https://www.certificate-transparency.org/ Certificate Transparency] does not provide any way for Relying Parties to determine if a certificate corresponding to a given precertificate has or has not been issued. It is only safe to assume that a certificate corresponding to every precertificate exists.<br />
<br />
[https://tools.ietf.org/html/rfc6962 RFC 6962] states “The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate).”<br />
<br />
However, [https://cabforum.org/baseline-requirements-documents/ BR] section 7.1.2.5 states “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.”<br />
<br />
Mozilla [https://cabforum.org/pipermail/public/2014-January/002694.html interprets] the BR language as a specific exception allowing CAs to issue a precertificate containing the same serial number as the subsequent certificate. Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued.<br />
<br />
This means, for example, that:<br />
* A CA must provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a Precertificate, even if the certificate does not actually exist<br />
* A CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under Mozilla policy, even if the certificate does not actually exist.<br />
* If any corresponding certificate with the same serial number and issuer exists, and can not be verified to match the precertificate using the algorithms in RFC 6962, it will be considered misissued.<br />
* In examining historical issuance, the CA must consider both final certificates and precertificates, even if the precertificate did not ultimately result in the issuance of a certificate.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Policy_Participants&diff=1218478CA/Policy Participants2019-09-30T22:25:38Z<p>Wthayer: Add Curt Spann</p>
<hr />
<div>This is an optional list of the names, affiliations (if speaking for a company) and backgrounds of participants in the [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] group. If you participate in this group, feel free to add yourself or not; please do not add anyone other than yourself. If getting a wiki account seems like a hassle, email mhoye@mozilla.com with your info and he will add it.<br />
<br />
Please keep the list in alphabetical order by first character of name, as used in From: email header. Use "definition list" markup (; for your name, : for the description).<br />
<br />
; Alex Gaynor<br />
: Works for Mozilla; posting in a personal capacity with views not necessarily representing the views of Mozilla, unless otherwise noted.<br />
; Ben Laurie<br />
: Founder of the Certificate Transparency project; posting in a personal capacity except where otherwise indicated.<br />
; Curt Spann<br />
: Works for Apple; Posting in a personal capacity, with posts not necessarily representing the views of Apple, except where otherwise noted.<br />
; Devon O'Brien<br />
: Works for [https://www.google.com/ Google]; PKI policy for Chrome/ChromeOS; Posting in a personal capacity, with posts not necessarily representing the views of Google, except where otherwise noted.<br />
; Eric Mill<br />
: [https://www.techcongress.io/ TechCongress] fellow, currently supporting the U.S. Senate for 2019. Posting in a personal capacity and not representing TechCongress or the U.S. Senate.<br />
; Gijs Kruitbosch<br />
: Mozilla employee who works on Firefox frontend; Posting in a personal capacity except where otherwise indicated. Even when posting in official capacity, posts do not imply anything about the official position of the Mozilla CA Certificate Module (with which Gijs is not involved).<br />
; Ken Myers<br />
: Senior Manager with Protiviti and also supports the U.S. Federal PKI; Always posting in a personal capacity except where otherwise indicated.<br />
; Jason Milionis<br />
: University student on Electrical and Computer Engineering at the National Technical University of Athens; Firefox Student Ambassador; Posting in a personal capacity except where otherwise indicated.<br />
; Kathleen Wilson<br />
: Owner of the [[Modules/All#CA_Certificates|Mozilla CA Certificates Module]]; posting in an official capacity.<br />
; Kirk Hall <br />
: Works as Director Policy and Compliance - SSL for Entrust Datacard. I previously worked with Trend Micro and GeoTrust.<br />
; Nick Lamb<br />
: aka tialaramex; Employee of [https://www.kynd.io/ Kynd]; posting in a personal capacity.<br />
; Peter Bowen<br />
: Works for [https://aws.amazontrust.com/ Amazon Web Services]; posting in a personal capacity with posts not necessarily representing views of Amazon, except where otherwise indicated. <br />
; Robin Alden<br />
: Works for [https://sectigo.com/ Sectigo Ltd]/; posting in an official capacity except where otherwise indicated.<br />
; Rob Stradling<br />
: Works for [https://sectigo.com/ Sectigo Ltd]/; author of [https://crt.sh/ crt.sh]; posting in a personal capacity, with views not necessarily representing the views of Sectigo (unless otherwise noted).<br />
; Ryan Hurst<br />
: Works for [https://www.google.com/ Google]; Product Manager for Certificate Transparency and other PKI related projects. Posting in an official capacity except where otherwise indicated.<br />
; Ryan Sleevi<br />
: Peer of the [[Modules/All#CA_Certificates|CA Certificates Module]]; Works for [https://www.google.com/ Google]; PKI policy for Chrome/ChromeOS; Posting in a personal capacity, with posts not necessarily representing the views of Google or the Mozilla CA Certificate Module, except where otherwise noted.<br />
; Tim Smith<br />
: Product data science at Mozilla since April 2018. Not organizationally associated with the root program; posts in personal capacity.<br />
; Tom Ritter<br />
: Works at Mozilla but is not involved with the Mozilla CA Certificate Module, Firefox UI Frontend. Just cares about TLS, CAs, and CT. Not posting in an official capacity, unless otherwise noted (but probably never ever will.)<br />
; Wayne Thayer<br />
: Works at Mozilla as a CA Program Manager; posting in an official capacity except where otherwise indicated.<br />
<br />
<!-- Don't add your name down here - alphabetical order! Read the instructions :-) --></div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Required_or_Recommended_Practices&diff=1218035CA/Required or Recommended Practices2019-09-19T00:40:09Z<p>Wthayer: /* Precertificates */ add link to BR discussion</p>
<hr />
<div>This page contains a set of practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are required by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and so are mandatory for a CA to have its root certificate(s) included. They are listed here because they are things CAs often get wrong. In other cases the practices are only recommended, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.<br />
<br />
== Required Practices ==<br />
<br />
=== Publicly Available CP and CPS ===<br />
<br />
CAs must supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.<br />
<br />
* The CP/CPS must be publicly available from the CA's official web site.<br />
* The CP/CPS must clearly indicate which root and subordinate certificates the practices and processes described in those documents apply to.<br />
* The format of the CP/CPS document must be PDF or another suitable format for reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.<br />
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.<br />
* The CA must provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.<br />
<br />
===== CP/CPS Revision Table =====<br />
<br />
Section 3.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] states: "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document."<br />
<br />
===== CAA Domains listed in CP/CPS =====<br />
<br />
Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs] states: "CA's Certificate Policy and/or Certification Practice<br />
Statement ... '''shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA''' "issue" or<br />
"issuewild" records as permitting it to issue.<br />
<br />
===== BR Commitment to Comply statement in CP/CPS =====<br />
<br />
For root certificates with the Websites (TLS/SSL) trust bit enabled, Mozilla requires the corresponding CP/CPS documents to include a statement of commitment to comply with the CA/Browser Forum's Baseline Requirements, as per section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs.]<br />
<br />
===== CP/CPS Structured According to RFC 3647 =====<br />
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements, with the effective of 31 May 2018. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.<br />
* The words "''No Stipulation''" mean that the particular document imposes no requirements related to that section. <br />
** Note that Mozilla's root store policy may be updated soon to forbid the use of "No Stipulation" in CP/CPS documents. <br />
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred. <br />
* Sections should not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional.<br />
** Note that Mozilla's root store policy may be updated soon to forbid blank sections in CP/CPS documents. <br />
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. Cross-referencing between CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.<br />
* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to SSL certificates.<br />
<br />
Examples:<br />
* If your CA does not allow a particular domain validation method to be used, then the CP or CPS should say that, e.g. "This method of domain validation is not used".<br />
* If your CP delegates requirements to one or more CPSs, then the CP should state "Refer to CPS".<br />
* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for SSL certs, and then the other sections related to suspension should say “Not applicable”.<br />
* If your CA does not issue SSL certs containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed; e.g. “No IP address certificates are issued under this CPS.”<br />
* If your CP contains the full description of section 5, then the CPS may say "As stipulated in section 5 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)<br />
<br />
===== CP/CPS Documents will be Reviewed! =====<br />
<br />
During the [[CA/Application_Verification#Detailed_Review|Detailed Review]] phase, <br />
your CP/CPS documentation will be thoroughly reviewed and commented on. Concerns raised by the reviewer must be sufficiently resolved before the request will be allowed to enter [[CA/Application_Verification#Public_discussion|public discussion]]. <br />
<br />
Here are some examples of previous reviews of CP/CPS documents:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1474556#c16 Detailed Review Feedback on Dubai Government CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1448093#c56 Detailed Review Feedback on Microsoft CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1480510#c10 Detailed Review Feedback on Entrust CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]<br />
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]<br />
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.<br />
<br />
=== Audit Criteria ===<br />
<br />
CAs must supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.<br />
<br />
* The CA must indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).<br />
* All documents supplied as evidence must be publicly available.<br />
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).<br />
<br />
==== Complete Audit History ====<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#71-inclusions Mozilla's Root Store Policy] states: "Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements."<br />
<br />
This requirement may be met via one of the following options:<br />
* Providing the sequence of audit statements on the CA's website.<br />
* Attaching the sequence of audit statements to the root inclusion request (Bugzilla Bug).<br />
<br />
=== Revocation of Compromised Certificates ===<br />
<br />
CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.<br />
<br />
=== Verifying Domain Name Ownership ===<br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has registered all domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf. This must be done using one or more of the methods documented in section 3.2.2.4 of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with. CAs are not permitted to use 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address)."<br />
<br />
The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.<br />
<br />
===== Baseline Requirements =====<br />
<br />
It is '''not''' sufficient to simply reference section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements (BR)]. The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 3.2.2.4 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. Section 2.3 of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes '''in detail''' how the CA implements the latest version of these Requirements."<br />
<br />
'''Important:'''<br />
* The CPS should state what the CA actually does, not what it could do. Such as which of the allowed domain validation methods the CA uses.<br />
* BR subsections 3.2.2.4.1 and 3.2.2.4.5 were banned effective 1-August-2018.<br />
** "CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods"<br />
* BR subsection 3.2.2.4.9 was banned by ballot SC15, effective 16-March 2019.<br />
* BR subsection 3.2.2.4.10 contains major vulnerabilities. If the CA uses this method, then the CA should describe how they are mitigating those vulnerabilities. If not using this method, the CPS should say so.<br />
* BR section 3.2.2.5(4) was updated by ballot SC7 to remove "any other method", effective 1-August 2019. Prior to that date:<br />
** Saying the CA follows BR section 3.2.2.5 does not meet [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's disclosure requirements for this method]. The CPS must describe if/how "any other method" is implemented.<br />
** BR subsection 3.2.2.5(4) "any other method" is not permitted in conjunction with 3.2.2.4.8 per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's Root Store Policy]. The CPS should be clear that they do not do that.<br />
<br />
===== WHOIS =====<br />
<br />
[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking <br />
ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.<br />
<br />
It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?<br />
<br />
===== Email Challenge-Response =====<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. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]<br />
<br />
CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to cause and obtain certificates for example.com. Please work with your engineering department to ensure your systems properly handle such cases, as well as handling productions such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.<br />
<br />
=== Verifying Email Address Control === <br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."<br />
<br />
The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.<br />
<br />
The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.<br />
<br />
It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.<br />
<br />
=== DNS names go in SAN ===<br />
<br />
According to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements:]<br />
* Section 7.1.4.2.1 states:<br />
** Certificate Field: '''extensions:subjectAltName'''<br />
** Required/Optional: '''Required'''<br />
** Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.<br />
* Section 7.1.4.2.2 states:<br />
** Certificate Field: '''subject:commonName''' (OID 2.5.4.3)<br />
** Required/Optional: Deprecated ('''Discouraged''', but not prohibited)<br />
** Contents: If present, this field '''MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension''' (see Section 7.1.4.2.1).<br />
<br />
=== OCSP ===<br />
<br />
OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80. <br />
<br />
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements]:<br />
# The OCSP URI must be provided in the certificate, except when OCSP stapling is used. (sections 7.1.2.2, 7.1.2.3)<br />
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (section 4.9.10)<br />
# OCSP Responses shall be updated at least every four days and have a maximum expiration time of ten days (section 4.9.10)<br />
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (section 7.1.3)<br />
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (section 4.9.9)<br />
<br />
You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:<br />
* Go to Firefox -> Preferences... -> Privacy & Security -> Certificates<br />
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"<br />
* You may need to clear your history cache<br />
* Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.<br />
<br />
=== Network Security Controls ===<br />
<br />
CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.<br />
<br />
It is expected that CAs do the following on a regular basis:<br />
* Maintain network security controls that at minimum meet the [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements.]<br />
* Check for mis-issuance of certificates, especially for high-profile domains.<br />
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.<br />
* Ensure Intrusion Detection System and other monitoring software is up-to-date.<br />
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.<br />
<br />
=== Precertificates ===<br />
<br />
The current implementation of [https://www.certificate-transparency.org/ Certificate Transparency] does not provide any way for Relying Parties to determine if a certificate corresponding to a given precertificate has or has not been issued. It is only safe to assume that a certificate corresponding to every precertificate exists.<br />
<br />
[https://tools.ietf.org/html/rfc6962 RFC 6962] states “The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate).”<br />
<br />
However, [https://cabforum.org/baseline-requirements-documents/ BR] section 7.1.2.5 states “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.”<br />
<br />
Mozilla [https://cabforum.org/pipermail/public/2014-January/002694.html interprets] the BR language as a specific exception allowing CAs to issue a precertificate containing the same serial number as the subsequent certificate. Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued.<br />
<br />
This means, for example, that:<br />
* A CA must provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a Precertificate, even if the certificate does not actually exist<br />
* A CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under Mozilla policy, even if the certificate does not actually exist.<br />
* If any corresponding certificate with the same serial number and issuer exists, and can not be verified to match the precertificate using the algorithms in RFC 6962, it will be considered misissued.<br />
* In examining historical issuance, the CA must consider both final certificates and precertificates, even if the precertificate did not ultimately result in the issuance of a certificate.<br />
<br />
== Recommended Practices ==<br />
<br />
=== CA Hierarchy ===<br />
<br />
A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See [[CA:Recommendations_for_Roots]].<br />
<br />
CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:<br />
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs<br />
* The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.<br />
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.<br />
<br />
We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).<br />
<br />
=== Document Handling of IDNs in CP/CPS ===<br />
<br />
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)<br />
<br />
=== Usage of Appropriate Constraints ===<br />
<br />
Root certificates in Mozilla's program can have either the SSL trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.<br />
<br />
=== Pre-Issuance Linting ===<br />
<br />
Recently, several tools have been developed ([https://github.com/awslabs/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Required_or_Recommended_Practices&diff=1218034CA/Required or Recommended Practices2019-09-19T00:35:55Z<p>Wthayer: Add required practices section on precertificates</p>
<hr />
<div>This page contains a set of practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are required by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and so are mandatory for a CA to have its root certificate(s) included. They are listed here because they are things CAs often get wrong. In other cases the practices are only recommended, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.<br />
<br />
== Required Practices ==<br />
<br />
=== Publicly Available CP and CPS ===<br />
<br />
CAs must supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.<br />
<br />
* The CP/CPS must be publicly available from the CA's official web site.<br />
* The CP/CPS must clearly indicate which root and subordinate certificates the practices and processes described in those documents apply to.<br />
* The format of the CP/CPS document must be PDF or another suitable format for reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.<br />
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.<br />
* The CA must provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.<br />
<br />
===== CP/CPS Revision Table =====<br />
<br />
Section 3.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] states: "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document."<br />
<br />
===== CAA Domains listed in CP/CPS =====<br />
<br />
Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs] states: "CA's Certificate Policy and/or Certification Practice<br />
Statement ... '''shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA''' "issue" or<br />
"issuewild" records as permitting it to issue.<br />
<br />
===== BR Commitment to Comply statement in CP/CPS =====<br />
<br />
For root certificates with the Websites (TLS/SSL) trust bit enabled, Mozilla requires the corresponding CP/CPS documents to include a statement of commitment to comply with the CA/Browser Forum's Baseline Requirements, as per section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs.]<br />
<br />
===== CP/CPS Structured According to RFC 3647 =====<br />
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements, with the effective of 31 May 2018. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.<br />
* The words "''No Stipulation''" mean that the particular document imposes no requirements related to that section. <br />
** Note that Mozilla's root store policy may be updated soon to forbid the use of "No Stipulation" in CP/CPS documents. <br />
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred. <br />
* Sections should not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional.<br />
** Note that Mozilla's root store policy may be updated soon to forbid blank sections in CP/CPS documents. <br />
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. Cross-referencing between CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.<br />
* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to SSL certificates.<br />
<br />
Examples:<br />
* If your CA does not allow a particular domain validation method to be used, then the CP or CPS should say that, e.g. "This method of domain validation is not used".<br />
* If your CP delegates requirements to one or more CPSs, then the CP should state "Refer to CPS".<br />
* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for SSL certs, and then the other sections related to suspension should say “Not applicable”.<br />
* If your CA does not issue SSL certs containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed; e.g. “No IP address certificates are issued under this CPS.”<br />
* If your CP contains the full description of section 5, then the CPS may say "As stipulated in section 5 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)<br />
<br />
===== CP/CPS Documents will be Reviewed! =====<br />
<br />
During the [[CA/Application_Verification#Detailed_Review|Detailed Review]] phase, <br />
your CP/CPS documentation will be thoroughly reviewed and commented on. Concerns raised by the reviewer must be sufficiently resolved before the request will be allowed to enter [[CA/Application_Verification#Public_discussion|public discussion]]. <br />
<br />
Here are some examples of previous reviews of CP/CPS documents:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1474556#c16 Detailed Review Feedback on Dubai Government CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1448093#c56 Detailed Review Feedback on Microsoft CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1480510#c10 Detailed Review Feedback on Entrust CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]<br />
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]<br />
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.<br />
<br />
=== Audit Criteria ===<br />
<br />
CAs must supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.<br />
<br />
* The CA must indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).<br />
* All documents supplied as evidence must be publicly available.<br />
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).<br />
<br />
==== Complete Audit History ====<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#71-inclusions Mozilla's Root Store Policy] states: "Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements."<br />
<br />
This requirement may be met via one of the following options:<br />
* Providing the sequence of audit statements on the CA's website.<br />
* Attaching the sequence of audit statements to the root inclusion request (Bugzilla Bug).<br />
<br />
=== Revocation of Compromised Certificates ===<br />
<br />
CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.<br />
<br />
=== Verifying Domain Name Ownership ===<br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has registered all domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf. This must be done using one or more of the methods documented in section 3.2.2.4 of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with. CAs are not permitted to use 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address)."<br />
<br />
The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.<br />
<br />
===== Baseline Requirements =====<br />
<br />
It is '''not''' sufficient to simply reference section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements (BR)]. The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 3.2.2.4 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. Section 2.3 of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes '''in detail''' how the CA implements the latest version of these Requirements."<br />
<br />
'''Important:'''<br />
* The CPS should state what the CA actually does, not what it could do. Such as which of the allowed domain validation methods the CA uses.<br />
* BR subsections 3.2.2.4.1 and 3.2.2.4.5 were banned effective 1-August-2018.<br />
** "CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods"<br />
* BR subsection 3.2.2.4.9 was banned by ballot SC15, effective 16-March 2019.<br />
* BR subsection 3.2.2.4.10 contains major vulnerabilities. If the CA uses this method, then the CA should describe how they are mitigating those vulnerabilities. If not using this method, the CPS should say so.<br />
* BR section 3.2.2.5(4) was updated by ballot SC7 to remove "any other method", effective 1-August 2019. Prior to that date:<br />
** Saying the CA follows BR section 3.2.2.5 does not meet [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's disclosure requirements for this method]. The CPS must describe if/how "any other method" is implemented.<br />
** BR subsection 3.2.2.5(4) "any other method" is not permitted in conjunction with 3.2.2.4.8 per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's Root Store Policy]. The CPS should be clear that they do not do that.<br />
<br />
===== WHOIS =====<br />
<br />
[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking <br />
ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.<br />
<br />
It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?<br />
<br />
===== Email Challenge-Response =====<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. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]<br />
<br />
CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to cause and obtain certificates for example.com. Please work with your engineering department to ensure your systems properly handle such cases, as well as handling productions such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.<br />
<br />
=== Verifying Email Address Control === <br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."<br />
<br />
The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.<br />
<br />
The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.<br />
<br />
It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.<br />
<br />
=== DNS names go in SAN ===<br />
<br />
According to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements:]<br />
* Section 7.1.4.2.1 states:<br />
** Certificate Field: '''extensions:subjectAltName'''<br />
** Required/Optional: '''Required'''<br />
** Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.<br />
* Section 7.1.4.2.2 states:<br />
** Certificate Field: '''subject:commonName''' (OID 2.5.4.3)<br />
** Required/Optional: Deprecated ('''Discouraged''', but not prohibited)<br />
** Contents: If present, this field '''MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension''' (see Section 7.1.4.2.1).<br />
<br />
=== OCSP ===<br />
<br />
OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80. <br />
<br />
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements]:<br />
# The OCSP URI must be provided in the certificate, except when OCSP stapling is used. (sections 7.1.2.2, 7.1.2.3)<br />
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (section 4.9.10)<br />
# OCSP Responses shall be updated at least every four days and have a maximum expiration time of ten days (section 4.9.10)<br />
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (section 7.1.3)<br />
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (section 4.9.9)<br />
<br />
You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:<br />
* Go to Firefox -> Preferences... -> Privacy & Security -> Certificates<br />
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"<br />
* You may need to clear your history cache<br />
* Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.<br />
<br />
=== Network Security Controls ===<br />
<br />
CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.<br />
<br />
It is expected that CAs do the following on a regular basis:<br />
* Maintain network security controls that at minimum meet the [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements.]<br />
* Check for mis-issuance of certificates, especially for high-profile domains.<br />
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.<br />
* Ensure Intrusion Detection System and other monitoring software is up-to-date.<br />
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.<br />
<br />
=== Precertificates ===<br />
<br />
The current implementation of [https://www.certificate-transparency.org/ Certificate Transparency] does not provide any way for Relying Parties to determine if a certificate corresponding to a given precertificate has or has not been issued. It is only safe to assume that a certificate corresponding to every precertificate exists.<br />
<br />
[https://tools.ietf.org/html/rfc6962 RFC 6962] states “The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate).”<br />
<br />
However, [https://cabforum.org/baseline-requirements-documents/ BR] section 7.1.2.5 states “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.”<br />
<br />
Mozilla interprets the BR language as a specific exception allowing CAs to issue a precertificate containing the same serial number as the subsequent certificate [1]. Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued.<br />
<br />
This means, for example, that:<br />
* A CA must provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a Precertificate, even if the certificate does not actually exist<br />
* A CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under Mozilla policy, even if the certificate does not actually exist.<br />
* If any corresponding certificate with the same serial number and issuer exists, and can not be verified to match the precertificate using the algorithms in RFC 6962, it will be considered misissued.<br />
* In examining historical issuance, the CA must consider both final certificates and precertificates, even if the precertificate did not ultimately result in the issuance of a certificate.<br />
<br />
== Recommended Practices ==<br />
<br />
=== CA Hierarchy ===<br />
<br />
A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See [[CA:Recommendations_for_Roots]].<br />
<br />
CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:<br />
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs<br />
* The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.<br />
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.<br />
<br />
We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).<br />
<br />
=== Document Handling of IDNs in CP/CPS ===<br />
<br />
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)<br />
<br />
=== Usage of Appropriate Constraints ===<br />
<br />
Root certificates in Mozilla's program can have either the SSL trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.<br />
<br />
=== Pre-Issuance Linting ===<br />
<br />
Recently, several tools have been developed ([https://github.com/awslabs/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident&diff=1215546CA/Responding To An Incident2019-07-24T17:52:45Z<p>Wthayer: /* Examples of Good Practice */ Add SecureTrust example</p>
<hr />
<div>The page gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. <br />
<br />
For the purposes of this page, a "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. Researchers who report CA incidents such as misissuances are welcome to include a link to this page in their report to the CA, reminding the CA that Mozilla has the following expectations. This document is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained therein.<br />
<br />
Other examples of incidents include misconfigured OCSP responders, un-revocations, and any other event affecting trust in the WebPKI which does not involve the actual contents of certificates.<br />
<br />
While some forms of incident may be seen as less serious than others, opinions vary on which these are. Mozilla sees all incidents as good opportunities for the CA to test that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity.<br />
<br />
To be clear on the status of this document: this is a best practices document, not an official policy, and does not use normative language. Therefore, failure to follow one or more of the recommendations here is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response. <br />
<br />
= Immediate Actions =<br />
<br />
In misussuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI until you have diagnosed the source of the problem, or explain why this has not been done.<br />
<br />
Once the problem is diagnosed, you may restart issuance even if a full fix is not rolled out, if you are able to put in place temporary or manual procedures to prevent the problem from re-occurring. You should not restart issuance until you are confident that the problem will not re-occur.<br />
<br />
= Revocation =<br />
<br />
It is normal practice for CAs to revoke misissued certificates. But that leaves the question about '''when''' this should be done, particularly if it's not possible to contact the customer immediately, or if they are unable to replace their certificate quickly. Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements currently states (version 1.6.3):<br />
<br />
<blockquote><br />
“The CA SHOULD revoke a Certificate within 24 hours and MUST revoke a Certificate with 5 days if one or more of the following occurs: …<br><br />
7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;<br><br />
8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; …<br><br />
10. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or<br><br />
11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the Private Key was flawed."<br />
</blockquote><br />
<br />
This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 5 days.<br />
<br />
Mozilla recognizes that in some '''exceptional''' circumstances, revoking misissued certificates within the prescribed deadline may cause significant harm, such as when the certificate is used in critical infrastructure and cannot be safely replaced prior to the revocation deadline, or when the volume of revocations in a short period of time would result in a large cumulative impact to the web. However, Mozilla does not grant exceptions to the BR revocation requirements. It is our position that your CA is ultimately responsible for deciding if the harm caused by following the requirements of BR section 4.9.1 outweighs the risks that are passed on to individuals who rely on the web PKI by choosing not to meet this requirement.<br />
<br />
If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that:<br />
<br />
* The decision and rationale for delaying revocation will be disclosed to Mozilla in the form of a preliminary incident report immediately; preferably before the BR mandated revocation deadline. The rationale must include an explanation for why the situation is exceptional. Responses similar to “we deem this misissuance not to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.<br />
* Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a clear timeline describing if and when the problematic certificates will be revoked or expire naturally, and supported by the rationale to delay revocation.<br />
* The issue will need to be listed as a finding in your CA’s next BR audit statement.<br />
* Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.<br />
* That you will perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays.<br />
<br />
If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.<br />
<br />
= Follow-Up Actions =<br />
<br />
* Work out how the bug or problem was introduced. For a code bug, were the code review processes sufficient? Does your code have automated tests, and if so, why did they not catch this case?<br />
<br />
* Work out why the problem was not detected earlier. Were these certificates missed by your self-audits? Or is the code or process you use for such audits insufficiently frequent or rigorous?<br />
<br />
* If the problem is lack of compliance to an RFC, Baseline Requirement or Mozilla Policy requirement: were you aware of this requirement? If not, why not? If so, was an attempt made to meet it? If not, why not? If so, why was that attempt flawed? Do any processes need updating for making sure your CA complies with the latest version of the various requirements placed upon it?<br />
<br />
* Scan your corpus of certificates to look for others with the same issue. It does not look good for a CA to claim they have revoked all affected certificates and resolved the issue, and then for a researcher to discover another set of certificates with the same or a similar problem.<br />
<br />
* Examine whether there are potential related problems which you can also remediate at the same time. For example, if the problem was bad data in a particular field, consider improving the validation of all fields in the certificate prior to issuance. You should be proactively looking for [https://crt.sh/linttbscert ways] to harden your issuance pipeline against further problems.<br />
<br />
* If, as happens in a regrettably large number of cases, a problem report was sent to your CA but action in accordance with BR section 9.4.5 was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate.<br />
<br />
= Incident Report =<br />
<br />
The purpose of incident reporting is to help all of us work together to build a more<br />
secure web. Therefore, the incident report should share lessons learned that could be helpful to all CAs to build better systems. The incident report should explain how the systems failed, how was the mis-issuance or incident possible, and why the problem was not detected earlier. In addition to the timeline of responding to and resolving the incident, the incident report should explain how the CA's systems will be made more robust, and how other CAs may learn from the incident.<br />
<br />
Each incident should result in an incident report, written as soon as the problem is fully diagnosed and (temporary or permanent) measures have been put in place to make sure it will not re-occur. If the permanent fix is going to take significant time to implement, you should not wait until this is done before issuing the report. We expect to see incident reports as soon as possible, and certainly within two weeks of the initial issue report. While remediation work may still be ongoing, a satisfactory incident report will serve to resolve the issue from a Mozilla perspective. <br />
<br />
The incident report may well repeat things which have been said previously in discussions or bug comments. This is entirely expected. The report should be a summary of previous findings. The existence of data in discussions or bug comments does not excuse a CA from the task of compiling a proper incident report.<br />
<br />
Your CA may submit an incident report by creating a bug in Bugzilla under the NSS:CA Certificate Compliance component, or by posting the report to the mozilla.dev.security.policy mailing list. If an incident report is sent to the list without a corresponding bug, a new one will be created to track the incident.<br />
<br />
The incident report should cover at least the following topics:<br />
<br />
# How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.<br />
# A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.<br />
# Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.<br />
# A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.<br />
# The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.<br />
# Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.<br />
# List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.<br />
<br />
= Keeping Us Informed =<br />
<br />
Once the report is posted, you should respond promptly to questions that are asked, and in no circumstances should a question linger without a response for more than one week, even if the response is only to acknowledge the question and provide a later date when an answer will be delivered. You should also provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless Mozilla representatives agree to a different schedule by setting a “Next Update” date in the “Whiteboard” field of the bug. Such updates should be posted to the m.d.s.p. thread, if there is one, and the Bugzilla bug. The bug will be closed when remediation is completed.<br />
<br />
= Examples of Good Practice =<br />
<br />
Here are some examples of good practice, where a CA did most or all of the things recommended above.<br />
<br />
== Let's Encrypt Unicode Normalization Compliance Incident ==<br />
<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g6_zGA2exXw Initial Public Problem Report], 2017-08-10 20:23 UTC (apparently LE were made aware of the problem privately earlier that day)<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/_tXldrbIBwAJ Initial Public Response from CA], 2017-08-10 21:53 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJY Final Report from CA], 2017-08-11 03:00 UTC<br />
<br />
In this case, the CA managed to diagnose the problem, remediate it, and deploy the fix to production within 24 hours.<br />
<br />
== PKIOverheid Short Serial Number Incident ==<br />
<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ Initial Public Problem Report], 2017-07-18 22:26 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/TzH5eI9dAQAJ Initial Public Response from CA], 2017-07-25 19:20 UTC<br />
* [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ Final Report from CA], 2017-08-11 14:39 UTC<br />
<br />
While the CA could have provided interim updates, and the final report was a little delayed, the contents of it were excellent.<br />
<br />
== SecureTrust "Some-State" in stateOrProvinceName ==<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374 Initial Public Problem Report], 2019-05-14 00:49 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c1 Initial Public Response from CA], 2017-05-15 19:40 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c8 Final Report from CA], 2017-06-14 9:43 UTC<br />
<br />
The level of detail provided by the CA in both the initial report and follow-up responses is comprehensive, as is the work performed to identify additional occurrences and to remediate the issue.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1212122CA/Certinomis Issues2019-05-10T04:38:18Z<p>Wthayer: /* Issue A: StartCom Cross-signing (2017) */ old --> new</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
[UPDATE 9-May in reply to the [[CA/Certinomis_Issues#Certinomis_Response|Certinomis Response]]]<br />
<br />
Certinomis asked Mozilla to approve their plan to help Startcom, but when the cross-certificates were discovered, [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/lyAX9Wz_AQAJ Gerv responded] "This seems to be very different to the plan you implemented." By cross-signing Startcom's new roots, Certinomis assisted Startcom in circumventing the remediation plan, and by proposing one plan then implementing a different one, Certinomis did so without Mozilla's consent.<br />
<br />
Startcom misissued a number of certificates ([https://crt.sh/?opt=cablint&id=160150786 example]) under that cross-signing relationship that Certinomis is responsible for as the Mozilla program member.<br />
<br />
By cross-signing Startcom's roots, Certinomis also took responsibility for Startcom's qualified audit.<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
<br />
[CERTINOMIS RESPONSE] On 6-May, 2019, Certinomis stated that pre issuance linting is now operational.<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.<br />
<br />
=== <s>Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline</s> ===<br />
The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious [https://cabforum.org/pipermail/public/2017-December/012630.html vulnerabilities that were identified]. This concern was communicated in Mozilla's [[CA/Communications#January_2018_CA_Communication|January 2018 and September 2018 CA Communications]]. In a [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 bug that was recently filed describing the issuance of a certificate containing an unregistered domain name], Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c9 Certinomis stated that BR method 3.2.2.4.5 was still in use].<br />
<br />
<br />
[CERTINOMIS RESPONSE] [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c12 Certinomis confirmed] that the following [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11 comment form a former employee], is correct:<br />
<br />
''I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).''<br />
<br />
''For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).''<br />
<br />
''Theses two validation methods were manual ones so subject to human errors.''<br />
''Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.''<br />
<br />
''This new automated validation feature were to be available by the end of 2018.''<br />
<br />
''I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).''<br />
<br />
Certinomis later provided a [https://bugzilla.mozilla.org/show_bug.cgi?id=1547072#c6 detailed description] of their domain validation processes.<br />
<br />
=== Certinomis Response ===<br />
The following response to all of the issues listed herein was posted to the mozilla.dev.security.policy discussion list on 9-April:<br />
<br />
Dear All,<br />
<br />
Before detailing my answer, I would like to refute opinions that Certinomis does not take these subjects seriously: since February the management of Certinomis was directly involved in the exchanges with the Mozilla community, decisions were made and are implemented.<br />
<br />
I acknowledge that I was surprised by the multiple topics that were grouped by Wayne THAYER on the CA/Certinomis issues page. I would also like to thank Wayne THAYER for his analysis of a technical point of view that distinguished different categories of problems.<br />
<br />
For my part, my role is above all to advance the practice of Certinomis, and for this I must classify the problems according to their cause, because the best way to solve a problem is to correct its cause. And I will allow myself to structure my answer according to this classification that I made of problems, reserving for the end the Issue A (Startcom Signing) that I really did not expect to hear about.<br />
<br />
- First cause of problems: An organization of the technical direction not adapted to the plan of charge in 2018<br />
<br />
In 2018, Certinomis carried out several projects to renew its technical capabilities (new production site, new PKI software, adaptation to BR 1.6.5, among others). Franck as our Technical Director led all this work. And at the same time, Frank was Mozilla’s only point of contact. Inevitably there has been errors in settings (e.g. Issue F4 & F5) or incomplete corrections (Bug 1496088 comment#20 and answer that are part of Issue F3) and low reactivity (Issue B until November 2018) and perhaps editorial errors when updating PCs and DPCs (for example Issue D, rule 3.2.2.4.5 is mentioned in figures, but the description, in English, is that of rule 3.2.2.4.6)<br />
<br />
-->Response to Cause 1:<br />
<br />
- Action 1:<br />
<br />
Franck’s departure was an opportunity to restructure Certinomis’ technical management with three roles for caring of SSL activity.<br />
- an internal audit team independent of the project management is in place; the structure that ensures it has implemented a daily linting post-issuance control since April 1st, to allow us to detect without delay any possible mistake.<br />
- An employee of the quality team of Certinomis will be designated as the main contact of the CA/B Forum and Mozilla (but not the only point of contact).<br />
To be complete on this topic the transition between Franck and another person had been prepared during the three months following his decision to leave.<br />
But it soon became clear that the person chosen was not fitted to the role. It is for this reason that I have resumed the discussion with Mozilla personally, and I intend to remain engaged on the subject until the situation is stabilized.<br />
-- PKI’s project management will carry out changes, settings and corrections.<br />
<br />
The idea is to separate those who propose the evolutions, those who realize them and those who control them. In this way each one carries out his task without being inhibited by the constraints of the other.<br />
<br />
- Second cause of problem: insufficient syntax control for certificate request processed by Enterprise RAs.<br />
<br />
Several problems have been reported for certificates issued for the domains "laposte.fr" and "labanquepostale.fr".<br />
La Poste and La Banque Postale belong to the La Poste group, as well as Certinomis. For each of these two companies an external RA was set up by Certinomis, to facilitate the issuance of certificates on the two domains controlled by these two companies. The ownership of domain names and the authorisation of operators have been established beforehand.<br />
In this context, it has recently happened that CSRs generated by technicians on their servers are inserted by the operators in the AE software and that the syntax errors they contained are not highlighted by the RA software neither detected by operators (a space in a domain name, truncated domain names, empty SANs, function names instead of geographical indications etc. (Issues F1 & F2).<br />
Under no circumstances could these errors lead, or could lead, to the supply to an illegitimate person for this purpose of a certificate containing a real domain name.<br />
<br />
-->Responses to Cause 2:<br />
<br />
- Action 2: Entreprise RAs have been temporarily deactivated to allow us to correct this situation.<br />
<br />
- Action no. 3: The action carried out as a priority was to install the pre-issuance linting. It is now operational as we committed to.<br />
<br />
- Action 4: The next action will be to strengthen control on the locality field in these external RAs.<br />
<br />
- Third cause of problem: human-based registration.<br />
<br />
Several certificates were issued in good faith for testing by operators of Certinomis (Issue F3). To understand, it is necessary to know that for our other ranges of certificates, it is sometimes necessary to provide a test certificate from the production CAs, for the purpose of testing complex applications from end to end. Well, in those cases, the operator must display the word "TEST" in the significant fields; and in order that the invalidity of these certificates be even more evident to third parties who rely, we have, voluntarily, created fictitious organizations whose name is intended to make evident this fictitious character, and above all, also a fictitious organization identifier. The objective is that no one can be misled with any of these certificates.<br />
<br />
This practice is forbidden by the CA/B Forum, I do not discuss it, and simply I explain why the operators of Certinomis could have made these errors.<br />
<br />
Another error related to human control occurred in February 2019: the town hall of Le Cannet, client of Certinomis for several years, was mistaken in writing its application form and requested a domain name "mediatheque-lecannet.fr" instead of "mediatheque.lecannet.fr". And the Certinomis RA operator did not notice that instead of a dot there was a dash.<br />
The employee who validated this request made an indisputable error, even though I am convinced that his vigilance would have been stronger for an unknown client.<br />
<br />
--> Responses to cause 3:<br />
<br />
- Action no. 5: for test certificates, the solution was to isolate the test organizations in a registration area where PTC SSL certificates are not available. This solution is now fully in place.<br />
<br />
- Action no. 6: Certinomis has developed a function for sending e-mails in accordance with BR 1.6.5 method 3.2.2.4.4 This function will be in production by May 15, and then it will no longer be possible for a human operator to add or validate a domain name without a positive response according to 3.2.2.4.4<br />
<br />
On these three main causes of problem, Certinomis has already started to act, certain actions have been completed (action n°2, action n°3, action n°5) one is partially completed (action n°1) and the others will be completed within a maximum of one month (action n°6) or two months (action n°4). And our efforts will not stop, other improvements are already in the works and will have to be added to our road map (implementation of method 3.2.2.4.6 for example).<br />
<br />
I don’t want to finish this answer without going back to the A issue, the Startcom cross-sign.<br />
I will not repeat all the history, Franck LEROY had detailed it in his e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of view: at no time did we in this case violate an existing rule, nor did we assist or seek to assist Startcom in circumventing the remediation plan proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand if what we wanted to do was acceptable, we clearly made it a condition for Iñigo to follow the plan and waited to be convinced that he had done so, and when, after all these precautions, we were told that we had not understood this remedial plan, we revoked both CAs without discussion.<br />
I hadn’t heard anything about it in those two years.<br />
So what is the factual criticism that is being made now, two years later? I don’t know about that.<br />
And what is the link with our difficulties of this year? None!<br />
<br />
In conclusion, I would like to remind you that Certinomis, although a modest player in the SSL business, is a respectably well-known company in France, qualified for several ranges of certificates, and which provides personal signature certificates for many organizations, large companies, ministries and local communities.<br />
<br />
This good reputation does not justify the errors that are currently highlighted.<br />
<br />
But this fame was not obtained by chance, and on the contrary, it is a testament to our know-how, our work and the rigour we put into it.<br />
<br />
And I believe that considering this is likely to reassure the Mozilla community and restore its confidence: It’s true that we have been initially destabilized by the barrage of questions and bug notifications that started just after the departure of our former technical director Franck LEROY.<br />
But the attention paid to this issue over the past three months and especially the rapid progress of our action plan show that we are taking these matters seriously and that we are able to play our role as a CA as well in the rules of the CA/B Forum than in the other rules to which we are subject.<br />
<br />
Kind Regards,<br />
<br />
François CHASSERY<br />
CEO<br />
Certinomis</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1212121CA/Certinomis Issues2019-05-10T00:35:17Z<p>Wthayer: /* Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline */ add link to domain validation processes</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
[UPDATE 9-May in reply to the [[CA/Certinomis_Issues#Certinomis_Response|Certinomis Response]]]<br />
<br />
Certinomis asked Mozilla to approve their plan to help Startcom, but when the cross-certificates were discovered, [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/lyAX9Wz_AQAJ Gerv responded] "This seems to be very different to the plan you implemented." By cross-signing Startcom's old roots, Certinomis assisted Startcom in circumventing the remediation plan, and by proposing one plan then implementing a different one, Certinomis did so without Mozilla's consent.<br />
<br />
Startcom misissued a number of certificates ([https://crt.sh/?opt=cablint&id=160150786 example]) under that cross-signing relationship that Certinomis is responsible for as the Mozilla program member.<br />
<br />
By cross-signing Startcom's roots, Certinomis also took responsibility for Startcom's qualified audit.<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
<br />
[CERTINOMIS RESPONSE] On 6-May, 2019, Certinomis stated that pre issuance linting is now operational.<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.<br />
<br />
=== <s>Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline</s> ===<br />
The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious [https://cabforum.org/pipermail/public/2017-December/012630.html vulnerabilities that were identified]. This concern was communicated in Mozilla's [[CA/Communications#January_2018_CA_Communication|January 2018 and September 2018 CA Communications]]. In a [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 bug that was recently filed describing the issuance of a certificate containing an unregistered domain name], Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c9 Certinomis stated that BR method 3.2.2.4.5 was still in use].<br />
<br />
<br />
[CERTINOMIS RESPONSE] [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c12 Certinomis confirmed] that the following [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11 comment form a former employee], is correct:<br />
<br />
''I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).''<br />
<br />
''For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).''<br />
<br />
''Theses two validation methods were manual ones so subject to human errors.''<br />
''Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.''<br />
<br />
''This new automated validation feature were to be available by the end of 2018.''<br />
<br />
''I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).''<br />
<br />
Certinomis later provided a [https://bugzilla.mozilla.org/show_bug.cgi?id=1547072#c6 detailed description] of their domain validation processes.<br />
<br />
=== Certinomis Response ===<br />
The following response to all of the issues listed herein was posted to the mozilla.dev.security.policy discussion list on 9-April:<br />
<br />
Dear All,<br />
<br />
Before detailing my answer, I would like to refute opinions that Certinomis does not take these subjects seriously: since February the management of Certinomis was directly involved in the exchanges with the Mozilla community, decisions were made and are implemented.<br />
<br />
I acknowledge that I was surprised by the multiple topics that were grouped by Wayne THAYER on the CA/Certinomis issues page. I would also like to thank Wayne THAYER for his analysis of a technical point of view that distinguished different categories of problems.<br />
<br />
For my part, my role is above all to advance the practice of Certinomis, and for this I must classify the problems according to their cause, because the best way to solve a problem is to correct its cause. And I will allow myself to structure my answer according to this classification that I made of problems, reserving for the end the Issue A (Startcom Signing) that I really did not expect to hear about.<br />
<br />
- First cause of problems: An organization of the technical direction not adapted to the plan of charge in 2018<br />
<br />
In 2018, Certinomis carried out several projects to renew its technical capabilities (new production site, new PKI software, adaptation to BR 1.6.5, among others). Franck as our Technical Director led all this work. And at the same time, Frank was Mozilla’s only point of contact. Inevitably there has been errors in settings (e.g. Issue F4 & F5) or incomplete corrections (Bug 1496088 comment#20 and answer that are part of Issue F3) and low reactivity (Issue B until November 2018) and perhaps editorial errors when updating PCs and DPCs (for example Issue D, rule 3.2.2.4.5 is mentioned in figures, but the description, in English, is that of rule 3.2.2.4.6)<br />
<br />
-->Response to Cause 1:<br />
<br />
- Action 1:<br />
<br />
Franck’s departure was an opportunity to restructure Certinomis’ technical management with three roles for caring of SSL activity.<br />
- an internal audit team independent of the project management is in place; the structure that ensures it has implemented a daily linting post-issuance control since April 1st, to allow us to detect without delay any possible mistake.<br />
- An employee of the quality team of Certinomis will be designated as the main contact of the CA/B Forum and Mozilla (but not the only point of contact).<br />
To be complete on this topic the transition between Franck and another person had been prepared during the three months following his decision to leave.<br />
But it soon became clear that the person chosen was not fitted to the role. It is for this reason that I have resumed the discussion with Mozilla personally, and I intend to remain engaged on the subject until the situation is stabilized.<br />
-- PKI’s project management will carry out changes, settings and corrections.<br />
<br />
The idea is to separate those who propose the evolutions, those who realize them and those who control them. In this way each one carries out his task without being inhibited by the constraints of the other.<br />
<br />
- Second cause of problem: insufficient syntax control for certificate request processed by Enterprise RAs.<br />
<br />
Several problems have been reported for certificates issued for the domains "laposte.fr" and "labanquepostale.fr".<br />
La Poste and La Banque Postale belong to the La Poste group, as well as Certinomis. For each of these two companies an external RA was set up by Certinomis, to facilitate the issuance of certificates on the two domains controlled by these two companies. The ownership of domain names and the authorisation of operators have been established beforehand.<br />
In this context, it has recently happened that CSRs generated by technicians on their servers are inserted by the operators in the AE software and that the syntax errors they contained are not highlighted by the RA software neither detected by operators (a space in a domain name, truncated domain names, empty SANs, function names instead of geographical indications etc. (Issues F1 & F2).<br />
Under no circumstances could these errors lead, or could lead, to the supply to an illegitimate person for this purpose of a certificate containing a real domain name.<br />
<br />
-->Responses to Cause 2:<br />
<br />
- Action 2: Entreprise RAs have been temporarily deactivated to allow us to correct this situation.<br />
<br />
- Action no. 3: The action carried out as a priority was to install the pre-issuance linting. It is now operational as we committed to.<br />
<br />
- Action 4: The next action will be to strengthen control on the locality field in these external RAs.<br />
<br />
- Third cause of problem: human-based registration.<br />
<br />
Several certificates were issued in good faith for testing by operators of Certinomis (Issue F3). To understand, it is necessary to know that for our other ranges of certificates, it is sometimes necessary to provide a test certificate from the production CAs, for the purpose of testing complex applications from end to end. Well, in those cases, the operator must display the word "TEST" in the significant fields; and in order that the invalidity of these certificates be even more evident to third parties who rely, we have, voluntarily, created fictitious organizations whose name is intended to make evident this fictitious character, and above all, also a fictitious organization identifier. The objective is that no one can be misled with any of these certificates.<br />
<br />
This practice is forbidden by the CA/B Forum, I do not discuss it, and simply I explain why the operators of Certinomis could have made these errors.<br />
<br />
Another error related to human control occurred in February 2019: the town hall of Le Cannet, client of Certinomis for several years, was mistaken in writing its application form and requested a domain name "mediatheque-lecannet.fr" instead of "mediatheque.lecannet.fr". And the Certinomis RA operator did not notice that instead of a dot there was a dash.<br />
The employee who validated this request made an indisputable error, even though I am convinced that his vigilance would have been stronger for an unknown client.<br />
<br />
--> Responses to cause 3:<br />
<br />
- Action no. 5: for test certificates, the solution was to isolate the test organizations in a registration area where PTC SSL certificates are not available. This solution is now fully in place.<br />
<br />
- Action no. 6: Certinomis has developed a function for sending e-mails in accordance with BR 1.6.5 method 3.2.2.4.4 This function will be in production by May 15, and then it will no longer be possible for a human operator to add or validate a domain name without a positive response according to 3.2.2.4.4<br />
<br />
On these three main causes of problem, Certinomis has already started to act, certain actions have been completed (action n°2, action n°3, action n°5) one is partially completed (action n°1) and the others will be completed within a maximum of one month (action n°6) or two months (action n°4). And our efforts will not stop, other improvements are already in the works and will have to be added to our road map (implementation of method 3.2.2.4.6 for example).<br />
<br />
I don’t want to finish this answer without going back to the A issue, the Startcom cross-sign.<br />
I will not repeat all the history, Franck LEROY had detailed it in his e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of view: at no time did we in this case violate an existing rule, nor did we assist or seek to assist Startcom in circumventing the remediation plan proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand if what we wanted to do was acceptable, we clearly made it a condition for Iñigo to follow the plan and waited to be convinced that he had done so, and when, after all these precautions, we were told that we had not understood this remedial plan, we revoked both CAs without discussion.<br />
I hadn’t heard anything about it in those two years.<br />
So what is the factual criticism that is being made now, two years later? I don’t know about that.<br />
And what is the link with our difficulties of this year? None!<br />
<br />
In conclusion, I would like to remind you that Certinomis, although a modest player in the SSL business, is a respectably well-known company in France, qualified for several ranges of certificates, and which provides personal signature certificates for many organizations, large companies, ministries and local communities.<br />
<br />
This good reputation does not justify the errors that are currently highlighted.<br />
<br />
But this fame was not obtained by chance, and on the contrary, it is a testament to our know-how, our work and the rigour we put into it.<br />
<br />
And I believe that considering this is likely to reassure the Mozilla community and restore its confidence: It’s true that we have been initially destabilized by the barrage of questions and bug notifications that started just after the departure of our former technical director Franck LEROY.<br />
But the attention paid to this issue over the past three months and especially the rapid progress of our action plan show that we are taking these matters seriously and that we are able to play our role as a CA as well in the rules of the CA/B Forum than in the other rules to which we are subject.<br />
<br />
Kind Regards,<br />
<br />
François CHASSERY<br />
CEO<br />
Certinomis</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1212120CA/Certinomis Issues2019-05-10T00:32:08Z<p>Wthayer: /* Issue A: StartCom Cross-signing (2017) */ update link</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
[UPDATE 9-May in reply to the [[CA/Certinomis_Issues#Certinomis_Response|Certinomis Response]]]<br />
<br />
Certinomis asked Mozilla to approve their plan to help Startcom, but when the cross-certificates were discovered, [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/lyAX9Wz_AQAJ Gerv responded] "This seems to be very different to the plan you implemented." By cross-signing Startcom's old roots, Certinomis assisted Startcom in circumventing the remediation plan, and by proposing one plan then implementing a different one, Certinomis did so without Mozilla's consent.<br />
<br />
Startcom misissued a number of certificates ([https://crt.sh/?opt=cablint&id=160150786 example]) under that cross-signing relationship that Certinomis is responsible for as the Mozilla program member.<br />
<br />
By cross-signing Startcom's roots, Certinomis also took responsibility for Startcom's qualified audit.<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
<br />
[CERTINOMIS RESPONSE] On 6-May, 2019, Certinomis stated that pre issuance linting is now operational.<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.<br />
<br />
=== <s>Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline</s> ===<br />
The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious [https://cabforum.org/pipermail/public/2017-December/012630.html vulnerabilities that were identified]. This concern was communicated in Mozilla's [[CA/Communications#January_2018_CA_Communication|January 2018 and September 2018 CA Communications]]. In a [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 bug that was recently filed describing the issuance of a certificate containing an unregistered domain name], Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c9 Certinomis stated that BR method 3.2.2.4.5 was still in use].<br />
<br />
<br />
[CERTINOMIS RESPONSE] [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c12 Certinomis confirmed] that the following [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11 comment form a former employee], is correct:<br />
<br />
''I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).''<br />
<br />
''For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).''<br />
<br />
''Theses two validation methods were manual ones so subject to human errors.''<br />
''Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.''<br />
<br />
''This new automated validation feature were to be available by the end of 2018.''<br />
<br />
''I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).''<br />
<br />
=== Certinomis Response ===<br />
The following response to all of the issues listed herein was posted to the mozilla.dev.security.policy discussion list on 9-April:<br />
<br />
Dear All,<br />
<br />
Before detailing my answer, I would like to refute opinions that Certinomis does not take these subjects seriously: since February the management of Certinomis was directly involved in the exchanges with the Mozilla community, decisions were made and are implemented.<br />
<br />
I acknowledge that I was surprised by the multiple topics that were grouped by Wayne THAYER on the CA/Certinomis issues page. I would also like to thank Wayne THAYER for his analysis of a technical point of view that distinguished different categories of problems.<br />
<br />
For my part, my role is above all to advance the practice of Certinomis, and for this I must classify the problems according to their cause, because the best way to solve a problem is to correct its cause. And I will allow myself to structure my answer according to this classification that I made of problems, reserving for the end the Issue A (Startcom Signing) that I really did not expect to hear about.<br />
<br />
- First cause of problems: An organization of the technical direction not adapted to the plan of charge in 2018<br />
<br />
In 2018, Certinomis carried out several projects to renew its technical capabilities (new production site, new PKI software, adaptation to BR 1.6.5, among others). Franck as our Technical Director led all this work. And at the same time, Frank was Mozilla’s only point of contact. Inevitably there has been errors in settings (e.g. Issue F4 & F5) or incomplete corrections (Bug 1496088 comment#20 and answer that are part of Issue F3) and low reactivity (Issue B until November 2018) and perhaps editorial errors when updating PCs and DPCs (for example Issue D, rule 3.2.2.4.5 is mentioned in figures, but the description, in English, is that of rule 3.2.2.4.6)<br />
<br />
-->Response to Cause 1:<br />
<br />
- Action 1:<br />
<br />
Franck’s departure was an opportunity to restructure Certinomis’ technical management with three roles for caring of SSL activity.<br />
- an internal audit team independent of the project management is in place; the structure that ensures it has implemented a daily linting post-issuance control since April 1st, to allow us to detect without delay any possible mistake.<br />
- An employee of the quality team of Certinomis will be designated as the main contact of the CA/B Forum and Mozilla (but not the only point of contact).<br />
To be complete on this topic the transition between Franck and another person had been prepared during the three months following his decision to leave.<br />
But it soon became clear that the person chosen was not fitted to the role. It is for this reason that I have resumed the discussion with Mozilla personally, and I intend to remain engaged on the subject until the situation is stabilized.<br />
-- PKI’s project management will carry out changes, settings and corrections.<br />
<br />
The idea is to separate those who propose the evolutions, those who realize them and those who control them. In this way each one carries out his task without being inhibited by the constraints of the other.<br />
<br />
- Second cause of problem: insufficient syntax control for certificate request processed by Enterprise RAs.<br />
<br />
Several problems have been reported for certificates issued for the domains "laposte.fr" and "labanquepostale.fr".<br />
La Poste and La Banque Postale belong to the La Poste group, as well as Certinomis. For each of these two companies an external RA was set up by Certinomis, to facilitate the issuance of certificates on the two domains controlled by these two companies. The ownership of domain names and the authorisation of operators have been established beforehand.<br />
In this context, it has recently happened that CSRs generated by technicians on their servers are inserted by the operators in the AE software and that the syntax errors they contained are not highlighted by the RA software neither detected by operators (a space in a domain name, truncated domain names, empty SANs, function names instead of geographical indications etc. (Issues F1 & F2).<br />
Under no circumstances could these errors lead, or could lead, to the supply to an illegitimate person for this purpose of a certificate containing a real domain name.<br />
<br />
-->Responses to Cause 2:<br />
<br />
- Action 2: Entreprise RAs have been temporarily deactivated to allow us to correct this situation.<br />
<br />
- Action no. 3: The action carried out as a priority was to install the pre-issuance linting. It is now operational as we committed to.<br />
<br />
- Action 4: The next action will be to strengthen control on the locality field in these external RAs.<br />
<br />
- Third cause of problem: human-based registration.<br />
<br />
Several certificates were issued in good faith for testing by operators of Certinomis (Issue F3). To understand, it is necessary to know that for our other ranges of certificates, it is sometimes necessary to provide a test certificate from the production CAs, for the purpose of testing complex applications from end to end. Well, in those cases, the operator must display the word "TEST" in the significant fields; and in order that the invalidity of these certificates be even more evident to third parties who rely, we have, voluntarily, created fictitious organizations whose name is intended to make evident this fictitious character, and above all, also a fictitious organization identifier. The objective is that no one can be misled with any of these certificates.<br />
<br />
This practice is forbidden by the CA/B Forum, I do not discuss it, and simply I explain why the operators of Certinomis could have made these errors.<br />
<br />
Another error related to human control occurred in February 2019: the town hall of Le Cannet, client of Certinomis for several years, was mistaken in writing its application form and requested a domain name "mediatheque-lecannet.fr" instead of "mediatheque.lecannet.fr". And the Certinomis RA operator did not notice that instead of a dot there was a dash.<br />
The employee who validated this request made an indisputable error, even though I am convinced that his vigilance would have been stronger for an unknown client.<br />
<br />
--> Responses to cause 3:<br />
<br />
- Action no. 5: for test certificates, the solution was to isolate the test organizations in a registration area where PTC SSL certificates are not available. This solution is now fully in place.<br />
<br />
- Action no. 6: Certinomis has developed a function for sending e-mails in accordance with BR 1.6.5 method 3.2.2.4.4 This function will be in production by May 15, and then it will no longer be possible for a human operator to add or validate a domain name without a positive response according to 3.2.2.4.4<br />
<br />
On these three main causes of problem, Certinomis has already started to act, certain actions have been completed (action n°2, action n°3, action n°5) one is partially completed (action n°1) and the others will be completed within a maximum of one month (action n°6) or two months (action n°4). And our efforts will not stop, other improvements are already in the works and will have to be added to our road map (implementation of method 3.2.2.4.6 for example).<br />
<br />
I don’t want to finish this answer without going back to the A issue, the Startcom cross-sign.<br />
I will not repeat all the history, Franck LEROY had detailed it in his e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of view: at no time did we in this case violate an existing rule, nor did we assist or seek to assist Startcom in circumventing the remediation plan proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand if what we wanted to do was acceptable, we clearly made it a condition for Iñigo to follow the plan and waited to be convinced that he had done so, and when, after all these precautions, we were told that we had not understood this remedial plan, we revoked both CAs without discussion.<br />
I hadn’t heard anything about it in those two years.<br />
So what is the factual criticism that is being made now, two years later? I don’t know about that.<br />
And what is the link with our difficulties of this year? None!<br />
<br />
In conclusion, I would like to remind you that Certinomis, although a modest player in the SSL business, is a respectably well-known company in France, qualified for several ranges of certificates, and which provides personal signature certificates for many organizations, large companies, ministries and local communities.<br />
<br />
This good reputation does not justify the errors that are currently highlighted.<br />
<br />
But this fame was not obtained by chance, and on the contrary, it is a testament to our know-how, our work and the rigour we put into it.<br />
<br />
And I believe that considering this is likely to reassure the Mozilla community and restore its confidence: It’s true that we have been initially destabilized by the barrage of questions and bug notifications that started just after the departure of our former technical director Franck LEROY.<br />
But the attention paid to this issue over the past three months and especially the rapid progress of our action plan show that we are taking these matters seriously and that we are able to play our role as a CA as well in the rules of the CA/B Forum than in the other rules to which we are subject.<br />
<br />
Kind Regards,<br />
<br />
François CHASSERY<br />
CEO<br />
Certinomis</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1212119CA/Certinomis Issues2019-05-10T00:31:00Z<p>Wthayer: /* Issue A: StartCom Cross-signing (2017) */ Added response Startcom Issues</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
[UPDATE 9-May in reply to the [[CA/Certinomis_Issues#Certinomis_Response|Certinomis Response]]]<br />
<br />
Certinomis asked Mozilla to approve their plan to help Startcom, but when the cross-certificates were discovered, [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/lyAX9Wz_AQAJ Gerv responded] "This seems to be very different to the plan you implemented." By cross-signing Startcom's old roots, Certinomis assisted Startcom in circumventing the remediation plan, and by proposing one plan then implementing a different one, Certinomis did so without Mozilla's consent.<br />
<br />
Startcom misissued a number of certificates (e.g. [3]) under that cross-signing relationship that Certinomis is responsible for as the Mozilla program member.<br />
<br />
By cross-signing Startcom's roots, Certinomis also took responsibility for Startcom's qualified audit.<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
<br />
[CERTINOMIS RESPONSE] On 6-May, 2019, Certinomis stated that pre issuance linting is now operational.<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.<br />
<br />
=== <s>Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline</s> ===<br />
The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious [https://cabforum.org/pipermail/public/2017-December/012630.html vulnerabilities that were identified]. This concern was communicated in Mozilla's [[CA/Communications#January_2018_CA_Communication|January 2018 and September 2018 CA Communications]]. In a [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 bug that was recently filed describing the issuance of a certificate containing an unregistered domain name], Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c9 Certinomis stated that BR method 3.2.2.4.5 was still in use].<br />
<br />
<br />
[CERTINOMIS RESPONSE] [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c12 Certinomis confirmed] that the following [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11 comment form a former employee], is correct:<br />
<br />
''I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).''<br />
<br />
''For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).''<br />
<br />
''Theses two validation methods were manual ones so subject to human errors.''<br />
''Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.''<br />
<br />
''This new automated validation feature were to be available by the end of 2018.''<br />
<br />
''I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).''<br />
<br />
=== Certinomis Response ===<br />
The following response to all of the issues listed herein was posted to the mozilla.dev.security.policy discussion list on 9-April:<br />
<br />
Dear All,<br />
<br />
Before detailing my answer, I would like to refute opinions that Certinomis does not take these subjects seriously: since February the management of Certinomis was directly involved in the exchanges with the Mozilla community, decisions were made and are implemented.<br />
<br />
I acknowledge that I was surprised by the multiple topics that were grouped by Wayne THAYER on the CA/Certinomis issues page. I would also like to thank Wayne THAYER for his analysis of a technical point of view that distinguished different categories of problems.<br />
<br />
For my part, my role is above all to advance the practice of Certinomis, and for this I must classify the problems according to their cause, because the best way to solve a problem is to correct its cause. And I will allow myself to structure my answer according to this classification that I made of problems, reserving for the end the Issue A (Startcom Signing) that I really did not expect to hear about.<br />
<br />
- First cause of problems: An organization of the technical direction not adapted to the plan of charge in 2018<br />
<br />
In 2018, Certinomis carried out several projects to renew its technical capabilities (new production site, new PKI software, adaptation to BR 1.6.5, among others). Franck as our Technical Director led all this work. And at the same time, Frank was Mozilla’s only point of contact. Inevitably there has been errors in settings (e.g. Issue F4 & F5) or incomplete corrections (Bug 1496088 comment#20 and answer that are part of Issue F3) and low reactivity (Issue B until November 2018) and perhaps editorial errors when updating PCs and DPCs (for example Issue D, rule 3.2.2.4.5 is mentioned in figures, but the description, in English, is that of rule 3.2.2.4.6)<br />
<br />
-->Response to Cause 1:<br />
<br />
- Action 1:<br />
<br />
Franck’s departure was an opportunity to restructure Certinomis’ technical management with three roles for caring of SSL activity.<br />
- an internal audit team independent of the project management is in place; the structure that ensures it has implemented a daily linting post-issuance control since April 1st, to allow us to detect without delay any possible mistake.<br />
- An employee of the quality team of Certinomis will be designated as the main contact of the CA/B Forum and Mozilla (but not the only point of contact).<br />
To be complete on this topic the transition between Franck and another person had been prepared during the three months following his decision to leave.<br />
But it soon became clear that the person chosen was not fitted to the role. It is for this reason that I have resumed the discussion with Mozilla personally, and I intend to remain engaged on the subject until the situation is stabilized.<br />
-- PKI’s project management will carry out changes, settings and corrections.<br />
<br />
The idea is to separate those who propose the evolutions, those who realize them and those who control them. In this way each one carries out his task without being inhibited by the constraints of the other.<br />
<br />
- Second cause of problem: insufficient syntax control for certificate request processed by Enterprise RAs.<br />
<br />
Several problems have been reported for certificates issued for the domains "laposte.fr" and "labanquepostale.fr".<br />
La Poste and La Banque Postale belong to the La Poste group, as well as Certinomis. For each of these two companies an external RA was set up by Certinomis, to facilitate the issuance of certificates on the two domains controlled by these two companies. The ownership of domain names and the authorisation of operators have been established beforehand.<br />
In this context, it has recently happened that CSRs generated by technicians on their servers are inserted by the operators in the AE software and that the syntax errors they contained are not highlighted by the RA software neither detected by operators (a space in a domain name, truncated domain names, empty SANs, function names instead of geographical indications etc. (Issues F1 & F2).<br />
Under no circumstances could these errors lead, or could lead, to the supply to an illegitimate person for this purpose of a certificate containing a real domain name.<br />
<br />
-->Responses to Cause 2:<br />
<br />
- Action 2: Entreprise RAs have been temporarily deactivated to allow us to correct this situation.<br />
<br />
- Action no. 3: The action carried out as a priority was to install the pre-issuance linting. It is now operational as we committed to.<br />
<br />
- Action 4: The next action will be to strengthen control on the locality field in these external RAs.<br />
<br />
- Third cause of problem: human-based registration.<br />
<br />
Several certificates were issued in good faith for testing by operators of Certinomis (Issue F3). To understand, it is necessary to know that for our other ranges of certificates, it is sometimes necessary to provide a test certificate from the production CAs, for the purpose of testing complex applications from end to end. Well, in those cases, the operator must display the word "TEST" in the significant fields; and in order that the invalidity of these certificates be even more evident to third parties who rely, we have, voluntarily, created fictitious organizations whose name is intended to make evident this fictitious character, and above all, also a fictitious organization identifier. The objective is that no one can be misled with any of these certificates.<br />
<br />
This practice is forbidden by the CA/B Forum, I do not discuss it, and simply I explain why the operators of Certinomis could have made these errors.<br />
<br />
Another error related to human control occurred in February 2019: the town hall of Le Cannet, client of Certinomis for several years, was mistaken in writing its application form and requested a domain name "mediatheque-lecannet.fr" instead of "mediatheque.lecannet.fr". And the Certinomis RA operator did not notice that instead of a dot there was a dash.<br />
The employee who validated this request made an indisputable error, even though I am convinced that his vigilance would have been stronger for an unknown client.<br />
<br />
--> Responses to cause 3:<br />
<br />
- Action no. 5: for test certificates, the solution was to isolate the test organizations in a registration area where PTC SSL certificates are not available. This solution is now fully in place.<br />
<br />
- Action no. 6: Certinomis has developed a function for sending e-mails in accordance with BR 1.6.5 method 3.2.2.4.4 This function will be in production by May 15, and then it will no longer be possible for a human operator to add or validate a domain name without a positive response according to 3.2.2.4.4<br />
<br />
On these three main causes of problem, Certinomis has already started to act, certain actions have been completed (action n°2, action n°3, action n°5) one is partially completed (action n°1) and the others will be completed within a maximum of one month (action n°6) or two months (action n°4). And our efforts will not stop, other improvements are already in the works and will have to be added to our road map (implementation of method 3.2.2.4.6 for example).<br />
<br />
I don’t want to finish this answer without going back to the A issue, the Startcom cross-sign.<br />
I will not repeat all the history, Franck LEROY had detailed it in his e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of view: at no time did we in this case violate an existing rule, nor did we assist or seek to assist Startcom in circumventing the remediation plan proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand if what we wanted to do was acceptable, we clearly made it a condition for Iñigo to follow the plan and waited to be convinced that he had done so, and when, after all these precautions, we were told that we had not understood this remedial plan, we revoked both CAs without discussion.<br />
I hadn’t heard anything about it in those two years.<br />
So what is the factual criticism that is being made now, two years later? I don’t know about that.<br />
And what is the link with our difficulties of this year? None!<br />
<br />
In conclusion, I would like to remind you that Certinomis, although a modest player in the SSL business, is a respectably well-known company in France, qualified for several ranges of certificates, and which provides personal signature certificates for many organizations, large companies, ministries and local communities.<br />
<br />
This good reputation does not justify the errors that are currently highlighted.<br />
<br />
But this fame was not obtained by chance, and on the contrary, it is a testament to our know-how, our work and the rigour we put into it.<br />
<br />
And I believe that considering this is likely to reassure the Mozilla community and restore its confidence: It’s true that we have been initially destabilized by the barrage of questions and bug notifications that started just after the departure of our former technical director Franck LEROY.<br />
But the attention paid to this issue over the past three months and especially the rapid progress of our action plan show that we are taking these matters seriously and that we are able to play our role as a CA as well in the rules of the CA/B Forum than in the other rules to which we are subject.<br />
<br />
Kind Regards,<br />
<br />
François CHASSERY<br />
CEO<br />
Certinomis</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1212115CA/Certinomis Issues2019-05-09T23:37:45Z<p>Wthayer: /* Certinomis Response */ Action 1 formatting fix</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
<br />
[CERTINOMIS RESPONSE] On 6-May, 2019, Certinomis stated that pre issuance linting is now operational.<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.<br />
<br />
=== <s>Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline</s> ===<br />
The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious [https://cabforum.org/pipermail/public/2017-December/012630.html vulnerabilities that were identified]. This concern was communicated in Mozilla's [[CA/Communications#January_2018_CA_Communication|January 2018 and September 2018 CA Communications]]. In a [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 bug that was recently filed describing the issuance of a certificate containing an unregistered domain name], Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c9 Certinomis stated that BR method 3.2.2.4.5 was still in use].<br />
<br />
<br />
[CERTINOMIS RESPONSE] [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c12 Certinomis confirmed] that the following [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11 comment form a former employee], is correct:<br />
<br />
''I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).''<br />
<br />
''For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).''<br />
<br />
''Theses two validation methods were manual ones so subject to human errors.''<br />
''Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.''<br />
<br />
''This new automated validation feature were to be available by the end of 2018.''<br />
<br />
''I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).''<br />
<br />
=== Certinomis Response ===<br />
The following response to all of the issues listed herein was posted to the mozilla.dev.security.policy discussion list on 9-April:<br />
<br />
Dear All,<br />
<br />
Before detailing my answer, I would like to refute opinions that Certinomis does not take these subjects seriously: since February the management of Certinomis was directly involved in the exchanges with the Mozilla community, decisions were made and are implemented.<br />
<br />
I acknowledge that I was surprised by the multiple topics that were grouped by Wayne THAYER on the CA/Certinomis issues page. I would also like to thank Wayne THAYER for his analysis of a technical point of view that distinguished different categories of problems.<br />
<br />
For my part, my role is above all to advance the practice of Certinomis, and for this I must classify the problems according to their cause, because the best way to solve a problem is to correct its cause. And I will allow myself to structure my answer according to this classification that I made of problems, reserving for the end the Issue A (Startcom Signing) that I really did not expect to hear about.<br />
<br />
- First cause of problems: An organization of the technical direction not adapted to the plan of charge in 2018<br />
<br />
In 2018, Certinomis carried out several projects to renew its technical capabilities (new production site, new PKI software, adaptation to BR 1.6.5, among others). Franck as our Technical Director led all this work. And at the same time, Frank was Mozilla’s only point of contact. Inevitably there has been errors in settings (e.g. Issue F4 & F5) or incomplete corrections (Bug 1496088 comment#20 and answer that are part of Issue F3) and low reactivity (Issue B until November 2018) and perhaps editorial errors when updating PCs and DPCs (for example Issue D, rule 3.2.2.4.5 is mentioned in figures, but the description, in English, is that of rule 3.2.2.4.6)<br />
<br />
-->Response to Cause 1:<br />
<br />
- Action 1:<br />
<br />
Franck’s departure was an opportunity to restructure Certinomis’ technical management with three roles for caring of SSL activity.<br />
- an internal audit team independent of the project management is in place; the structure that ensures it has implemented a daily linting post-issuance control since April 1st, to allow us to detect without delay any possible mistake.<br />
- An employee of the quality team of Certinomis will be designated as the main contact of the CA/B Forum and Mozilla (but not the only point of contact).<br />
To be complete on this topic the transition between Franck and another person had been prepared during the three months following his decision to leave.<br />
But it soon became clear that the person chosen was not fitted to the role. It is for this reason that I have resumed the discussion with Mozilla personally, and I intend to remain engaged on the subject until the situation is stabilized.<br />
-- PKI’s project management will carry out changes, settings and corrections.<br />
<br />
The idea is to separate those who propose the evolutions, those who realize them and those who control them. In this way each one carries out his task without being inhibited by the constraints of the other.<br />
<br />
- Second cause of problem: insufficient syntax control for certificate request processed by Enterprise RAs.<br />
<br />
Several problems have been reported for certificates issued for the domains "laposte.fr" and "labanquepostale.fr".<br />
La Poste and La Banque Postale belong to the La Poste group, as well as Certinomis. For each of these two companies an external RA was set up by Certinomis, to facilitate the issuance of certificates on the two domains controlled by these two companies. The ownership of domain names and the authorisation of operators have been established beforehand.<br />
In this context, it has recently happened that CSRs generated by technicians on their servers are inserted by the operators in the AE software and that the syntax errors they contained are not highlighted by the RA software neither detected by operators (a space in a domain name, truncated domain names, empty SANs, function names instead of geographical indications etc. (Issues F1 & F2).<br />
Under no circumstances could these errors lead, or could lead, to the supply to an illegitimate person for this purpose of a certificate containing a real domain name.<br />
<br />
-->Responses to Cause 2:<br />
<br />
- Action 2: Entreprise RAs have been temporarily deactivated to allow us to correct this situation.<br />
<br />
- Action no. 3: The action carried out as a priority was to install the pre-issuance linting. It is now operational as we committed to.<br />
<br />
- Action 4: The next action will be to strengthen control on the locality field in these external RAs.<br />
<br />
- Third cause of problem: human-based registration.<br />
<br />
Several certificates were issued in good faith for testing by operators of Certinomis (Issue F3). To understand, it is necessary to know that for our other ranges of certificates, it is sometimes necessary to provide a test certificate from the production CAs, for the purpose of testing complex applications from end to end. Well, in those cases, the operator must display the word "TEST" in the significant fields; and in order that the invalidity of these certificates be even more evident to third parties who rely, we have, voluntarily, created fictitious organizations whose name is intended to make evident this fictitious character, and above all, also a fictitious organization identifier. The objective is that no one can be misled with any of these certificates.<br />
<br />
This practice is forbidden by the CA/B Forum, I do not discuss it, and simply I explain why the operators of Certinomis could have made these errors.<br />
<br />
Another error related to human control occurred in February 2019: the town hall of Le Cannet, client of Certinomis for several years, was mistaken in writing its application form and requested a domain name "mediatheque-lecannet.fr" instead of "mediatheque.lecannet.fr". And the Certinomis RA operator did not notice that instead of a dot there was a dash.<br />
The employee who validated this request made an indisputable error, even though I am convinced that his vigilance would have been stronger for an unknown client.<br />
<br />
--> Responses to cause 3:<br />
<br />
- Action no. 5: for test certificates, the solution was to isolate the test organizations in a registration area where PTC SSL certificates are not available. This solution is now fully in place.<br />
<br />
- Action no. 6: Certinomis has developed a function for sending e-mails in accordance with BR 1.6.5 method 3.2.2.4.4 This function will be in production by May 15, and then it will no longer be possible for a human operator to add or validate a domain name without a positive response according to 3.2.2.4.4<br />
<br />
On these three main causes of problem, Certinomis has already started to act, certain actions have been completed (action n°2, action n°3, action n°5) one is partially completed (action n°1) and the others will be completed within a maximum of one month (action n°6) or two months (action n°4). And our efforts will not stop, other improvements are already in the works and will have to be added to our road map (implementation of method 3.2.2.4.6 for example).<br />
<br />
I don’t want to finish this answer without going back to the A issue, the Startcom cross-sign.<br />
I will not repeat all the history, Franck LEROY had detailed it in his e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of view: at no time did we in this case violate an existing rule, nor did we assist or seek to assist Startcom in circumventing the remediation plan proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand if what we wanted to do was acceptable, we clearly made it a condition for Iñigo to follow the plan and waited to be convinced that he had done so, and when, after all these precautions, we were told that we had not understood this remedial plan, we revoked both CAs without discussion.<br />
I hadn’t heard anything about it in those two years.<br />
So what is the factual criticism that is being made now, two years later? I don’t know about that.<br />
And what is the link with our difficulties of this year? None!<br />
<br />
In conclusion, I would like to remind you that Certinomis, although a modest player in the SSL business, is a respectably well-known company in France, qualified for several ranges of certificates, and which provides personal signature certificates for many organizations, large companies, ministries and local communities.<br />
<br />
This good reputation does not justify the errors that are currently highlighted.<br />
<br />
But this fame was not obtained by chance, and on the contrary, it is a testament to our know-how, our work and the rigour we put into it.<br />
<br />
And I believe that considering this is likely to reassure the Mozilla community and restore its confidence: It’s true that we have been initially destabilized by the barrage of questions and bug notifications that started just after the departure of our former technical director Franck LEROY.<br />
But the attention paid to this issue over the past three months and especially the rapid progress of our action plan show that we are taking these matters seriously and that we are able to play our role as a CA as well in the rules of the CA/B Forum than in the other rules to which we are subject.<br />
<br />
Kind Regards,<br />
<br />
François CHASSERY<br />
CEO<br />
Certinomis</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1212113CA/Certinomis Issues2019-05-09T23:35:52Z<p>Wthayer: Add Certinomis Response section</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
<br />
[CERTINOMIS RESPONSE] On 6-May, 2019, Certinomis stated that pre issuance linting is now operational.<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.<br />
<br />
=== <s>Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline</s> ===<br />
The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious [https://cabforum.org/pipermail/public/2017-December/012630.html vulnerabilities that were identified]. This concern was communicated in Mozilla's [[CA/Communications#January_2018_CA_Communication|January 2018 and September 2018 CA Communications]]. In a [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 bug that was recently filed describing the issuance of a certificate containing an unregistered domain name], Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c9 Certinomis stated that BR method 3.2.2.4.5 was still in use].<br />
<br />
<br />
[CERTINOMIS RESPONSE] [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c12 Certinomis confirmed] that the following [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11 comment form a former employee], is correct:<br />
<br />
''I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).''<br />
<br />
''For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).''<br />
<br />
''Theses two validation methods were manual ones so subject to human errors.''<br />
''Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.''<br />
<br />
''This new automated validation feature were to be available by the end of 2018.''<br />
<br />
''I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).''<br />
<br />
=== Certinomis Response ===<br />
The following response to all of the issues listed herein was posted to the mozilla.dev.security.policy discussion list on 9-April:<br />
<br />
Dear All,<br />
<br />
Before detailing my answer, I would like to refute opinions that Certinomis does not take these subjects seriously: since February the management of Certinomis was directly involved in the exchanges with the Mozilla community, decisions were made and are implemented.<br />
<br />
I acknowledge that I was surprised by the multiple topics that were grouped by Wayne THAYER on the CA/Certinomis issues page. I would also like to thank Wayne THAYER for his analysis of a technical point of view that distinguished different categories of problems.<br />
<br />
For my part, my role is above all to advance the practice of Certinomis, and for this I must classify the problems according to their cause, because the best way to solve a problem is to correct its cause. And I will allow myself to structure my answer according to this classification that I made of problems, reserving for the end the Issue A (Startcom Signing) that I really did not expect to hear about.<br />
<br />
- First cause of problems: An organization of the technical direction not adapted to the plan of charge in 2018<br />
<br />
In 2018, Certinomis carried out several projects to renew its technical capabilities (new production site, new PKI software, adaptation to BR 1.6.5, among others). Franck as our Technical Director led all this work. And at the same time, Frank was Mozilla’s only point of contact. Inevitably there has been errors in settings (e.g. Issue F4 & F5) or incomplete corrections (Bug 1496088 comment#20 and answer that are part of Issue F3) and low reactivity (Issue B until November 2018) and perhaps editorial errors when updating PCs and DPCs (for example Issue D, rule 3.2.2.4.5 is mentioned in figures, but the description, in English, is that of rule 3.2.2.4.6)<br />
<br />
-->Response to Cause 1:<br />
<br />
- Action 1:<br />
Franck’s departure was an opportunity to restructure Certinomis’ technical management with three roles for caring of SSL activity.<br />
- an internal audit team independent of the project management is in place; the structure that ensures it has implemented a daily linting post-issuance control since April 1st, to allow us to detect without delay any possible mistake.<br />
- An employee of the quality team of Certinomis will be designated as the main contact of the CA/B Forum and Mozilla (but not the only point of contact).<br />
To be complete on this topic the transition between Franck and another person had been prepared during the three months following his decision to leave.<br />
But it soon became clear that the person chosen was not fitted to the role. It is for this reason that I have resumed the discussion with Mozilla personally, and I intend to remain engaged on the subject until the situation is stabilized.<br />
-- PKI’s project management will carry out changes, settings and corrections.<br />
<br />
The idea is to separate those who propose the evolutions, those who realize them and those who control them. In this way each one carries out his task without being inhibited by the constraints of the other.<br />
<br />
- Second cause of problem: insufficient syntax control for certificate request processed by Enterprise RAs.<br />
<br />
Several problems have been reported for certificates issued for the domains "laposte.fr" and "labanquepostale.fr".<br />
La Poste and La Banque Postale belong to the La Poste group, as well as Certinomis. For each of these two companies an external RA was set up by Certinomis, to facilitate the issuance of certificates on the two domains controlled by these two companies. The ownership of domain names and the authorisation of operators have been established beforehand.<br />
In this context, it has recently happened that CSRs generated by technicians on their servers are inserted by the operators in the AE software and that the syntax errors they contained are not highlighted by the RA software neither detected by operators (a space in a domain name, truncated domain names, empty SANs, function names instead of geographical indications etc. (Issues F1 & F2).<br />
Under no circumstances could these errors lead, or could lead, to the supply to an illegitimate person for this purpose of a certificate containing a real domain name.<br />
<br />
-->Responses to Cause 2:<br />
<br />
- Action 2: Entreprise RAs have been temporarily deactivated to allow us to correct this situation.<br />
<br />
- Action no. 3: The action carried out as a priority was to install the pre-issuance linting. It is now operational as we committed to.<br />
<br />
- Action 4: The next action will be to strengthen control on the locality field in these external RAs.<br />
<br />
- Third cause of problem: human-based registration.<br />
<br />
Several certificates were issued in good faith for testing by operators of Certinomis (Issue F3). To understand, it is necessary to know that for our other ranges of certificates, it is sometimes necessary to provide a test certificate from the production CAs, for the purpose of testing complex applications from end to end. Well, in those cases, the operator must display the word "TEST" in the significant fields; and in order that the invalidity of these certificates be even more evident to third parties who rely, we have, voluntarily, created fictitious organizations whose name is intended to make evident this fictitious character, and above all, also a fictitious organization identifier. The objective is that no one can be misled with any of these certificates.<br />
<br />
This practice is forbidden by the CA/B Forum, I do not discuss it, and simply I explain why the operators of Certinomis could have made these errors.<br />
<br />
Another error related to human control occurred in February 2019: the town hall of Le Cannet, client of Certinomis for several years, was mistaken in writing its application form and requested a domain name "mediatheque-lecannet.fr" instead of "mediatheque.lecannet.fr". And the Certinomis RA operator did not notice that instead of a dot there was a dash.<br />
The employee who validated this request made an indisputable error, even though I am convinced that his vigilance would have been stronger for an unknown client.<br />
<br />
--> Responses to cause 3:<br />
<br />
- Action no. 5: for test certificates, the solution was to isolate the test organizations in a registration area where PTC SSL certificates are not available. This solution is now fully in place.<br />
<br />
- Action no. 6: Certinomis has developed a function for sending e-mails in accordance with BR 1.6.5 method 3.2.2.4.4 This function will be in production by May 15, and then it will no longer be possible for a human operator to add or validate a domain name without a positive response according to 3.2.2.4.4<br />
<br />
On these three main causes of problem, Certinomis has already started to act, certain actions have been completed (action n°2, action n°3, action n°5) one is partially completed (action n°1) and the others will be completed within a maximum of one month (action n°6) or two months (action n°4). And our efforts will not stop, other improvements are already in the works and will have to be added to our road map (implementation of method 3.2.2.4.6 for example).<br />
<br />
I don’t want to finish this answer without going back to the A issue, the Startcom cross-sign.<br />
I will not repeat all the history, Franck LEROY had detailed it in his e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of view: at no time did we in this case violate an existing rule, nor did we assist or seek to assist Startcom in circumventing the remediation plan proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand if what we wanted to do was acceptable, we clearly made it a condition for Iñigo to follow the plan and waited to be convinced that he had done so, and when, after all these precautions, we were told that we had not understood this remedial plan, we revoked both CAs without discussion.<br />
I hadn’t heard anything about it in those two years.<br />
So what is the factual criticism that is being made now, two years later? I don’t know about that.<br />
And what is the link with our difficulties of this year? None!<br />
<br />
In conclusion, I would like to remind you that Certinomis, although a modest player in the SSL business, is a respectably well-known company in France, qualified for several ranges of certificates, and which provides personal signature certificates for many organizations, large companies, ministries and local communities.<br />
<br />
This good reputation does not justify the errors that are currently highlighted.<br />
<br />
But this fame was not obtained by chance, and on the contrary, it is a testament to our know-how, our work and the rigour we put into it.<br />
<br />
And I believe that considering this is likely to reassure the Mozilla community and restore its confidence: It’s true that we have been initially destabilized by the barrage of questions and bug notifications that started just after the departure of our former technical director Franck LEROY.<br />
But the attention paid to this issue over the past three months and especially the rapid progress of our action plan show that we are taking these matters seriously and that we are able to play our role as a CA as well in the rules of the CA/B Forum than in the other rules to which we are subject.<br />
<br />
Kind Regards,<br />
<br />
François CHASSERY<br />
CEO<br />
Certinomis</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1211963CA/Certinomis Issues2019-05-07T22:59:26Z<p>Wthayer: /* Issue F: Non-BR-Compliant Certificate Issuance */ Add implementation of linting</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
<br />
[CERTINOMIS RESPONSE] On 6-May, 2019, Certinomis stated that pre issuance linting is now operational.<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.<br />
<br />
=== <s>Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline</s> ===<br />
The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious [https://cabforum.org/pipermail/public/2017-December/012630.html vulnerabilities that were identified]. This concern was communicated in Mozilla's [[CA/Communications#January_2018_CA_Communication|January 2018 and September 2018 CA Communications]]. In a [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 bug that was recently filed describing the issuance of a certificate containing an unregistered domain name], Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c9 Certinomis stated that BR method 3.2.2.4.5 was still in use].<br />
<br />
<br />
[CERTINOMIS RESPONSE] [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c12 Certinomis confirmed] that the following [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11 comment form a former employee], is correct:<br />
<br />
''I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).''<br />
<br />
''For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).''<br />
<br />
''Theses two validation methods were manual ones so subject to human errors.''<br />
''Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.''<br />
<br />
''This new automated validation feature were to be available by the end of 2018.''<br />
<br />
''I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).''</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1211962CA/Certinomis Issues2019-05-07T22:55:57Z<p>Wthayer: /* Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline */ Updated with Certinomis response</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.<br />
<br />
=== <s>Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline</s> ===<br />
The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious [https://cabforum.org/pipermail/public/2017-December/012630.html vulnerabilities that were identified]. This concern was communicated in Mozilla's [[CA/Communications#January_2018_CA_Communication|January 2018 and September 2018 CA Communications]]. In a [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 bug that was recently filed describing the issuance of a certificate containing an unregistered domain name], Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c9 Certinomis stated that BR method 3.2.2.4.5 was still in use].<br />
<br />
<br />
[CERTINOMIS RESPONSE] [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c12 Certinomis confirmed] that the following [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11 comment form a former employee], is correct:<br />
<br />
''I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).''<br />
<br />
''For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).''<br />
<br />
''Theses two validation methods were manual ones so subject to human errors.''<br />
''Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.''<br />
<br />
''This new automated validation feature were to be available by the end of 2018.''<br />
<br />
''I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).''</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1211206CA/Certinomis Issues2019-04-25T19:13:31Z<p>Wthayer: Add issue G</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.<br />
<br />
=== Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline ===<br />
The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious [https://cabforum.org/pipermail/public/2017-December/012630.html vulnerabilities that were identified]. This concern was communicated in Mozilla's [[CA/Communications#January_2018_CA_Communication|January 2018 and September 2018 CA Communications]]. In a [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 bug that was recently filed describing the issuance of a certificate containing an unregistered domain name], Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c9 Certinomis stated that BR method 3.2.2.4.5 was still in use].</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1211115CA/Certinomis Issues2019-04-23T20:42:08Z<p>Wthayer: /* Issue F.3: Inadequate Controls on Production Testing */ Add response to new test cert</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c21 full response])<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210887CA/Certinomis Issues2019-04-18T19:24:12Z<p>Wthayer: /* Issue F.1: SANs */ 18-April --> 17-April</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210885CA/Certinomis Issues2019-04-18T19:22:51Z<p>Wthayer: /* Issue F.3: Inadequate Controls on Production Testing */ discovered-->reported</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 18-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 reported]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210884CA/Certinomis Issues2019-04-18T19:22:18Z<p>Wthayer: /* Issue F.3: Inadequate Controls on Production Testing */ Add another O=Entreprise TEST" cert</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 18-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
On 17-April, 2019, [https://crt.sh/?sha256=97C78F92745645FE7ABC5A531C27F4C29D54F193563FB2035C01A0BE74CA3BBA another certificate] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 discovered]. This one contains "O=Entreprise TEST" and was issued in January, after [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c11 Certinomis stated] that such issuance had been stopped.<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210882CA/Certinomis Issues2019-04-18T19:15:25Z<p>Wthayer: /* Issue F.1: SANs */ Add another cert with space in SAN</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
On 18-April, 2019, [https://crt.sh/?sha256=965cc06fe73303e146d0f13a4e3ea76b4721d9dd95486f134c7d5e0fc5c8b576 another pre-certificate] having been issued on 17-April with a space character in the SAN was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 reported].<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210834CA/Certinomis Issues2019-04-17T21:11:38Z<p>Wthayer: /* Issue F.1: SANs */ Added new issue</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
On 16-April, 2019, a set of [https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 14 pre-certificates containing an unregistered domain name was reported]. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Maintenance_and_Enforcement&diff=1210772CA/Maintenance and Enforcement2019-04-16T18:43:47Z<p>Wthayer: /* Recurring Issues */ Add Certinomis</p>
<hr />
<div>= Maintaining Confidence in Root Certificates =<br />
<br />
Mozilla's efforts to maintain confidence in root certificates include:<br />
# Carefully reviewing [[CA/Application_Process|CA applications for root inclusion]].<br />
#* A Mozilla representative reviews relevant [https://wiki.mozilla.org/CA/Incident_Dashboard incident reports] and the CA’s responses<br />
#* A Mozilla representative checks the CA's CP/CPS documentation for<br />
#** compliance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy,]<br />
#** compliance with [https://wiki.mozilla.org/CA/Required_or_Recommended_Practices Mozilla's Required Practices], and<br />
#** avoidance of [https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices Mozilla's list of Forbidden Practices].<br />
#* A Mozilla representative confirms that the CA has been audited as per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#31-audits Mozilla's Root Store Policy.]<br />
# Keeping a record of current audit statements for each CA.<br />
#* [https://wiki.mozilla.org/CA/IncludedCertificates Link to the list of included root certs and their corresponding documentation and current audit statements].<br />
#* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#313-audit-parameters Mozilla's Root Store Policy] states that CAs must conduct period-of-time audits and provide updated publicly-available audit documentation no less frequently than annually.<br />
# Updating policies and practices as issues are found/realized, communicating updates and recommendations to CAs, and tracking CA responses to communications.<br />
#* [https://github.com/mozilla/pkipolicy/issues Issues list for Mozilla’s Root Store Policy]<br />
#* [https://wiki.mozilla.org/CA/Communications CA Communications]<br />
#* If a CA does not respond to Mozilla's communications within the timeframe specified in the communication or does not provide a copy of its annual audit statement within 15 months of the end of its previous annual audit period, then Mozilla may take action up to and including [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#73-removals removal of the root(s) from the program].<br />
# When a potential certificate mis-issuance is noticed by anyone, they should report it by [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance creating a bug in the CA Certificate Mis-issuance component]. More information on filing a security-sensitive bug can be found in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy.]<br />
<br />
When a security threat or potential certificate mis-issuance arises with a CA in Mozilla's program we consider the impact and risk to the end-users to decide on the action to take. The following considerations are taken into account:<br />
* Magnitude of the threat<br />
** How can the threat or mis-issuance be used by a hacker to put end-users at risk?<br />
** Has all appropriate action been taken by the CA to prevent further impact to end-users?<br />
** What additional actions does Mozilla need to take to protect end-users from the threat or mis-issuance?<br />
*** How will end-users be impacted by Mozilla actions?<br />
*** Can Mozilla take a different action that will protect end-users, but confine noticeable impact to the smallest group possible?<br />
*** Will Mozilla's actions have a worse impact on end-users than the current threat or mis-issuance?<br />
* CA behavior<br />
** Did the CA notice the error and take appropriate action in a timely manner?<br />
*** Was the threat or error properly contained?<br />
** Did the CA notice the hacker intrusion and take appropriate action in a timely manner?<br />
*** Were the CA's defense mechanisms current and sufficient?<br />
*** Was the intrusion appropriately contained?<br />
** Was the CA's behavior reckless?<br />
** Did the CA try to cover up the mistake/threat rather than follow [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy?]<br />
<br />
Mozilla relies on audit statements submitted by either the CA or an auditor to confirm a CA's compliance with Mozilla's [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy]. Statements obtained from an auditor are assumed legitimate. Audit statements provided by a CA are verified for legitimacy with the auditor. The<br />
qualifications of any auditors not previously approved by Mozilla are reviewed before an audit statement is accepted. Auditor qualifications are reviewed using the webtrust.org website or an appropriate government website. If the auditor claims to be AICPA/CICA/CISA accredited, but the<br />
auditor is not approved by Mozilla and not listed on a trusted website as accredited, then Mozilla will verify the auditor's qualifications with a representative of CICA or CISA, as appropriate.<br />
<br />
= Risks to Consumers =<br />
<br />
Possession of a mis-issued certificate alone does not allow an attacker to do anything. The attacker also needs some control over the victim's network connection. This means that the most likely attacks are either very localized (public WiFi, local network compromise) or very broad (governments). An attacker armed with a fraudulent certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. The end users could be deceived into revealing personal information such as usernames and passwords, or downloading malware (containing malicious content or software) if they believe it’s coming from a trusted site.<br />
<br />
An attacker armed with a fraudulent SSL certificate and an ability to control their victim’s network can:<br />
* Impersonate a valid website -- Present a fake website that looks like a valid website, and make the browser believe it is the real version of the website, because the browser finds that the SSL certificate of the fake site is valid.<br />
* Re-direct users to a fake site -- Users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for the legitimate sites.<br />
** In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing) and the HTTPS connection may never happen. Many users might not notice this and end up logging into an attacker’s website.<br />
<br />
= Potential Problems, Prevention, Response=<br />
While [[CA/Responding_To_An_Incident|CA incidents]] have differing levels of severity, there are some components which every CA should be able to avoid which are red flags for Mozilla in terms of a continued trust relationship, and which would lead to an investigation. They are:<br />
* Deliberate violation of Mozilla or other applicable policy<br />
* Lying or deception<br />
* Concealing or failing to disclose the full extent of a problem<br />
Mozilla will also assess how concerned we are about an issue in part based on how the CA reacts to that issue, and previous ones. In incident response, Mozilla is looking for the following factors:<br />
* A CA takes responsibility for their own actions.<br />
* Incidents are taken with an appropriate level of seriousness.<br />
* Incidents are handled with urgency.<br />
* Root cause analysis is performed.<br />
* Any questions posed, by anyone, are answered quickly and in detail.<br />
* A reasonably-detailed [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report] is made public on what happened, why, and how things have changed to make sure it won’t happen again.<br />
<br />
The following is an enumeration of some of the different kinds of problems that may occur, and what our prevention or immediate response to those problems should be, as long as the CA is demonstrating responsibility and integrity as described above. This is not about meting out punishment, and is not intended to be punitive. Rather, when there is evidence of one of the problems below with a certificate chaining up to a CA in Mozilla's CA Certificate program, we need to take the necessary steps to keep users safe.<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] describes the steps that Mozilla takes to evaluate and respond to security concerns related to certificate operation and issuance. The following list may be used as a guideline of what to expect when certain types of issues are found, but this list is non-binding because the necessary actions and responses will vary depending on the situation.<br />
<br />
'''Problem:''' CA mis-issued a small number of SSL certificates that they can enumerate<br />
* Immediate Minimum Response: Open a [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance CA compliance] and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].<br />
* Depending on the situation, also consider adding the certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].<br />
<br />
'''Problem:''' CA mis-issued a small number of email certificates that they can enumerate<br />
* Immediate Minimum Response: Actively distrust that set of email certificates in Thunderbird, and push out an update to Thunderbird.<br />
* Depending on the situation, also consider distrusting the intermediate or root certificate that the mis-issued certificates chain up to.<br />
<br />
'''Problem:''' CA mis-issued a large number (e.g. hundreds) of end-entity certificates that they can enumerate<br />
* Immediate Minimum Response: Open a [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance CA compliance] and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].<br />
* Depending on the situation, also consider adding the intermediate CA certificate(s) to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL], distrusting the root certificate that the mis-issued certificates chain up to, or all of the root certificates owned by that CA.<br />
<br />
'''Problem:''' CA mis-issued an unknown number of un-enumerated end-entity certificates<br />
* Immediate Minimum Response: Actively distrust the intermediate and root certificates that the mis-issued certificates chain up to, and push out an update to all Mozilla products.<br />
* Depending on the situation, also consider distrusting all of the root certificates owned by that CA.<br />
<br />
'''Problem:''' CA mis-issued a small number of intermediate certificates that they can enumerate<br />
* Immediate Minimum Response: Actively distrust the intermediate certificates, and push out an update to all Mozilla products.<br />
* Depending on the situation, also consider distrusting the root certificate or all of the root certificates owned by that CA.<br />
<br />
'''Problem:''' CA mis-issued an unknown number of un-enumerated intermediate certificates<br />
* Immediate Minimum Response: Actively distrust the root certificate, and push out an update to all Mozilla products.<br />
* Depending on the situation, also consider distrusting all of the root certificates owned by that CA.<br />
<br />
'''Problem:''' CA failed to supply proper audit documentation, or audit report contains numerous and/or serious qualifications<br />
* Immediate Minimum Response: File a [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance CA compliance] bug, request that the CA respond with remediation plans, and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report]<br />
* Depending on the situation, also consider requiring the CA to undergo new period-of-time audits as soon as the problems have been resolved. If the same problems are included on the new audit reports, they must state the dates on which the problems were resolved.<br />
<br />
= Recurring Issues =<br />
In addition to evaluating the severity of a specific incident, Mozilla considers the totality of known issues and patterns of behavior in a CA's response to those issues. When Mozilla believes that sufficient evidence is available to establish an ongoing pattern of neglect or incompetence, an Issues List may be created. Mozilla will compile the facts of known problems of a particular CA and create a wiki page listing them. Mozilla may then ask the community to consider a response to the combined set of issues based on the perceived risk to users. This response typically involves distrust of the CA's currently included roots, or requiring the CA to undergo more frequent audits until the Mozilla community’s trust in the CA has been adequately restored.<br />
<br />
'''Issues Lists'''<br />
* https://wiki.mozilla.org/CA:PROCERT_Issues<br />
* https://wiki.mozilla.org/CA:Symantec_Issues<br />
* https://wiki.mozilla.org/CA:WoSign_Issues<br />
* https://wiki.mozilla.org/CA:Visa_Issues<br />
* https://wiki.mozilla.org/CA/Certinomis_Issues<br />
<br />
= Actively Distrusting a Certificate =<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] and the [https://cabforum.org/baseline-requirements/ CA/Browser Forum's Baseline Requirements] list some of the reasons why a certificate should be revoked. For the common revocations, CRL and OCSP revocation checking are sufficient. However, in extenuating circumstances, such as those listed above, Mozilla may take additional action to protect users by actively distrusting a certificate.<br />
<br />
The steps to actively distrust a certificate are as follows.<br />
# Report security concern<br />
#* When a serious security concern is noticed, such as a root or intermediate certificate compromise, it should be treated as a security-sensitive bug, and the [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs] should be followed.<br />
#* As per [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs] a security concern may be reported by sending email to [mailto:security@mozilla.org security@mozilla.org] or by [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security&bug_severity=critical filing a bug.]<br />
# Decide on course of action<br />
#* See [https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Potential_Problems.2C_Prevention.2C_Response Immediate Minimum Responses] above.<br />
#* Depending on the situation, discussion to determine the course of action may occur in private security group email list and/or in the public mozilla.dev.security.policy forum.<br />
#* The bug will be updated to indicate corresponding decisions.<br />
# Measure Impact of Change<br />
#* Check Firefox telemetry for usage data of the affected root certificate<br />
#* Run [https://tlscanary.mozilla.org/ TLS Canary] in regression mode to determine which websites will be affected.<br />
# Implement Code Change<br />
#* Add the corresponding intermediate or end-entity certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].<br />
#* If it is determined that a certificate needs to be actively distrusted in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS], then the following may also be done.<br />
#** Update [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] by adding a new entry to the built-in root cert list, to take away trust instead of giving trust. This is done with a separate "distrust" flag, and is called '''Active Distrust'''. Active Distrust can be done for any root, intermediate, or leaf certificate. Active Distrust does not require the entire certificate, because it may be done with a combination of the certificate Serial Number and Issuer. Note: The built-in cert list has two types of entries; cert entries and trust entries. A (dis)trust entry can be added without adding a corresponding cert entry.<br />
#** A problem with this approach arises if the certificate to be Actively Distrusted has been cross-signed with another root certificate that is included in NSS. This could lead us to have to ask every CA in Mozilla's program if they have cross-signed with the root or intermediate certificate that is to be Actively Distrusted. If there is such cross-signing, then the change to the built-in root cert list will also have to include the Issuer/Serial number combination for the cross-signed certificate chain.<br />
# Test<br />
#* Manual testing: Need at least one of the bad leaf certs to make sure the distrust worked.<br />
#* Add test to cert.sh (NSS test file) for the ongoing test of the Active Distrust. At minimum, need the intermediate cert for this test. Preferable to also have a leaf cert, which may have been provided when the compromised cert was reported; otherwise would need to request from the CA.<br />
# Release<br />
#* NSS security update, or new version of NSS roots module can be released independently.<br />
#* Depending on the timing and the urgency of the patch, the update may be done either as part of regularly scheduled [https://wiki.mozilla.org/Releases Mozilla releases,] or as a chemspill update (an off-schedule release that addresses live security vulnerabilities). Some Linux users of Firefox use their OS version of NSS, so they would have to make sure that they pick up the [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases new version of NSS].<br />
# Communication / Announcements<br />
#* Announcement in [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy]<br />
#* If the Active Distrust is the result of a security incident, then the Mozilla Security Group will assign a [http://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures CVE (security incident number)] and reference the new version of NSS or root module.<br />
#* May send an email communication to all CAs, depending on situation.<br />
#* May post in [https://blog.mozilla.org/security/ Mozilla security blog,] depending on situation.<br />
# Result<br />
#* Users will get an error message when they try to browse to a website that uses (or chains up to) the Actively Distrusted certificate.<br />
#* If a cert entry was added to the NSS built-in root cert list, then the Certificate Manager displays the Actively Distrusted certificate in the same manner as other certificates, and the trust bits may be manually turned on by users.<br />
<br />
= Concerns =<br />
<br />
* Certs that have been mistakenly issued with insufficient key usage can be used maliciously until we implement {{Bug|725351}}.<br />
* The code patch to distrust a cert should only disclose the necessary information; {{Bug|826640}}.<br />
* If the certificate to be distrusted is cross-signed by another certificate in NSS, then the Serial Number and Issuer for that certificate chain also has to be distrusted. This is error-prone, even if we ask every CA in Mozilla's program if they have cross-signed with the certificate to be distrusted.<br />
** Possible Scenario: A cross-signing relationship is overlooked, so the malicious certificate continues to be trusted even after the security update.<br />
** Possible Solution: {{Bug|808839}} - Ability to Actively Distrust all certs with a particular Subject.<br />
* The Certificate Manager does not recognize the "distrust" flag, so there is no distinction in the user interface between certificates that have been Actively Distrusted in NSS and all other certificates. The distrusted certificate(s) should also be added to OneCRL, so the certificate(s) will still be distrusted even if the user manually turns on the trust bits for Actively Distrusted certificates.<br />
** Possible Scenario: User confusion about Actively Distrusted certs listed in the Certificate Manager.<br />
** Possible Solutions: {{Bug|470994}}, {{Bug|733716}}. For Actively Distrusted certs, remove the cert entry from the NSS built-in cert list, and only keep the (dis)trust entry.<br />
* If the certificate to be Actively Distrusted is used by a large portion of the internet population, immediately distrusting the certificate could make many high-traffic websites no longer be reachable, giving the appearance of a large network outage, or users might take actions (such as permanently trusting the bad cert) to bypass error messages.<br />
** Possible Scenario: A root certificate that is chained to by many high-traffic websites is compromised and has to be Actively Distrusted. This is done and an update to Firefox pushed out. Then a large number of users can no longer browse to the high-traffic websites, giving the appearance of an outage, costing those high-traffic websites loss in money, causing frustration and confusion to end users who are regular customers of those websites. Many end-users are likely to manually-override the error, permanently trusting the certificate. Then if they later accidentally browse one of the corresponding malicious websites, they will not get an error.<br />
** Possible Solutions: Implement date-based distrust {{Bug|712615}}, a whitelist of certs to remain trusted {{Bug|1151512}}, or make an announcement that the root will be distrusted on such a date, allowing a small transition time for websites to update their SSL certs before before the Firefox chemspill update is released.<br />
* Distrusting a certificate requires a release to the NSS root module, and users have to choose to upgrade to the new version. Firefox users are protected from distrusted certificates that are added to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident&diff=1210671CA/Responding To An Incident2019-04-15T23:36:33Z<p>Wthayer: /* Revocation */ Responding to Ryan Sleevi's feedback on MDSP</p>
<hr />
<div>The page gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. <br />
<br />
For the purposes of this page, a "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. Researchers who report CA incidents such as misissuances are welcome to include a link to this page in their report to the CA, reminding the CA that Mozilla has the following expectations. This document is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained therein.<br />
<br />
Other examples of incidents include misconfigured OCSP responders, un-revocations, and any other event affecting trust in the WebPKI which does not involve the actual contents of certificates.<br />
<br />
While some forms of incident may be seen as less serious than others, opinions vary on which these are. Mozilla sees all incidents as good opportunities for the CA to test that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity.<br />
<br />
To be clear on the status of this document: this is a best practices document, not an official policy, and does not use normative language. Therefore, failure to follow one or more of the recommendations here is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response. <br />
<br />
= Immediate Actions =<br />
<br />
In misussuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI until you have diagnosed the source of the problem, or explain why this has not been done.<br />
<br />
Once the problem is diagnosed, you may restart issuance even if a full fix is not rolled out, if you are able to put in place temporary or manual procedures to prevent the problem from re-occurring. You should not restart issuance until you are confident that the problem will not re-occur.<br />
<br />
= Revocation =<br />
<br />
It is normal practice for CAs to revoke misissued certificates. But that leaves the question about '''when''' this should be done, particularly if it's not possible to contact the customer immediately, or if they are unable to replace their certificate quickly. Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements currently states (version 1.6.3):<br />
<br />
<blockquote><br />
“The CA SHOULD revoke a Certificate within 24 hours and MUST revoke a Certificate with 5 days if one or more of the following occurs: …<br><br />
7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;<br><br />
8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; …<br><br />
10. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or<br><br />
11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the Private Key was flawed."<br />
</blockquote><br />
<br />
This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 5 days.<br />
<br />
Mozilla recognizes that in some '''exceptional''' circumstances, revoking misissued certificates within the prescribed deadline may cause significant harm, such as when the certificate is used in critical infrastructure and cannot be safely replaced prior to the revocation deadline, or when the volume of revocations in a short period of time would result in a large cumulative impact to the web. However, Mozilla does not grant exceptions to the BR revocation requirements. It is our position that your CA is ultimately responsible for deciding if the harm caused by following the requirements of BR section 4.9.1 outweighs the risks that are passed on to individuals who rely on the web PKI by choosing not to meet this requirement.<br />
<br />
If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that:<br />
<br />
* The decision and rationale for delaying revocation will be disclosed to Mozilla in the form of a preliminary incident report immediately; preferably before the BR mandated revocation deadline. The rationale must include an explanation for why the situation is exceptional. Responses similar to “we deem this misissuance not to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.<br />
* Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a clear timeline describing if and when the problematic certificates will be revoked or expire naturally, and supported by the rationale to delay revocation.<br />
* The issue will need to be listed as a finding in your CA’s next BR audit statement.<br />
* Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.<br />
* That you will perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays.<br />
<br />
If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.<br />
<br />
= Follow-Up Actions =<br />
<br />
* Work out how the bug or problem was introduced. For a code bug, were the code review processes sufficient? Does your code have automated tests, and if so, why did they not catch this case?<br />
<br />
* Work out why the problem was not detected earlier. Were these certificates missed by your self-audits? Or is the code or process you use for such audits insufficiently frequent or rigorous?<br />
<br />
* If the problem is lack of compliance to an RFC, Baseline Requirement or Mozilla Policy requirement: were you aware of this requirement? If not, why not? If so, was an attempt made to meet it? If not, why not? If so, why was that attempt flawed? Do any processes need updating for making sure your CA complies with the latest version of the various requirements placed upon it?<br />
<br />
* Scan your corpus of certificates to look for others with the same issue. It does not look good for a CA to claim they have revoked all affected certificates and resolved the issue, and then for a researcher to discover another set of certificates with the same or a similar problem.<br />
<br />
* Examine whether there are potential related problems which you can also remediate at the same time. For example, if the problem was bad data in a particular field, consider improving the validation of all fields in the certificate prior to issuance. You should be proactively looking for [https://crt.sh/linttbscert ways] to harden your issuance pipeline against further problems.<br />
<br />
* If, as happens in a regrettably large number of cases, a problem report was sent to your CA but action in accordance with BR section 9.4.5 was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate.<br />
<br />
= Incident Report =<br />
<br />
The purpose of incident reporting is to help all of us work together to build a more<br />
secure web. Therefore, the incident report should share lessons learned that could be helpful to all CAs to build better systems. The incident report should explain how the systems failed, how was the mis-issuance or incident possible, and why the problem was not detected earlier. In addition to the timeline of responding to and resolving the incident, the incident report should explain how the CA's systems will be made more robust, and how other CAs may learn from the incident.<br />
<br />
Each incident should result in an incident report, written as soon as the problem is fully diagnosed and (temporary or permanent) measures have been put in place to make sure it will not re-occur. If the permanent fix is going to take significant time to implement, you should not wait until this is done before issuing the report. We expect to see incident reports as soon as possible, and certainly within two weeks of the initial issue report. While remediation work may still be ongoing, a satisfactory incident report will serve to resolve the issue from a Mozilla perspective. <br />
<br />
The incident report may well repeat things which have been said previously in discussions or bug comments. This is entirely expected. The report should be a summary of previous findings. The existence of data in discussions or bug comments does not excuse a CA from the task of compiling a proper incident report.<br />
<br />
Your CA may submit an incident report by creating a bug in Bugzilla under the NSS:CA Certificate Compliance component, or by posting the report to the mozilla.dev.security.policy mailing list. If an incident report is sent to the list without a corresponding bug, a new one will be created to track the incident.<br />
<br />
The incident report should cover at least the following topics:<br />
<br />
# How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.<br />
# A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.<br />
# Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.<br />
# A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.<br />
# The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.<br />
# Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.<br />
# List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.<br />
<br />
= Keeping Us Informed =<br />
<br />
Once the report is posted, you should respond promptly to questions that are asked, and in no circumstances should a question linger without a response for more than one week, even if the response is only to acknowledge the question and provide a later date when an answer will be delivered. You should also provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless Mozilla representatives agree to a different schedule by setting a “Next Update” date in the “Whiteboard” field of the bug. Such updates should be posted to the m.d.s.p. thread, if there is one, and the Bugzilla bug. The bug will be closed when remediation is completed.<br />
<br />
= Examples of Good Practice =<br />
<br />
Here are some examples of good practice, where a CA did most or all of the things recommended above.<br />
<br />
== Let's Encrypt Unicode Normalization Compliance Incident ==<br />
<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g6_zGA2exXw Initial Public Problem Report], 2017-08-10 20:23 UTC (apparently LE were made aware of the problem privately earlier that day)<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/_tXldrbIBwAJ Initial Public Response from CA], 2017-08-10 21:53 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJY Final Report from CA], 2017-08-11 03:00 UTC<br />
<br />
In this case, the CA managed to diagnose the problem, remediate it, and deploy the fix to production within 24 hours.<br />
<br />
== PKIOverheid Short Serial Number Incident ==<br />
<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ Initial Public Problem Report], 2017-07-18 22:26 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/TzH5eI9dAQAJ Initial Public Response from CA], 2017-07-25 19:20 UTC<br />
* [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ Final Report from CA], 2017-08-11 14:39 UTC<br />
<br />
While the CA could have provided interim updates, and the final report was a little delayed, the contents of it were excellent.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210444CA/Certinomis Issues2019-04-11T21:54:57Z<p>Wthayer: Updated based on KW review</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== Issue A: StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== Issue B: Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In early 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== Issue C: Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== Issue D: CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.<br />
** "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."<br />
* A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== Issue E: Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== Issue F: Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of [https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=Certinomis&query_format=advanced&component=CA%20Certificate%20Compliance&product=NSS&list_id=14663508 13 misissuance bugs] since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451#c5 stated that it is still some months away].<br />
<br />
==== Issue F.1: SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128#c13 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c2 another certificate was misissued, this one containing an empty SAN value]. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 incident report for that issue] disclosed one more nearly identical certificate issued 3 days later.<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."<br />
<br />
==== Issue F.2: Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== Issue F.3: Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
==== Issue F.4: Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== Issue F.5: Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210442CA/Certinomis Issues2019-04-11T21:27:18Z<p>Wthayer: /* C Audit Issues (2015-2018) */ Add LSTI comments</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== A StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== B Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In January 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== C Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements], and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.<br />
<br />
=== D CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* States that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5 (latter is probably a typo since it refers to ‘website change’), which have been forbidden since 1-August, 2018.<br />
* A thoroughly review the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== E Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== F Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of 13 misissuance bugs since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 stated that it is still some months away].<br />
<br />
==== 1 SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 another certificate was misissued, this one containing an empty SAN value].<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values.<br />
<br />
==== 2 Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== 3 Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
==== 4 Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== 5 Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210423CA/Certinomis Issues2019-04-11T18:12:03Z<p>Wthayer: Edits</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== A StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== B Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
<br />
In January 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== C Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements].<br />
<br />
=== D CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* States that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5 (latter is probably a typo since it refers to ‘website change’), which have been forbidden since 1-August, 2018.<br />
* A thoroughly review the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== E Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== F Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of 13 misissuance bugs since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 stated that it is still some months away].<br />
<br />
==== 1 SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 another certificate was misissued, this one containing an empty SAN value].<br />
<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values.<br />
<br />
==== 2 Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== 3 Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
==== 4 Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== 5 Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210419CA/Certinomis Issues2019-04-11T18:06:49Z<p>Wthayer: /* F Non-BR-Compliant Certificate Issuance */ fix date</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== A StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== B Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
In January 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== C Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements].<br />
<br />
=== D CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* States that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5 (latter is probably a typo since it refers to ‘website change’), which have been forbidden since 1-August, 2018.<br />
* A thoroughly review the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== E Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== F Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of 13 misissuance bugs since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 stated that it is still some months away].<br />
<br />
==== 1 SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 another certificate was misissued, this one containing an empty SAN value].<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values.<br />
<br />
==== 2 Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== 3 Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
==== 4 Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== 5 Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210418CA/Certinomis Issues2019-04-11T18:03:03Z<p>Wthayer: /* D CP/CPS Non-conformities (Present) */ rewording</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== A StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== B Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
In January 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== C Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements].<br />
<br />
=== D CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* States that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5 (latter is probably a typo since it refers to ‘website change’), which have been forbidden since 1-August, 2018.<br />
* A thoroughly review the current version of the CPS has not been completed because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== E Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== F Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of 13 misissuance bugs since 2018. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 stated that it is still some months away].<br />
<br />
==== 1 SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 another certificate was misissued, this one containing an empty SAN value].<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values.<br />
<br />
==== 2 Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== 3 Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
==== 4 Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== 5 Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210417CA/Certinomis Issues2019-04-11T18:01:29Z<p>Wthayer: /* D CP/CPS Non-conformities (Present) */ reformat date</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== A StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== B Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
In January 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== C Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements].<br />
<br />
=== D CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated 25-November, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* States that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5 (latter is probably a typo since it refers to ‘website change’), which have been forbidden since 1-August, 2018.<br />
* I have not been able to thoroughly review the current version of the CPS because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== E Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== F Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of 13 misissuance bugs since 2018. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 stated that it is still some months away].<br />
<br />
==== 1 SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 another certificate was misissued, this one containing an empty SAN value].<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values.<br />
<br />
==== 2 Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== 3 Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
==== 4 Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== 5 Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Certinomis_Issues&diff=1210415CA/Certinomis Issues2019-04-11T17:37:11Z<p>Wthayer: Initial page creation</p>
<hr />
<div>This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.<br />
<br />
Certinomis currently has a single root certificate in the Mozilla program The “[https://crt.sh/?caid=5676 Certinomis - Root CA]” was included in 2015 via [https://bugzilla.mozilla.org/show_bug.cgi?id=1169083 bug #1169083] with only the websites trust bit set. The root is not EV-capable.<br />
<br />
=== A StartCom Cross-signing (2017) ===<br />
In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 StartCom had been recently distrusted] and was [https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ misissuing test certificates from this new, replacement hierarchy]. These cross-certificates were not disclosed until 111 days after being issued (the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited current one-week rule] was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their [https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 remediation plan] before they could request reinclusion. The Certinomis cross-certificates were ultimately [https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ added to OneCRL and revoked by Certinomis].<br />
<br />
=== B Lack of Responsiveness (2018 - Present) ===<br />
In a 2017 misissuance bug, Cartinomis was [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978#c19 called out for letting more than a month pass without providing a timeline for complying with the BRs].<br />
<br />
In January 2018, Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1439126 failed to respond] to a [[CA/Communications#January_2018_CA_Communication|Mozilla CA Communication]]. Certinomis was also late in responding to the prior [[CA/Communications#November_2017_CA_Communication|November 2017 survey]] and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.<br />
<br />
In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 bug #1496088] (comments 12-17) ; [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 bug #1495524] (comments 6 and 7) ; and [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 bug #1503128] (comments 2 and 7).<br />
<br />
=== C Audit Issues (2015-2018) ===<br />
There are gaps in Certinomis’ audit coverage dating back to at least 2016. The [https://bug937589.bmoattachments.org/attachment.cgi?id=8652034 2015 assessment report] is dated 28-April 2015, but the [https://bugzilla.mozilla.org/attachment.cgi?id=8784555 2016 assessment report] covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The [https://bugzilla.mozilla.org/attachment.cgi?id=8898169 2017 assessment report] states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.<br />
<br />
The [https://bugzilla.mozilla.org/attachment.cgi?id=9027927 2018 assessment report] was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. [https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/ptUw6kZhBQAJ Certinomis stated that LSTI was at fault for the late audit statements].<br />
<br />
=== D CP/CPS Non-conformities (Present) ===<br />
The current version of the [https://www.certinomis.fr/publi/rgs/DT-FL-1310-220-PC-SERVEUR-1.9.pdf Certinomis CPS] which was updated November 25, 2018, does not comply with the Baseline Requirements:<br />
* Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs<br />
* States that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5 (latter is probably a typo since it refers to ‘website change’), which have been forbidden since 1-August, 2018.<br />
* I have not been able to thoroughly review the current version of the CPS because it is only published in French, in violation of a [[CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS|Mozilla required practice]].<br />
<br />
=== E Non-BR-Compliant OCSP Responders (2017) ===<br />
Certinomis was one of a number of CAs whose OCSP responders were [https://bugzilla.mozilla.org/show_bug.cgi?id=1425998 violating the BRs by returning “good” in response to a request for an unknown certificate]. The effective date for this BR requirement in section 4.9.10 was August 2013.<br />
<br />
=== F Non-BR-Compliant Certificate Issuance ===<br />
Certinomis has accumulated a total of 13 misissuance bugs since 2018. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 stated that it is still some months away].<br />
<br />
==== 1 SANs ====<br />
In August 2017, Certinomis’ [https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 first CA compliance bug was filed]. The errors were:<br />
* Email address in DNSName in SAN<br />
* Spaces in DNSName in SAN<br />
* Serial numbers longer than 20 octets<br />
<br />
On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.<br />
<br />
On 1-October, 2018, a precertificate with a SAN containing only “www” was [https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 reported]. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.<br />
<br />
On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were [https://bugzilla.mozilla.org/show_bug.cgi?id=1503128 reported]. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328 disclosed two newly misissued certificates containing an invalid TLD in a SAN]. The subsequent [https://bugzilla.mozilla.org/show_bug.cgi?id=1542328#c0 incident report] disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day [https://bugzilla.mozilla.org/show_bug.cgi?id=1542793 another certificate was misissued, this one containing an empty SAN value].<br />
<br />
Another similar set of misissued certificates was [https://bugzilla.mozilla.org/show_bug.cgi?id=1539531 reported] on 27-March, 2019. These 10 certificates contain spaces in SAN values.<br />
<br />
==== 2 Subject Organization ====<br />
On 30-January, 2019, it was reported that Certinomis [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103 issued 4 certificates containing invalid State or Locality information]. On 1-February, 2019, another misissuance in which the [https://crt.sh/?id=405372511 StateorProvinceName field contains “Direction des systèmes d'informations”] was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5 reported] and was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.<br />
<br />
==== 3 Inadequate Controls on Production Testing ====<br />
On 31-January, 2019, [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448 bug #1524448 reported] that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the [https://bugzilla.mozilla.org/show_bug.cgi?id=1524448#c3 incident report] is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”<br />
<br />
[https://bugzilla.mozilla.org/show_bug.cgi?id=1524112 Bug #1524112] filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The [https://bugzilla.mozilla.org/show_bug.cgi?id=1524112#c2 initial response from Certinomis] stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.<br />
<br />
A very similar problem had originally been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 brought to Certinomis’ attention] back on 3-October, 2018. That problem had also been [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c2 blamed on human error]. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c18 reported] to be “running on pre-production platform” in February.<br />
<br />
==== 4 Validity > 825 Days ====<br />
On June 26, 2018, Certinomis issued a [https://crt.sh/?opt=zlint&id=562748119 certificate] with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449 bug #1524449 was filed] in January. Part of the resulting [https://bugzilla.mozilla.org/show_bug.cgi?id=1524449#c2 incident report] explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”<br />
<br />
==== 5 Invalid CDP Extension ====<br />
On 31-January, 2019, it was [https://bugzilla.mozilla.org/show_bug.cgi?id=1524451 reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension]. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Required_or_Recommended_Practices&diff=1209900CA/Required or Recommended Practices2019-04-01T23:00:37Z<p>Wthayer: /* Baseline Requirements */ Fix typos</p>
<hr />
<div>This page contains a set of practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are required by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and so are mandatory for a CA to have its root certificate(s) included. They are listed here because they are things CAs often get wrong. In other cases the practices are only recommended, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.<br />
<br />
== Required Practices ==<br />
<br />
=== Publicly Available CP and CPS ===<br />
<br />
CAs must supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.<br />
<br />
* The CP/CPS must be publicly available from the CA's official web site.<br />
* The CP/CPS must clearly indicate which root and subordinate certificates the practices and processes described in those documents apply to.<br />
* The format of the CP/CPS document must be PDF or another suitable format for reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.<br />
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.<br />
* The CA must provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.<br />
<br />
===== CP/CPS Revision Table =====<br />
<br />
Section 3.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] states: "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document."<br />
<br />
===== CAA Domains listed in CP/CPS =====<br />
<br />
Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs] states: "CA's Certificate Policy and/or Certification Practice<br />
Statement ... '''shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA''' "issue" or<br />
"issuewild" records as permitting it to issue.<br />
<br />
===== BR Commitment to Comply statement in CP/CPS =====<br />
<br />
For root certificates with the Websites (TLS/SSL) trust bit enabled, Mozilla requires the corresponding CP/CPS documents to include a statement of commitment to comply with the CA/Browser Forum's Baseline Requirements, as per section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs.]<br />
<br />
===== CP/CPS Structured According to RFC 3647 =====<br />
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements, with the effective of 31 May 2018. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.<br />
* The words "''No Stipulation''" mean that the particular document imposes no requirements related to that section. <br />
** Note that Mozilla's root store policy may be updated soon to forbid the use of "No Stipulation" in CP/CPS documents. <br />
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred. <br />
* Sections should not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional.<br />
** Note that Mozilla's root store policy may be updated soon to forbid blank sections in CP/CPS documents. <br />
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. Cross-referencing between CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.<br />
* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to SSL certificates.<br />
<br />
Examples:<br />
* If your CA does not allow a particular domain validation method to be used, then the CP or CPS should say that, e.g. "This method of domain validation is not used".<br />
* If your CP delegates requirements to one or more CPSs, then the CP should state "Refer to CPS".<br />
* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for SSL certs, and then the other sections related to suspension should say “Not applicable”.<br />
* If your CA does not issue SSL certs containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed; e.g. “No IP address certificates are issued under this CPS.”<br />
* If your CP contains the full description of section 5, then the CPS may say "As stipulated in section 5 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)<br />
<br />
===== CP/CPS Documents will be Reviewed! =====<br />
<br />
During the [[CA/Application_Verification#Detailed_Review|Detailed Review]] phase, <br />
your CP/CPS documentation will be thoroughly reviewed and commented on. Concerns raised by the reviewer must be sufficiently resolved before the request will be allowed to enter [[CA/Application_Verification#Public_discussion|public discussion]]. <br />
<br />
Here are some examples of previous reviews of CP/CPS documents:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]<br />
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]<br />
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.<br />
<br />
=== Audit Criteria ===<br />
<br />
CAs must supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.<br />
<br />
* The CA must indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).<br />
* All documents supplied as evidence must be publicly available.<br />
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).<br />
<br />
==== Complete Audit History ====<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#71-inclusions Mozilla's Root Store Policy] states: "Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements."<br />
<br />
This requirement may be met via one of the following options:<br />
* Providing the sequence of audit statements on the CA's website.<br />
* Attaching the sequence of audit statements to the root inclusion request (Bugzilla Bug).<br />
<br />
=== Revocation of Compromised Certificates ===<br />
<br />
CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.<br />
<br />
=== Verifying Domain Name Ownership ===<br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has registered all domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf. This must be done using one or more of the methods documented in section 3.2.2.4 of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with. CAs are not permitted to use 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address)."<br />
<br />
The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.<br />
<br />
===== Baseline Requirements =====<br />
<br />
It is '''not''' sufficient to simply reference section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements (BR)]. The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 3.2.2.4 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. Section 2.3 of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes '''in detail''' how the CA implements the latest version of these Requirements."<br />
<br />
'''Important:'''<br />
* The CPS should state what the CA actually does, not what it could do. Such as which of the allowed domain validation methods the CA uses.<br />
* BR subsections 3.2.2.4.1 and 3.2.2.4.5 were banned effective 1-August-2018.<br />
** "CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods"<br />
* BR subsection 3.2.2.9 was banned by ballot SC15, effective 16-March 2019.<br />
* BR subsection 3.2.2.4.10 contains major vulnerabilities. If the CA uses this method, then the CA should describe how they are mitigating those vulnerabilities. If not using this method, the CPS should say so.<br />
* BR section 3.2.2.5(4) was updated by ballot SC7 to remove "any other method", effective 1-August 2019. Prior to that date:<br />
** Saying the CA follows BR section 3.2.2.5 does not meet [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's disclosure requirements for this method]. The CPS must describe if/how "any other method" is implemented.<br />
** BR subsection 3.2.2.5(4) "any other method" is not permitted in conjunction with 3.2.2.4.8 per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's Root Store Policy]. The CPS should be clear that they do not do that.<br />
<br />
===== WHOIS =====<br />
<br />
[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking <br />
ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.<br />
<br />
It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?<br />
<br />
===== Email Challenge-Response =====<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. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]<br />
<br />
CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to cause and obtain certificates for example.com. Please work with your engineering department to ensure your systems properly handle such cases, as well as handling productions such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.<br />
<br />
=== Verifying Email Address Control === <br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."<br />
<br />
The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.<br />
<br />
The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.<br />
<br />
It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.<br />
<br />
=== DNS names go in SAN ===<br />
<br />
According to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements:]<br />
* Section 7.1.4.2.1 states:<br />
** Certificate Field: '''extensions:subjectAltName'''<br />
** Required/Optional: '''Required'''<br />
** Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.<br />
* Section 7.1.4.2.2 states:<br />
** Certificate Field: '''subject:commonName''' (OID 2.5.4.3)<br />
** Required/Optional: Deprecated ('''Discouraged''', but not prohibited)<br />
** Contents: If present, this field '''MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension''' (see Section 7.1.4.2.1).<br />
<br />
=== OCSP ===<br />
<br />
OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80. <br />
<br />
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements]:<br />
# The OCSP URI must be provided in the certificate, except when OCSP stapling is used. (sections 7.1.2.2, 7.1.2.3)<br />
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (section 4.9.10)<br />
# OCSP Responses shall be updated at least every four days and have a maximum expiration time of ten days (section 4.9.10)<br />
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (section 7.1.3)<br />
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (section 4.9.9)<br />
<br />
You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:<br />
* Go to Firefox -> Preferences... -> Privacy & Security -> Certificates<br />
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"<br />
* You may need to clear your history cache<br />
* Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.<br />
<br />
=== Network Security Controls ===<br />
<br />
CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.<br />
<br />
It is expected that CAs do the following on a regular basis:<br />
* Maintain network security controls that at minimum meet the [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements.]<br />
* Check for mis-issuance of certificates, especially for high-profile domains.<br />
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.<br />
* Ensure Intrusion Detection System and other monitoring software is up-to-date.<br />
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.<br />
<br />
== Recommended Practices ==<br />
<br />
=== CA Hierarchy ===<br />
<br />
A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See [[CA:Recommendations_for_Roots]].<br />
<br />
CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:<br />
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs<br />
* The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.<br />
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.<br />
<br />
We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).<br />
<br />
=== Document Handling of IDNs in CP/CPS ===<br />
<br />
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)<br />
<br />
=== Usage of Appropriate Constraints ===<br />
<br />
Root certificates in Mozilla's program can have either the SSL trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.<br />
<br />
=== Pre-Issuance Linting ===<br />
<br />
Recently, several tools have been developed ([https://github.com/awslabs/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Required_or_Recommended_Practices&diff=1209899CA/Required or Recommended Practices2019-04-01T22:59:25Z<p>Wthayer: /* Baseline Requirements */ Update BR references</p>
<hr />
<div>This page contains a set of practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are required by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and so are mandatory for a CA to have its root certificate(s) included. They are listed here because they are things CAs often get wrong. In other cases the practices are only recommended, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.<br />
<br />
== Required Practices ==<br />
<br />
=== Publicly Available CP and CPS ===<br />
<br />
CAs must supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.<br />
<br />
* The CP/CPS must be publicly available from the CA's official web site.<br />
* The CP/CPS must clearly indicate which root and subordinate certificates the practices and processes described in those documents apply to.<br />
* The format of the CP/CPS document must be PDF or another suitable format for reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.<br />
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.<br />
* The CA must provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.<br />
<br />
===== CP/CPS Revision Table =====<br />
<br />
Section 3.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] states: "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document."<br />
<br />
===== CAA Domains listed in CP/CPS =====<br />
<br />
Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs] states: "CA's Certificate Policy and/or Certification Practice<br />
Statement ... '''shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA''' "issue" or<br />
"issuewild" records as permitting it to issue.<br />
<br />
===== BR Commitment to Comply statement in CP/CPS =====<br />
<br />
For root certificates with the Websites (TLS/SSL) trust bit enabled, Mozilla requires the corresponding CP/CPS documents to include a statement of commitment to comply with the CA/Browser Forum's Baseline Requirements, as per section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs.]<br />
<br />
===== CP/CPS Structured According to RFC 3647 =====<br />
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements, with the effective of 31 May 2018. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.<br />
* The words "''No Stipulation''" mean that the particular document imposes no requirements related to that section. <br />
** Note that Mozilla's root store policy may be updated soon to forbid the use of "No Stipulation" in CP/CPS documents. <br />
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred. <br />
* Sections should not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional.<br />
** Note that Mozilla's root store policy may be updated soon to forbid blank sections in CP/CPS documents. <br />
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. Cross-referencing between CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.<br />
* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to SSL certificates.<br />
<br />
Examples:<br />
* If your CA does not allow a particular domain validation method to be used, then the CP or CPS should say that, e.g. "This method of domain validation is not used".<br />
* If your CP delegates requirements to one or more CPSs, then the CP should state "Refer to CPS".<br />
* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for SSL certs, and then the other sections related to suspension should say “Not applicable”.<br />
* If your CA does not issue SSL certs containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed; e.g. “No IP address certificates are issued under this CPS.”<br />
* If your CP contains the full description of section 5, then the CPS may say "As stipulated in section 5 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)<br />
<br />
===== CP/CPS Documents will be Reviewed! =====<br />
<br />
During the [[CA/Application_Verification#Detailed_Review|Detailed Review]] phase, <br />
your CP/CPS documentation will be thoroughly reviewed and commented on. Concerns raised by the reviewer must be sufficiently resolved before the request will be allowed to enter [[CA/Application_Verification#Public_discussion|public discussion]]. <br />
<br />
Here are some examples of previous reviews of CP/CPS documents:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]<br />
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]<br />
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.<br />
<br />
=== Audit Criteria ===<br />
<br />
CAs must supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.<br />
<br />
* The CA must indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).<br />
* All documents supplied as evidence must be publicly available.<br />
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).<br />
<br />
==== Complete Audit History ====<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#71-inclusions Mozilla's Root Store Policy] states: "Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements."<br />
<br />
This requirement may be met via one of the following options:<br />
* Providing the sequence of audit statements on the CA's website.<br />
* Attaching the sequence of audit statements to the root inclusion request (Bugzilla Bug).<br />
<br />
=== Revocation of Compromised Certificates ===<br />
<br />
CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.<br />
<br />
=== Verifying Domain Name Ownership ===<br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has registered all domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf. This must be done using one or more of the methods documented in section 3.2.2.4 of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with. CAs are not permitted to use 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address)."<br />
<br />
The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.<br />
<br />
===== Baseline Requirements =====<br />
<br />
It is '''not''' sufficient to simply reference section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements (BR)]. The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 3.2.2.4 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. Section 2.3 of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes '''in detail''' how the CA implements the latest version of these Requirements."<br />
<br />
'''Important:'''<br />
* The CPS should state what the CA actually does, not what it could do. Such as which of the allowed domain validation methods the CA uses.<br />
* BR subsections 3.2.2.4.1 and 3.2.2.4.5 were banned effective 1-August-2018.<br />
** "CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods"<br />
* BR subsection 3.2.2.9 was banned by ballot SC15, effective 16-March 2019<br />
* BR subsection 3.2.2.4.10 contains major vulnerabilitie. If the CA uses this method, then the CA should describe how they are mitigating those vulnerabilities. If not using this method, the CPS should say so.<br />
* BR section 3.2.2.5(4) was updated by ballot SC7 to remove "any other method", effective 1-August 2019. Prior to that date:<br />
** Saying the CA follows BR section 3.2.2.5 does not meet [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's disclosure requirements for this method]. The CPS must describe if/how "any other method" is implemented.<br />
** BR subsection 3.2.2.5(4) "any other method" is not permitted in conjunction with 3.2.2.4.8 per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's Root Store Policy]. The CPS should be clear that they do not do that.<br />
<br />
===== WHOIS =====<br />
<br />
[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking <br />
ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.<br />
<br />
It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?<br />
<br />
===== Email Challenge-Response =====<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. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]<br />
<br />
CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to cause and obtain certificates for example.com. Please work with your engineering department to ensure your systems properly handle such cases, as well as handling productions such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.<br />
<br />
=== Verifying Email Address Control === <br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."<br />
<br />
The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.<br />
<br />
The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.<br />
<br />
It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.<br />
<br />
=== DNS names go in SAN ===<br />
<br />
According to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements:]<br />
* Section 7.1.4.2.1 states:<br />
** Certificate Field: '''extensions:subjectAltName'''<br />
** Required/Optional: '''Required'''<br />
** Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.<br />
* Section 7.1.4.2.2 states:<br />
** Certificate Field: '''subject:commonName''' (OID 2.5.4.3)<br />
** Required/Optional: Deprecated ('''Discouraged''', but not prohibited)<br />
** Contents: If present, this field '''MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension''' (see Section 7.1.4.2.1).<br />
<br />
=== OCSP ===<br />
<br />
OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80. <br />
<br />
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements]:<br />
# The OCSP URI must be provided in the certificate, except when OCSP stapling is used. (sections 7.1.2.2, 7.1.2.3)<br />
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (section 4.9.10)<br />
# OCSP Responses shall be updated at least every four days and have a maximum expiration time of ten days (section 4.9.10)<br />
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (section 7.1.3)<br />
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (section 4.9.9)<br />
<br />
You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:<br />
* Go to Firefox -> Preferences... -> Privacy & Security -> Certificates<br />
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"<br />
* You may need to clear your history cache<br />
* Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.<br />
<br />
=== Network Security Controls ===<br />
<br />
CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.<br />
<br />
It is expected that CAs do the following on a regular basis:<br />
* Maintain network security controls that at minimum meet the [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements.]<br />
* Check for mis-issuance of certificates, especially for high-profile domains.<br />
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.<br />
* Ensure Intrusion Detection System and other monitoring software is up-to-date.<br />
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.<br />
<br />
== Recommended Practices ==<br />
<br />
=== CA Hierarchy ===<br />
<br />
A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See [[CA:Recommendations_for_Roots]].<br />
<br />
CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:<br />
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs<br />
* The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.<br />
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.<br />
<br />
We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).<br />
<br />
=== Document Handling of IDNs in CP/CPS ===<br />
<br />
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)<br />
<br />
=== Usage of Appropriate Constraints ===<br />
<br />
Root certificates in Mozilla's program can have either the SSL trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.<br />
<br />
=== Pre-Issuance Linting ===<br />
<br />
Recently, several tools have been developed ([https://github.com/awslabs/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident&diff=1209031CA/Responding To An Incident2019-03-15T23:33:23Z<p>Wthayer: /* Revocation */ tweaks based on serial number entropy issue</p>
<hr />
<div>The page gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. <br />
<br />
For the purposes of this page, a "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. Researchers who report CA incidents such as misissuances are welcome to include a link to this page in their report to the CA, reminding the CA that Mozilla has the following expectations. This document is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained therein.<br />
<br />
Other examples of incidents include misconfigured OCSP responders, un-revocations, and any other event affecting trust in the WebPKI which does not involve the actual contents of certificates.<br />
<br />
While some forms of incident may be seen as less serious than others, opinions vary on which these are. Mozilla sees all incidents as good opportunities for the CA to test that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity.<br />
<br />
To be clear on the status of this document: this is a best practices document, not an official policy, and does not use normative language. Therefore, failure to follow one or more of the recommendations here is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response. <br />
<br />
= Immediate Actions =<br />
<br />
In misussuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI until you have diagnosed the source of the problem, or explain why this has not been done.<br />
<br />
Once the problem is diagnosed, you may restart issuance even if a full fix is not rolled out, if you are able to put in place temporary or manual procedures to prevent the problem from re-occurring. You should not restart issuance until you are confident that the problem will not re-occur.<br />
<br />
= Revocation =<br />
<br />
It is normal practice for CAs to revoke misissued certificates. But that leaves the question about '''when''' this should be done, particularly if it's not possible to contact the customer immediately, or if they are unable to replace their certificate quickly. Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements currently states (version 1.6.3):<br />
<br />
<blockquote><br />
“The CA SHOULD revoke a Certificate within 24 hours and MUST revoke a Certificate with 5 days if one or more of the following occurs: …<br><br />
7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;<br><br />
8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; …<br><br />
10. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or<br><br />
11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the Private Key was flawed."<br />
</blockquote><br />
<br />
This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 5 days.<br />
<br />
Mozilla recognizes that in some exceptional circumstances, revoking misissued certificates within the prescribed deadline may cause significant harm, such as when the certificate is used in critical infrastructure and cannot be safely replaced prior to the revocation deadline, or when a defect affects a massive number of Subscribers and certificates. However, Mozilla does not grant exceptions to the BR revocation requirements. It is our position that your CA is ultimately responsible for deciding if the harm caused by following the requirements of BR section 4.9.1 outweighs the risks that are passed on to individuals who rely on the web PKI by choosing not to meet this requirement.<br />
<br />
If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that:<br />
<br />
* The decision and rationale for delaying revocation will be disclosed to Mozilla in the form of a preliminary incident report immediately; preferably before the BR mandated revocation deadline. The rationale must include an explanation for why the situation is exceptional. Responses similar to “we deem this misissuance not to be a security risk” are generally not acceptable, and must be discussed on the mozilla.dev.security.policy list. When revocation is delayed at the request of specific Subscribers, the rationale should be provided on a per-Subscriber basis.<br />
* Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a clear timeline describing if and when the problematic certificates will be revoked and supported by the rationale to delay revocation.<br />
* The issue will need to be listed as a finding in your CA’s next BR audit statement.<br />
* Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.<br />
* That you will perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays.<br />
<br />
If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.<br />
<br />
= Follow-Up Actions =<br />
<br />
* Work out how the bug or problem was introduced. For a code bug, were the code review processes sufficient? Does your code have automated tests, and if so, why did they not catch this case?<br />
<br />
* Work out why the problem was not detected earlier. Were these certificates missed by your self-audits? Or is the code or process you use for such audits insufficiently frequent or rigorous?<br />
<br />
* If the problem is lack of compliance to an RFC, Baseline Requirement or Mozilla Policy requirement: were you aware of this requirement? If not, why not? If so, was an attempt made to meet it? If not, why not? If so, why was that attempt flawed? Do any processes need updating for making sure your CA complies with the latest version of the various requirements placed upon it?<br />
<br />
* Scan your corpus of certificates to look for others with the same issue. It does not look good for a CA to claim they have revoked all affected certificates and resolved the issue, and then for a researcher to discover another set of certificates with the same or a similar problem.<br />
<br />
* Examine whether there are potential related problems which you can also remediate at the same time. For example, if the problem was bad data in a particular field, consider improving the validation of all fields in the certificate prior to issuance. You should be proactively looking for [https://crt.sh/linttbscert ways] to harden your issuance pipeline against further problems.<br />
<br />
* If, as happens in a regrettably large number of cases, a problem report was sent to your CA but action in accordance with BR section 9.4.5 was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate.<br />
<br />
= Incident Report =<br />
<br />
The purpose of incident reporting is to help all of us work together to build a more<br />
secure web. Therefore, the incident report should share lessons learned that could be helpful to all CAs to build better systems. The incident report should explain how the systems failed, how was the mis-issuance or incident possible, and why the problem was not detected earlier. In addition to the timeline of responding to and resolving the incident, the incident report should explain how the CA's systems will be made more robust, and how other CAs may learn from the incident.<br />
<br />
Each incident should result in an incident report, written as soon as the problem is fully diagnosed and (temporary or permanent) measures have been put in place to make sure it will not re-occur. If the permanent fix is going to take significant time to implement, you should not wait until this is done before issuing the report. We expect to see incident reports as soon as possible, and certainly within two weeks of the initial issue report. While remediation work may still be ongoing, a satisfactory incident report will serve to resolve the issue from a Mozilla perspective. <br />
<br />
The incident report may well repeat things which have been said previously in discussions or bug comments. This is entirely expected. The report should be a summary of previous findings. The existence of data in discussions or bug comments does not excuse a CA from the task of compiling a proper incident report.<br />
<br />
Your CA may submit an incident report by creating a bug in Bugzilla under the NSS:CA Certificate Compliance component, or by posting the report to the mozilla.dev.security.policy mailing list. If an incident report is sent to the list without a corresponding bug, a new one will be created to track the incident.<br />
<br />
The incident report should cover at least the following topics:<br />
<br />
# How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.<br />
# A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.<br />
# Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.<br />
# A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.<br />
# The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.<br />
# Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.<br />
# List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.<br />
<br />
= Keeping Us Informed =<br />
<br />
Once the report is posted, you should respond promptly to questions that are asked, and in no circumstances should a question linger without a response for more than one week, even if the response is only to acknowledge the question and provide a later date when an answer will be delivered. You should also provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless Mozilla representatives agree to a different schedule by setting a “Next Update” date in the “Whiteboard” field of the bug. Such updates should be posted to the m.d.s.p. thread, if there is one, and the Bugzilla bug. The bug will be closed when remediation is completed.<br />
<br />
= Examples of Good Practice =<br />
<br />
Here are some examples of good practice, where a CA did most or all of the things recommended above.<br />
<br />
== Let's Encrypt Unicode Normalization Compliance Incident ==<br />
<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g6_zGA2exXw Initial Public Problem Report], 2017-08-10 20:23 UTC (apparently LE were made aware of the problem privately earlier that day)<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/_tXldrbIBwAJ Initial Public Response from CA], 2017-08-10 21:53 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJY Final Report from CA], 2017-08-11 03:00 UTC<br />
<br />
In this case, the CA managed to diagnose the problem, remediate it, and deploy the fix to production within 24 hours.<br />
<br />
== PKIOverheid Short Serial Number Incident ==<br />
<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ Initial Public Problem Report], 2017-07-18 22:26 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/TzH5eI9dAQAJ Initial Public Response from CA], 2017-07-25 19:20 UTC<br />
* [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ Final Report from CA], 2017-08-11 14:39 UTC<br />
<br />
While the CA could have provided interim updates, and the final report was a little delayed, the contents of it were excellent.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/Revocation_Checking_in_Firefox&diff=1209025CA/Revocation Checking in Firefox2019-03-15T21:51:25Z<p>Wthayer: /* OCSP */ UpdateOCSP GET reference</p>
<hr />
<div>== Revocation Is Important ==<br />
Support for revoking certificates is important, because otherwise stolen and misissued certificates can be misused until they expire. History, from DigiNotar (malicious misissuance) to Heartbleed (private key theft vulnerability) shows us that the ability to revoke certificates is important. Mozilla has and will continue to invest in certificate revocation checking.<br />
<br />
== Challenges ==<br />
When a CA has to declare that a cert that used to be valid is no longer valid, we would like to ensure that this information is propagated to browsers as quickly as possible, but we also need to make sure that revocation mechanisms don't harm the user experience, in particular that they:<br />
<br />
* Don't add latency to TLS connection establishment<br />
* Don't require clients to store large amounts of state<br />
* Don't reveal more private information than necessary<br />
<br />
Revocation should result in “hard fail” to the greatest extent possible. This means that Firefox should assume the certificate is invalid if it cannot determine the revocation status. The opposite is called “soft fail”, in which Firefox assumes the certificate is valid if it cannot determine the status via some supported form of revocation checking.<br />
<br />
The standard approach to revocation checking is to use Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol ([http://tools.ietf.org/html/rfc6960 OCSP]). This has several drawbacks:<br />
<br />
* Revocation checking through CRLs or OCSP requests has high latency, even when it succeeds. CRLs can be an especially big hit to performance because they can grow to multiple megabyte files that must be downloaded before displaying a web page.<br />
* When OCSP fails or is blocked (e.g., by a captive portal), the page load can stall for up 15 seconds while the OCSP request times out.<br />
* The CA learns the IP address, location, a subset of the user's browsing history, and other sensitive information about the user through the OCSP request to its servers.<br />
* Because OCSP requests fail so often, failures result in certificate acceptance ("soft-fail"), which doesn’t actually protect users from an attack. (i.e. [https://www.imperialviolet.org/2012/02/05/crlsets.html "soft-fail revocation checks are like a seat-belt that snaps when you crash"]).<br />
<br />
[http://tools.ietf.org/html/rfc6066 OCSP stapling] addresses some of these problems, removing the latency and privacy harm when a good OCSP response is available. However, it still has the "soft-fail" problem -- an adversary can suppress the OCSP response.<br />
<br />
Our overall goal is to make revocation checking faster and more private, while maximizing the probability that any individual HTTPS connection will get good revocation information. We leverage several approaches here:<br />
<br />
* Centralized collection of revocation information and push to Firefox<br />
* Exemption of short-lived certificates from revocation checking<br />
* OCSP stapling with a must-staple indicator<br />
<br />
== Revocation Processing for Intermediate CA Certificates ==<br />
<br />
The relatively small number and low revocation frequency of CA certificates means that mechanisms that deliver a complete set of revoked certificates to Firefox are practical. However, due to the problems listed above, Firefox never attempts to download CRLs to the client. OCSP is also not used by Firefox to validate CA certificates.<br />
<br />
=== OneCRL ===<br />
In 2015, Mozilla [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ introduced OneCRL]. We gather CA certificate revocation information centrally, then push it out to clients. OneCRL currently contains two types of revocations:<br />
<br />
* All CA certificates that have been revoked by the CA. Mozilla now requires CAs to disclose all unconstrained CA certificates in [https://ccadb.org/ CCADB]. From this master list, Mozilla collects revocation information and periodically (usually on a monthly basis) updates OneCRL.<br />
* Exceptional revocations for both CA and end-entity certificates, including some that are not revoked by the CA. These entries are manually processed by Mozilla, typically as the result of a security incident involving the certificate.<br />
<br />
Revocations in OneCRL are typically based on the serial number and issuer of the revoked certificate. If multiple certificates with the same subject and public key need to be revoked, revocations based on the subject and public key hash are also supported.<br />
<br />
=== Multi-staple ===<br />
[https://tools.ietf.org/html/rfc6961 RFC 6961] defines a mechanism for stapling OCSP responses for CA certificates. Since FIrefox does not rely on OCSP to validate intermediate certificates, we have no plans to implement support for this.<br />
<br />
== Revocation Processing for End-Entity Certificates ==<br />
<br />
Revocation of end-entity certificates is checked in Firefox using the following mechanisms.<br />
<br />
=== Short-Lived Certificates ===<br />
A certificate with a must-staple extension is basically equivalent to a certificate with the same lifetime as the stapled OCSP response. (The only difference is that the OCSP response can be signed by a delegated key pair.) If the CA simply issues certificates with a lifetime on the order of an OCSP response, then there is no security benefit to performing revocation checking on these certificates. (This is basically the same approach taken by DNSSEC, which has short-lived signatures and no revocation.)<br />
<br />
Like OCSP must-staple, short-lived certificates are another fast-path option for websites, since a supporting browser will skip all revocation checks. Using short-lived certificates instead of a must-staple extension also removes the need to send an OCSP response in the handshake.<br />
<br />
Unfortunately, the adoption of short-lived certificates has been hampered by current CA/Browser Forum rules requiring OCSP for all certificates.<br />
<br />
Firefox does not perform any form of revocation checking for certificates with a validity period of less than 10 days. That period is configurable via the security.pki.cert_short_lifetime_in_days preference.<br />
<br />
=== OCSP Stapling ===<br />
[https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/ OCSP stapling] is a mechanism by which the web server periodically retrieves a fresh OCSP response from the CA and delivers it to the client in the TLS handshake. This eliminates the separate connection to a CA’s OCSP server that introduces latency and leaks browsing information. However, OCSP stapling is still susceptible to network failures and attacks. When Firefox receives a valid stapled OCSP response, it processes the response and does no other revocation checking. If the security.OCSP.enabled preference is set to ‘0’, stapled OCSP responses are ignored.<br />
<br />
=== OCSP Must-staple ===<br />
OCSP stapling allows good certificates to save the latency of a live OCSP fetch, but they don't provide much security benefit, since an attacker can omit the stapled response, suppress the live OCSP response, and soft-fail their way to victory. The [http://tools.ietf.org/html/rfc7633 TLS Feature Extension] for certificates protects against this attack by allowing the certificate to signal the browser to hard-fail if a stapled OCSP response is not present. When an end-entity certificate with the proper value in this extension is evaluated by Firefox, the stapled OCSP response will always be processed. If the response is not delivered via the TLS handshake or is not valid, Firefox will display an error rather than falling back to regular OCSP. Must-staple may be disabled via the security.ssl.enable_ocsp_must_staple or the security.ssl.enable_ocsp_stapling preferences.<br />
<br />
=== OCSP ===<br />
Firefox currently relies on traditional OCSP when a certificate is delivered without a stapled OCSP response. By default, Firefox ignores the revocation check (i.e. soft-fails) if a valid response is not received from the OCSP server within 2 seconds (10 seconds for an EV certificate). Setting the security.ocsp.require preference to ‘1’ switches to hard fail and triggers a certificate validation error if an OCSP response is not received within 10 seconds.<br />
<br />
If the OCSP server returns a status of “unknown”, Firefox will display the “SEC_ERROR_OCSP_UNKNOWN_CERT” error in a non-overrideable error message, regardless of the security.ocsp.require preference. Similarly, if the OCSP responder returns an error such as “trylater”, Firefox will display an error message.<br />
<br />
Note: Firefox [https://hg.mozilla.org/mozreview/gecko/rev/2249d58c94c867628b83d6c32eb0b5f64812a05c#index_header no longer] performs OCSP fetching using the HTTP GET method; Firefox uses the HTTP POST method.<br />
<br />
=== CRLite ===<br />
Mozilla is [https://bugzilla.mozilla.org/show_bug.cgi?id=1429800 currently] (as of early 2019) preparing to test an out-of-band revocation mechanism based on an [https://mislove.org/publications/CRLite-Oakland.pdf academic paper] titled “CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers”. In this mechanism, Mozilla produces a highly compressed representation of all trusted, non-expired certificates found in Certificate Transparency (CT) logs and their revocation status as asserted by the corresponding CRL. CRLite updates are delivered to the client using the same mechanism as OneCRL. <br />
<br />
Once fully implemented, CRLite is expected to be the primary mechanism used by Firefox to validate end-entity certificates. We expect that revocation checking will fall back to OCSP stapling or OCSP in the following situations:<br />
<br />
* If a CA has opted not to log a certificate, then it will not be delivered to the browser with any SCTs from recognized CT logs. When this happens (even for logged certificates), Firefox will fall back to OCSP stapling or OCSP in a hard-fail mode of operation for revocation checking.<br />
* There will be a small period of time - typically less than a day - after a certificate is first logged when CRLite won’t know about it and thus may not provide the correct revocation status. If the client’s latest update is timestamped after the date of the earliest SCT, then revocation checking will fall back to OCSP stapling or OCSP.<br />
* There may be certain cases in which all certificates signed by a specific CA certificate are not included in CRLite data. For example, if a CA doesn’t supply CRLs Mozilla may choose to exclude it, resulting in the use of OCSP for all certificates issued by that CA.<br />
* An enterprise policy and preference will be available to allow organizations to disable CRLite in certain situations, such as when they choose not to log specific publicly-trusted certificates or install their own private roots.<br />
<br />
== Extended Validation Rules ==<br />
In order to receive the EV UI, end-entity revocation checking must succeed via one of the currently implemented revocation checking mechanisms described above. In addition, as part of EV processing, OCSP is used in addition to OneCRL to check revocation for intermediate CA certificates. If an OCSP response for the intermediate CA certificate is not received or fails to verify, then the EV UI will not be displayed. Finally, if the security.OCSP.enabled preference is set to ‘0’ (disabled), OCSP checking is not performed and the EV UI will not appear for otherwise valid EV certificates.<br />
<br />
== Enterprise PKIs ==<br />
The Baseline Requirements forbid publicly-trusted CAs from issuing certificates without revocation pointers. For reasons of compatibility with other PKIs, such as enterprise PKIs, Firefox currently accepts such certificates if they are otherwise valid, and will continue to do so.<br />
<br />
== History of Revocation Checking Improvements in Firefox ==<br />
[[CA/History of Revocation Checking|A partial history of changes made to Firefox as of March 2017 in support of better revocation checking has been preserved.]]</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA&diff=1207950CA2019-02-19T23:14:38Z<p>Wthayer: Add revocation checking link</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/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 />
* [http://www.mozilla.org/projects/security/certs/policy/ Root Store Policy] (current stable version: 2.6.1)<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 />
<br />
== Lists of CAs and Certificates ==<br />
<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 [http://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/Certificate_Change_Requests|Certificate Change Requests]] as tracked in the CCADB<br />
* [[CA/Incident_Dashboard|Incident and Compliance 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 />
* [http://ccadb.org/cas/ CCADB Login]<br />
* [[CA/Responding_To_An_Incident|Responding to an Incident]] (such as a misissuance)<br />
* [[CA/Application_Process|Application Process for Mozilla's Root Program]]<br />
** [[CA/BR_Self-Assessment|Baseline Requirements Self Assessment]]<br />
** [[CA/Information_Checklist|CA Information Checklist]]<br />
** [[CA/Subordinate_CA_Checklist|Subordinate CA Information Checklist]]<br />
* [[CA/Certificate_Change_Process|Making Changes to Included Roots]]<br />
* [[CA/Required_or_Recommended_Practices|Required or Recommended CA Practices]]<br />
* [[CA/Forbidden_or_Problematic_Practices|Forbidden or Problematic CA Practices]]<br />
* [[CA/Maintenance_and_Enforcement|Maintenance and Enforcement]]<br />
* [[CA/EV_Processing_for_CAs | How Firefox Processes EV Certificates]]<br />
* [[PSM:EV_Testing_Easy_Version|EV Readiness Test]]<br />
* [https://github.com/awslabs/certlint BR Lint Certificate Test] - 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 />
<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 />
* [[CA/FAQ|FAQ About Certificates and CAs]]<br />
* [https://ccadb-public.secure.force.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=NSS&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/Upcoming_Distrust_Actions|Significant upcoming CA Distrust Actions]]<br />
* [[CA/Terminology|Glossary of CA and Certificate Terminology]]<br />
* [[PSM:Changing_Trust_Settings|Changing Certificate Trust Settings in Firefox]]<br />
* [https://tls-observatory.services.mozilla.com/static/certsplainer.html Mozilla's Certificate Explainer]<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-public.secure.force.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 Mozilla public forums are relevant to CA evaluation and related issues. Each forum can be accessed either as a mailing list, over the web or as a newsgroup.<br />
<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] (MDSP). This forum is used for discussions of Mozilla policies related to security in general and CAs in particular, and for wider discussions about the WebPKI. Among other things, it is the preferred forum for the public comment phase of CA evaluation. If you are a regular participant in MDSP, then please add your name to the [[CA/Policy_Participants|Policy Participants]] page.<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-tech-crypto mozilla.dev.tech.crypto]. This forum is used for discussions of the [http://www.mozilla.org/projects/security/pki/nss/ NSS] cryptographic library used in Firefox and other Mozilla-based products, as well as the [http://www.mozilla.org/projects/security/pki/psm/ PSM] module that implements higher-level security protocols for Firefox.<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-security mozilla.dev.security]. This forum is used for discussions of Mozilla security issues in general.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA:RevocationPlan&diff=1207949CA:RevocationPlan2019-02-19T23:12:07Z<p>Wthayer: Redirect to new page</p>
<hr />
<div>#REDIRECT [[CA/Revocation_Checking_in_Firefox]]<br />
<br />
This page documents Mozilla's future plans regarding how we support revocation checking of SSL certificates.<br />
<br />
* Discussion of policy changes: [https://www.mozilla.org/about/forums/#dev-security-policy mozilla.dev.security.policy] forum<br />
* Discussion of code changes: [https://www.mozilla.org/about/forums/#dev-tech-crypto mozilla.dev.tech.crypto] forum <br />
<br />
==Revocation Is Important==<br />
<br />
Support for revoking certificates is important, because otherwise stolen certificates can be used to abuse our users until they expire. History, from Diginotar (malicious misissuance) to Heartbleed (private key theft vulnerability) shows us that the ability to revoke certificates is important. Having no revocation story is not an option.<br />
<br />
== Problem Statement ==<br />
<br />
Every so often, a CA has to declare that a cert that used to be valid is no longer valid. We would like to ensure that this information is propagated to browsers as quickly as possible, but we also need to make sure that revocation mechanisms don't harm the user experience, in particular that they:<br />
<br />
* Don't add latency to TLS connection establishment<br />
* Don't require clients to store large amounts of state<br />
* Don't reveal more private information than necessary<br />
<br />
Revocation should result in hard failure to the greatest extent possible. If a certificate is verifiably revoked, then the browser should not proceed with the connection -- and we should always be able to determine whether a certificate has been revoked.<br />
<br />
The current approach to revocation checking is to use [http://tools.ietf.org/html/rfc6960 OCSP]. This has several drawbacks:<br />
<br />
* Revocation checking through OCSP requests has high latency, even when it works.<br />
* When OCSP fails or is blocked (e.g., by a captive portal), the page load can stall for up 30+ seconds while we the OCSP request times out.<br />
* The CA learns the IP address, location, a subset of the user's browsing history, and other sensitive information about the user through the OCSP request to its servers.<br />
* Revocation of intermediate certificates is only checked during EV validation.<br />
* Because OCSP requests fail so often, failures result in certificate acceptance ("soft-fail"), which fails to protect users. (As AGL puts it, [https://www.imperialviolet.org/2012/02/05/crlsets.html "soft-fail revocation checks are like a seat-belt that snaps when you crash"]).<br />
<br />
[http://tools.ietf.org/html/rfc6066 OCSP stapling] addresses some of these problems, removing the latency and privacy harm when a good OCSP response is available. However, it still has the "soft-fail" problem -- an adversary can suppress the OCSP response.<br />
<br />
Our overall goal is to make revocation checking faster and more private, while maximizing the probability that any individual HTTPS connection will get good revocation information. We plan to leverage several approaches here:<br />
<br />
* Centralized collection of revocation information and push to browsers<br />
* Exemption of short-lived certificates from revocation checking<br />
* OCSP stapling with a must-staple indicator<br />
<br />
Our hope is that these solutions together will cover a sufficiently large number of use cases that the use of "live" OCSP will become small enough to let us hard-fail when OCSP fails. If live OCSP is sufficiently rare, then it will be easier for us to enable hard-fail by default -- in order for a web site to be broken, it will have had to decline to use all of the above mechanisms, and use a CA with a broken OCSP responder.<br />
<br />
== Long-range Vision ==<br />
<br />
To put it briefly: For CA certificates (that is, roots and subCA certificates), only check a centralized list. For EE certificates, provide a collection of "fast path" options. The proposed changes in validation processing are illustrated in [http://www.ipv.sx/tmp/revocation.pdf this PDF].<br />
<br />
* Mozilla maintains central list of revocation information (called OneCRL), covering all intermediate certificates and an (initially small) subset of EE certificates.<br />
* OneCRL is pushed out to Firefox instances regularly<br />
* For CA certificates, the only revocation checking done is to check the OneCRL<br />
* For EE certificates, Firefox checks several revocation paths:<br />
** OneCRL (if applicable)<br />
** Short-lived certificates are exempted from revocation checking<br />
** Stapled OCSP response (if present)<br />
** OCSP must-staple (if present)<br />
** Live OCSP with hard-fail<br />
<br />
Enabling hard-fail on live OCSP by default may not be achievable, and is a long-term goal in any case. We will proceed by implementing the fast-path options first, and measuring (1) how much they reduce live OCSP usage and (2) OCSP failure rates.<br />
<br />
The Baseline Requirements forbid publicly-trusted CAs from issuing certificates without revocation pointers. For reasons of compatibility with other PKIs, such as enterprise PKIs, Firefox currently accepts such certificates if they are otherwise valid, and will continue to do so.<br />
<br />
== Proposed Changes ==<br />
<br />
=== OneCRL ===<br />
<br />
The idea for OneCRL is to follow a similar approach to the [https://www.imperialviolet.org/2012/02/05/crlsets.html CRLset concept] used in Google Chrome (also discussed earlier on a [https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Certain_End-Entity_Certificates Mozilla wiki page]). Gather revocation information centrally, then push it out to browsers. The main questions are thus: (1) What information should we gather?, and (2) How should it be pushed to browsers? (3) How should it be used by the browser?<br />
<br />
'''What to include in OneCRL:''' The main focus of OneCRL is to cover intermediate CA certificates. So we will need to collect URLs for sources of revocation information for all intermediate CAs. We may well also use it for high-profile EE misissuances. In the future, once the initial implementation is working, we may look into covering EE certificates with OneCRL, possibly focusing initially on specific classes (e.g., EV certificates).<br />
<br />
'''Distribution and Security of OneCRL:''' Logically, OneCRL updates will be distributed to browsers regularly (roughly daily). In order to ensure that browsers have timely revocation information, we need to ensure that it is difficult for an adversary to block the channel by which these updates are sent out.<br />
<br />
'''Format and Usage of OneCRL:''' For CA certificates, we will include revocation information by explicitly representing revoked certs (directly or with a fingerprint). Thus, for CA certificates, OneCRL will be dispositive -- a certificate will be rejected if it is in OneCRL and accepted if not. (If OneCRL is updated in the future to cover EE certificates, it will likely require the use of a probabilistic, compressed representation, such as a Bloom filter. In this case, OneCRL will be dispositive only in the positive direction: If the certificate is covered by OneCRL and the certificate is not listed as revoked, then we know it is not revoked. But if the certificate is in OneCRL, then we still check OCSP (stapled or live) to for false positives).<br />
<br />
==== Next Steps ====<br />
<br />
* Complete implementation of block-list-based OneCRL<br />
* Add support for CRL polling as an input, as well as manual input<br />
* Collect URLs for revocation information covering all intermediate CAs<br />
* Investigate whether there are some EE certificates that should be covered by OneCRL<br />
<br />
=== OCSP must-staple ===<br />
<br />
OCSP stapling allows good certificates to save the latency of a live OCSP fetch, but they don't provide much security benefit, since an attacker can omit the stapled response, suppress the live OCSP response, and soft-fail his way to victory. The OCSP must-staple extension for certificates protects against this attack by allowing the browser to fail if a stapled OCSP response is not present. This also represents a guaranteed fast-path option for websites, since a certificate with this extension will never have a live OCSP lookup (at least for browsers that support the extension).<br />
<br />
The [http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/?include_text=1 specification for the must-staple extension] is currently being developed in the IETF. As this specification is finalized, we plan to add support for it to the Firefox certificate validation process.<br />
<br />
==== Next Steps ====<br />
<br />
* Support standardization of must-staple extension<br />
* Implement support for must-staple extension<br />
<br />
=== Short-Lived Certificates ===<br />
<br />
A certificate with a must-staple extension is basically equivalent to a certificate with the same lifetime as the stapled OCSP response. (The only difference is that the OCSP response can be signed by a delegated key pair.) If the CA simply issues certificates with a lifetime on the order of an OCSP response, then there is no security benefit to performing revocation checking on these certificates. (This is basically the same approach taken by DNSSEC, which has short-lived signatures and no revocation.)<br />
<br />
Like OCSP must-staple, short-lived certificates are another fast-path option for websites, since a supporting browser will skip all revocation checks. Using short-lived certificates instead of a must-staple extension also removes the need to send an OCSP response in the handshake.<br />
<br />
The proposal here is thus to set a threshold maximum lifetime, and for certificates whose lifetime is shorter than that threshold, perform no further revocation checking.<br />
<br />
The question is then what threshold we should use. As a starting point, Firefox currently limits OCSP validity times to a maximum of 10 days. We could also look at some empirical data on he distribution of OCSP validity times to see if something shorter might make sense. The setting of a threshold should obviously be done in coordination with CAs and website owners, since it will impact their operations. For example, it might be helpful for the CA/Browser Forum to establish a recommendation. <br />
<br />
==== Next Steps ====<br />
<br />
* Agree on a threshold with other stakeholders<br />
* Add a check for short-lived certificates, and exemption from revocation checking<br />
** Agreement on a threshold is required before this is enabled on a broad scale<br />
<br />
=== Hard-fail Measurement & Enablement ===<br />
<br />
In the long run, we would like to make live OCSP checks hard-fail by default when the browser is unable to reach an OCSP responder. But of course, as long as we are heavily reliant on live OCSP checks for revocation for most HTTPS transactions, the breakage caused by hard-fail is too high. We should monitor the level of breakage that hard-fail would cause to see if we can get to a low enough level that we can turn on hard-fail.<br />
<br />
==== Next Steps ====<br />
<br />
* Add measurements of how often the various revocation paths are taken, in particular, how often live OCSP is used and how often it fails<br />
* Establish measurements of (1) live OCSP usage rate and (2) live OCSP failure rate<br />
<br />
==What Do Others Do?==<br />
<br />
===Chrome on Desktop===<br />
<br />
Google Chrome only uses [http://dev.chromium.org/Home/chromium-security/crlsets CRLsets] for non-EV (and some EV?) certs. However, their CRLset implementation covers both end-entity and intermediate certs, and is not designed to be comprehensive. Some CRLs are not included - the list is manually mantained by emailing agl.<br />
<br />
agl is [https://www.imperialviolet.org/2014/04/19/revchecking.html of the opinion] that the only thing other than CRLsets which is worth considering is must-staple. So Chrome seems to be going in the same direction as us.<br />
<br />
===IE on Desktop===<br />
<br />
[http://technet.microsoft.com/en-us/library/ee619754%28WS.10%29.aspx IE checks OCSP] and, if OCSP fails, falls back to CRLs - although they are considering eliminating the fallback.<br />
<br />
===Chrome on Mobile===<br />
<br />
???<br />
<br />
===Android Browser===<br />
<br />
???</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA:ImprovingRevocation&diff=1207948CA:ImprovingRevocation2019-02-19T23:10:40Z<p>Wthayer: Redirect to new version of this page</p>
<hr />
<div>#REDIRECT [[CA/History_of_Revocation_Checking]]<br />
<br />
= Plan for Improving Revocation Checking in Firefox =<br />
<br />
See [[CA:RevocationPlan | CA:RevocationPlan]] for Mozilla's plans regarding how we will support revocation checking of SSL certificates. <br />
<br />
This page is dedicated to changes that are happening to move towards our [[CA:RevocationPlan#Long-range_Vision | long-term revocation goals]].<br />
<br />
* Discussion of Policy changes: '''mozilla.dev.security.policy''' forum<br />
* Discussion of Code changes: '''mozilla.dev.tech.crypto''' forum<br />
<br />
Results of a research project commissioned by Mozilla to investigate the state of SSL Certificate Revocation: <br />
[[File:SSLcertRevocation.pdf]]<br />
<br />
== Changes '''Completed/Released''' ==<br />
<br />
The following changes have been implemented and released.<br />
<br />
=== OCSP Must-Staple ===<br />
Websites that implement OCSP Must-Staple will get Hard Fail Revocation. <br />
<br />
A website may use OCSP Must-Staple to mandate support for revocation checking via OCSP stapling. A site that tells clients that an OCSP status response will always be stapled enables the browser to immediately stop processing when the response is not stapled. <br />
<br />
[http://tools.ietf.org/html/rfc7633 The IETF have specified a standard mechanism], which is implemented in Firefox Nightly. This is expected to ship with Firefox 45. <br />
<br />
* Release: Mozilla 45<br />
<br />
* Discussion: [http://www.ietf.org/mail-archive/web/tls/current/msg10351.html ''Discussion Thread'']<br />
<br />
* Code Change: {{Bug|901698}}, {{Bug|921907}}<br />
<br />
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]], insanity::pkix {{Bug|915930}}<br />
<br />
* Policy Change: None, though Must-Staple is a popular subject for proposals permitting "not short-lived" certificates in the future.<br />
<br />
* Process Change: None needed.<br />
<br />
<br />
=== Preload Revocations of Intermediate CA Certificates ===<br />
Push revocation information of revoked intermediate CA certificates to clients.<br />
<br />
Mozilla has implemented a revocation list push mechanism in Firefox called [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL], which pushes a revocation list of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This improves 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. <br />
<br />
Further information about revoked intermediate certificates: [[CA:RevokedSubCAcerts|https://wiki.mozilla.org/CA:RevokedSubCAcerts]]<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ mozilla.dev.security.policy]<br />
<br />
* Code Change: {{Bug|1024809}}<br />
<br />
* Policy Change:<br />
** https://wiki.mozilla.org/CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce<br />
** https://github.com/mozilla/pkipolicy/issues/48<br />
<br />
==== When To Notify Mozilla ====<br />
CAs must notify Mozilla of all revoked non-technically-constrained intermediate certificates chaining to a root certificate included in [[CA:IncludedCAs|Mozilla's root store]] that are revoked before the certificate has expired.<br />
<br />
When a CA revokes an intermediate certificate chaining to a root certificate included in [[CA:IncludedCAs|Mozilla's root store]], the CA '''must''' notify Mozilla if the certificate was revoked for one or more of the following reasons. '''Time Frame''' for such notification: within 24 hours of revocation of the intermediate certificate <br />
* Technical Issue - There is a problem with the intermediate certificate such that the certificate may be inappropriately used. This includes, but is not limited to, wrong key usage, incorrect name constraints, etc.<br />
* Cessation of business operation - An externally-operated subordinate CA certificate has been revoked or replaced (for any reason) before it has expired.<br />
* According to [http://csrc.nist.gov/publications/drafts/nistir-7924/draft_nistir_7924.pdf NIST IR 7924] a Trust Anchor Manager (TAM) is an Authority who manages a repository of trusted Root CA Certificates. As specified in Section 5.7, the TAM will require the CA to provide notification when:<br />
** Root CA compromise -- Compromise of CA private signing key (Notification shall be made in an authenticated and trusted manner... earliest feasible time and shall not exceed <24> hours beyond determination of compromise or loss unless otherwise required by law enforcement)<br />
**Intermediate or Subordinate CA key compromise (revocation information shall be published immediately in the most expedient, authenticated, and trusted manner but within <18> hours)<br />
** Compromise of Certificate Status Server (CSS) key, an example of a CSS is an OCSP server. (If the CSS is self-signed and the CSS certificate expiration is more than <7> days away, the vendor shall immediately notify the trust anchor managers)<br />
** RA key compromised (the revocation information shall be published within <24> hours in the most expedient, authenticated, and trusted manner)<br />
** Suspected or detected compromise of any CA system or subsystem<br />
** Physical or electronic penetration of any CA system or subsystem<br />
** Successful denial of service attacks on any CA system or subsystem<br />
** When computing resources, software, and/or data are corrupted<br />
** Any incident preventing a CA from issuing and publishing a CRL or OCSP prior to the time indicated in the nextUpdate field in the currently published CRL or OCSP suspected or detected compromise of a certificate status server (CSS) if<br />
*** the CSS certificate has a lifetime of more than <72> hours; and<br />
*** the CSS certificate cannot be revoked (e.g., an OCSP responder certificate with the id-pkix-ocsp-nocheck extension)<br />
<br />
'''Time Frame''' for Notification: within 24 hours of revocation of an intermediate certificate <br />
<br />
'''How to''' notify Mozilla of a revocation <br />
* If the revocation is due to a security concern or of revocation of a website certificate whose revocation was not prompted by the certificate owner, send email to security@mozilla.org. <br />
* Otherwise, enter the data about the revoked intermediate certificate into the [[CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce|Common CA Database]].<br />
<br />
=== No EV Treatment when OCSP Fails or Not Provided ===<br />
EV Treatment will not be given when the OCSP response fails or cannot be retrieved for end-entity and intermediate certificates. <br />
<br />
* Release: Mozilla 28<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/mYKaLIcP70I/255h8y4-0YYJ mozilla.dev.security.policy]<br />
<br />
* Code Change: {{Bug|585122#c34}}<br />
<br />
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]]<br />
** Some sites that are currently receiving EV treatment may stop getting EV treatment. If that happens, check that the OCSP URI is in the AIA of the end-entity and intermediate certificates (unless stapled OCSP response is provided), and that the OCSP responses are correctly being returned.<br />
<br />
* Policy Change: None. The EV guidelines already require OCSP.<br />
<br />
* Process Change: None. We already check for this when evaluating EV root inclusion/change requests.<br />
<br />
=== OCSP Stapling ===<br />
OCSP responders are not yet [http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html reliable enough for us to do hard fail]. OCSP stapling will help to make hard-fail possible. Must-Staple will be a way to opt into hard-fail. <br />
<br />
OCSP stapling has the site itself periodically ask the CA for a signed assertion of status and sends that statement in the TLS handshake at the beginning of new HTTPS connections. The browser takes that signed, stapled response, verifies it, and uses it to determine if the site’s certificate is still trustworthy. <br />
<br />
https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/<br />
<br />
* Release: Mozilla 26 <br />
<br />
* Discussion: This has been discussed in several forums.<br />
<br />
* Code Change: {{Bug|929617}}, {{Bug|700693}}, {{Bug|360420}}<br />
<br />
* Dependencies: Website operators turn on OCSP stapling to protect their users. <br />
** For websites using nginx as their server: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling<br />
** For Apache: https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslusestapling<br />
<br />
* Policy Change: None<br />
<br />
* Process Change: None<br />
<br />
=== Reduce OCSP Network Timeout for Soft-Fail ===<br />
When the OCSP preference is set to soft fail(default) and DV validation is being performed, the network timeout will be changed from 10 seconds to 3 seconds. When the OCSP preference is set to hard fail or EV validation is being performed, the network timeout will still be 10 seconds. <br />
<br />
* Release: Mozilla 27<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.tech.crypto/aUKIi8XVuQ0/7GwZn5-cI5QJ Discussed in mozilla.dev.tech.crypto]<br />
<br />
* Code Change: {{Bug|918120}}<br />
<br />
* Dependencies: None<br />
<br />
* Policy Change: None<br />
<br />
* Process Change: None<br />
<br />
=== Remove CRL User-Interface ===<br />
As of Firefox 24, the user-interface for importing CRLs via Firefox has been removed. Auto-importing/updating of CRLs through Firefox has also been removed. NSS still supports CRLs, but Firefox is moving away from checking CRLs, and moving towards using a [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]]. <br />
<br />
* Release: Mozilla 24 <br />
<br />
* Discussion: <br />
** Discussed pre-code-change in the [https://groups.google.com/d/msg/mozilla.dev.tech.crypto/_y9ReaRT91M/04WLqDs3tHcJ mozilla.dev.tech.crypto], [https://groups.google.com/d/msg/firefox-dev/Dmn_RQPClJ8/cfHw3m48dVIJ firefox-dev], and [https://groups.google.com/d/msg/mozilla.dev.security/AkyAD0l8btc/sYIHbOnAWt8J mozilla.dev.security] forums.<br />
** Policy and process discussion in the [https://groups.google.com/d/msg/mozilla.dev.security.policy/ilOoDiCU4JM/-iABltbxlWIJ mozilla.dev.security.policy forum.]<br />
<br />
* Code Change: <br />
** Firefox 24: {{Bug|867465#c12}}<br />
** Thunderbird 25: {{Bug|892255}}<br />
** SeaMonkey 2.22: {{Bug|886099}}<br />
<br />
* Dependencies: None. <br />
** Use [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil] to see and/or modify your list of CRLs in NSS.<br />
** The feature of auto-importing/updating CRLs through Firefox is gone, because CRLs won't be updated any more by Firefox. If you have another program that is adding/updating your CRLs in your NSS certificate database, then those CRLs will be used for the time being.<br />
** In the near future Firefox will not be checking CRLs that have been imported into NSS. Instead, Firefox will use a [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]].<br />
<br />
* Policy Change: No policy change for this, because CRLs are still supported in NSS so CRLs can continue to be used without the UI. Also, there are non-Mozilla products that use NSS and may continue to rely on CRLs.<br />
<br />
* Process Change: Update the [https://wiki.mozilla.org/CA:Information_checklist Root Inclusion Checklist] to provide information about how to manually test CRLs in NSS using [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil].<br />
<br />
== Changes '''In Progress''' ==<br />
<br />
The following changes have been discussed in a Mozilla discussion forum, and are in the implementation phase.<br />
<br />
=== OCSP GET ===<br />
Change OCSP client code to try HTTP GET first, and fall back to POST in case GET fails. GET has the advantage that it can be cached by an ordinary caching HTTP server. It is also possible for an OCSP responder to redirect a GET request, but not a POST request. <br />
<br />
* Release: NSS 3.15.4, Firefox ???<br />
<br />
* Discussion: ''Link to Discussion Thread''<br />
<br />
* Code Change: {{Bug|436414}}, {{Bug|871954}}<br />
<br />
* Dependencies: None<br />
<br />
* Policy Change: None<br />
<br />
* Process Change: None<br />
<br />
<br />
=== ''Change Name'' ===<br />
''Description''<br />
<br />
* Release: ''to be determined''<br />
<br />
* Discussion: ''Link to Discussion Thread''<br />
<br />
* Code Change: ''Bugzilla Bug Number''<br />
<br />
* Dependencies: <br />
<br />
* Policy Change: <br />
<br />
* Process Change:<br />
<br />
== '''Proposed''' Changes under Discussion ==<br />
<br />
The following changes are being discussed (or will be discussed soon) in the mozilla.dev.security.policy forum.<br />
<br />
Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction or outcome of the discussion.<br />
<br />
=== Remove CRL Checking via CRLDP===<br />
Remove CRL checking through CRLDP in the certificate (a.k.a. CRL fetching). The normal certificate checking path does not do CRL fetching, and it never has. So, for any CA that isn't enabled for EV treatment, Firefox has never done CRL fetching. Firefox has only done CRL checking for EV certs as per the following logic. The source code for this is here:<br />
http://hg.mozilla.org/mozilla-central/annotate/ad2a5a4f53ec/security/manager/ssl/src/CertVerifier.cpp#l150<br />
<br />
# Does the end-entity certificate have an EV policy OID from any of the CAs that have been [http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsIdentityChecking.cpp enabled for EV treatment.]<br />
# If yes, then verify that the certificate is valid for that policy OID, trusting only that CA's root. <br />
# During this validation, check OCSP, and fall back to CRLs using CRLDP. <br />
# If that validation succeeds, then return "Good EV certificate." <br />
# If that validation fails, check the certificate using the normal certificate checking path.<br />
<br />
The CABForum EV guidelines have required EV CAs to support OCSP for a very long time. So, there's no justification for Firefox to fall back to CRL fetching for EV certificate verification any more. Accordingly, to avoid various problems that CRLs pose on us, our users, and on CAs, we'll stop doing the fallback to CRLs for EV certificates very soon.<br />
<br />
Once that happens, for all practical purposes, Firefox will not have anything to do with CRLs. The only exception is that, if you use some specialized tools to important CRLs into Firefox's certificate database, then Firefox will recognize those specially-imported CRLs for a while. However, it is likely that that will stop too, when we switch to the new certificate validation library.<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/zgXqG_P3RIg/RozDfvB5t04J mozilla.dev.security.policy]<br />
<br />
* Code Change: {{Bug|585122#c34}}<br />
<br />
* Dependencies: [[CA:ImprovingRevocation#Remove_CRL_User-Interface | Remove CRL User-Interface]].<br />
<br />
* Policy Change: Remove any reference to CRLs from [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's CA Certificate Policy].<br />
<br />
* Process Change: In the CA root inclusion checklist change the instructions about checking CRL to use crlutil. NSS users still may use CRL even though Firefox won't.<br />
<br />
=== Preload Revocations of Certain End-Entity Certificates ===<br />
Push revocation information of certain revoked end-entity certificates to clients.<br />
<br />
Implement a revocation list push mechanism in Firefox, which will push revocation lists of end-entity certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This should only apply to certain revocation circumstances in order to keep the list small/manageable.<br />
<br />
* Discussion: ''Link to Discussion Thread''<br />
<br />
* Code Change: ''Bugzilla Bug Number''<br />
<br />
* Dependencies: <br />
** Will need to be very specific about the circumstances for which we want to include revocation information for end-entity certs.<br />
** Will require a notification mechanism for CAs to inform us of which end-entity certs to add to the revocation list.<br />
<br />
* Policy Change: Will need to discuss.<br />
<br />
'''When''' To Notify Mozilla: CAs must notify Mozilla of end-entity revocations when an end-entity certificate is revoked due to a technical issue that enabled the certificate to be inappropriately used, such as:<br />
* Wrong Key Usage<br />
* Certificate issued for a domain to somebody that doesn't own/control that domain <br />
* Mistakenly set isCA=true <br />
<br />
'''Time Frame''' for Notification: Same time frame as for revocation of intermediate certs?<br />
<br />
'''How''' to notify Mozilla of a revocation: Same method as used for revocation of intermediate certs?<br />
<br />
* Process Change: To be determined.<br />
<br />
=== ''Change Name'' ===<br />
''Description''<br />
<br />
* Discussion: ''Link to Discussion Thread''<br />
<br />
* Code Change: ''Bugzilla Bug Number''<br />
<br />
* Dependencies: <br />
<br />
* Policy Change: <br />
<br />
* Process Change:</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/History_of_Revocation_Checking&diff=1207947CA/History of Revocation Checking2019-02-19T23:09:04Z<p>Wthayer: Add link to current page</p>
<hr />
<div>== History of Revocation Checking Improvements in Firefox ==<br />
This page is a historical record of revocation checking improvements made to Firefox as of March 2017.<br />
<br />
<big>'''This page is outdated and exists for reference only!'''</big><br />
<br />
<big>'''[[CA/Revocation_Checking_in_Firefox|Current Information on Revocation Checking in Firefox]]'''</big><br />
<br />
Results of a research project commissioned by Mozilla to investigate the state of SSL Certificate Revocation: [[File:SSLcertRevocation.pdf]]<br />
== Changes Completed/Released ==<br />
The following changes have been implemented and released.<br />
=== OCSP Must-Staple ===<br />
Websites that implement OCSP Must-Staple will get Hard Fail Revocation.<br />
A website may use OCSP Must-Staple to mandate support for revocation checking via OCSP stapling. A site that tells clients that an OCSP status response will always be stapled enables the browser to immediately stop processing when the response is not stapled.<br />
[http://tools.ietf.org/html/rfc7633 The IETF have specified a standard mechanism], which is implemented in Firefox Nightly. This is expected to ship with Firefox 45.<br />
* Release: Mozilla 45<br />
* Discussion: [http://www.ietf.org/mail-archive/web/tls/current/msg10351.html Discussion Thread]<br />
* Code Change: [https://bugzilla.mozilla.org/show_bug.cgi?id=901698 bug 901698], [https://bugzilla.mozilla.org/show_bug.cgi?id=921907 bug 921907]<br />
* Dependencies: OCSP Stapling, insanity::pkix [https://bugzilla.mozilla.org/show_bug.cgi?id=915930 bug 915930]<br />
* Policy Change: None, though Must-Staple is a popular subject for proposals permitting "not short-lived" certificates in the future.<br />
* Process Change: None needed.<br />
<br />
=== Preload Revocations of Intermediate CA Certificates ===<br />
Push revocation information of revoked intermediate CA certificates to clients.<br />
Mozilla has implemented a revocation list push mechanism in Firefox called [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL], which pushes a revocation list of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This improves 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.<br />
Further information about revoked intermediate certificates: [[CA:RevokedSubCAcerts|https://wiki.mozilla.org/CA:RevokedSubCAcerts]]<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ mozilla.dev.security.policy]<br />
* Code Change: [https://bugzilla.mozilla.org/show_bug.cgi?id=1024809 bug 1024809]<br />
* Policy Change:<br />
** [[CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce|https://wiki.mozilla.org/CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce]]<br />
** https://github.com/mozilla/pkipolicy/issues/48<br />
=== No EV Treatment when OCSP Fails or Not Provided ===<br />
EV Treatment will not be given when the OCSP response fails or cannot be retrieved for end-entity and intermediate certificates. <br />
<br />
* Release: Mozilla 28<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/mYKaLIcP70I/255h8y4-0YYJ mozilla.dev.security.policy]<br />
<br />
* Code Change: {{Bug|585122#c34}}<br />
<br />
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]]<br />
** Some sites that are currently receiving EV treatment may stop getting EV treatment. If that happens, check that the OCSP URI is in the AIA of the end-entity and intermediate certificates (unless stapled OCSP response is provided), and that the OCSP responses are correctly being returned.<br />
<br />
* Policy Change: None. The EV guidelines already require OCSP.<br />
<br />
* Process Change: None. We already check for this when evaluating EV root inclusion/change requests.<br />
<br />
=== OCSP Stapling ===<br />
OCSP responders are not yet [http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html reliable enough for us to do hard fail]. OCSP stapling will help to make hard-fail possible. Must-Staple will be a way to opt into hard-fail. <br />
<br />
OCSP stapling has the site itself periodically ask the CA for a signed assertion of status and sends that statement in the TLS handshake at the beginning of new HTTPS connections. The browser takes that signed, stapled response, verifies it, and uses it to determine if the site’s certificate is still trustworthy. <br />
<br />
https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/<br />
<br />
* Release: Mozilla 26 <br />
<br />
* Discussion: This has been discussed in several forums.<br />
<br />
* Code Change: {{Bug|929617}}, {{Bug|700693}}, {{Bug|360420}}<br />
<br />
* Dependencies: Website operators turn on OCSP stapling to protect their users. <br />
** For websites using nginx as their server: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling<br />
** For Apache: https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslusestapling<br />
<br />
* Policy Change: None<br />
<br />
* Process Change: None<br />
<br />
=== Reduce OCSP Network Timeout for Soft-Fail ===<br />
When the OCSP preference is set to soft fail(default) and DV validation is being performed, the network timeout will be changed from 10 seconds to 3 seconds. When the OCSP preference is set to hard fail or EV validation is being performed, the network timeout will still be 10 seconds. <br />
<br />
* Release: Mozilla 27<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.tech.crypto/aUKIi8XVuQ0/7GwZn5-cI5QJ Discussed in mozilla.dev.tech.crypto]<br />
<br />
* Code Change: {{Bug|918120}}<br />
<br />
* Dependencies: None<br />
<br />
* Policy Change: None<br />
<br />
* Process Change: None<br />
<br />
=== Remove CRL User-Interface ===<br />
As of Firefox 24, the user-interface for importing CRLs via Firefox has been removed. Auto-importing/updating of CRLs through Firefox has also been removed. NSS still supports CRLs, but Firefox is moving away from checking CRLs, and moving towards using a [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]]. <br />
<br />
* Release: Mozilla 24 <br />
<br />
* Discussion: <br />
** Discussed pre-code-change in the [https://groups.google.com/d/msg/mozilla.dev.tech.crypto/_y9ReaRT91M/04WLqDs3tHcJ mozilla.dev.tech.crypto], [https://groups.google.com/d/msg/firefox-dev/Dmn_RQPClJ8/cfHw3m48dVIJ firefox-dev], and [https://groups.google.com/d/msg/mozilla.dev.security/AkyAD0l8btc/sYIHbOnAWt8J mozilla.dev.security] forums.<br />
** Policy and process discussion in the [https://groups.google.com/d/msg/mozilla.dev.security.policy/ilOoDiCU4JM/-iABltbxlWIJ mozilla.dev.security.policy forum.]<br />
<br />
* Code Change: <br />
** Firefox 24: {{Bug|867465#c12}}<br />
** Thunderbird 25: {{Bug|892255}}<br />
** SeaMonkey 2.22: {{Bug|886099}}<br />
<br />
* Dependencies: None. <br />
** Use [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil] to see and/or modify your list of CRLs in NSS.<br />
** The feature of auto-importing/updating CRLs through Firefox is gone, because CRLs won't be updated any more by Firefox. If you have another program that is adding/updating your CRLs in your NSS certificate database, then those CRLs will be used for the time being.<br />
** In the near future Firefox will not be checking CRLs that have been imported into NSS. Instead, Firefox will use a [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]].<br />
<br />
* Policy Change: No policy change for this, because CRLs are still supported in NSS so CRLs can continue to be used without the UI. Also, there are non-Mozilla products that use NSS and may continue to rely on CRLs.<br />
<br />
* Process Change: Update the [https://wiki.mozilla.org/CA:Information_checklist Root Inclusion Checklist] to provide information about how to manually test CRLs in NSS using [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil].<br />
<br />
== Changes '''In Progress''' ==<br />
<br />
The following changes have been discussed in a Mozilla discussion forum, and are in the implementation phase.<br />
<br />
=== OCSP GET ===<br />
Change OCSP client code to try HTTP GET first, and fall back to POST in case GET fails. GET has the advantage that it can be cached by an ordinary caching HTTP server. It is also possible for an OCSP responder to redirect a GET request, but not a POST request. <br />
<br />
* Release: NSS 3.15.4, Firefox ???<br />
<br />
* Discussion: ''Link to Discussion Thread''<br />
<br />
* Code Change: {{Bug|436414}}, {{Bug|871954}}<br />
<br />
* Dependencies: None<br />
<br />
* Policy Change: None<br />
<br />
* Process Change: None<br />
== Proposed Changes under Discussion ==<br />
The following changes are being discussed (or will be discussed soon) in the mozilla.dev.security.policy forum.<br />
<br />
Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction or outcome of the discussion.<br />
<br />
=== Remove CRL Checking via CRLDP===<br />
Remove CRL checking through CRLDP in the certificate (a.k.a. CRL fetching). The normal certificate checking path does not do CRL fetching, and it never has. So, for any CA that isn't enabled for EV treatment, Firefox has never done CRL fetching. Firefox has only done CRL checking for EV certs as per the following logic. The source code for this is here:<br />
http://hg.mozilla.org/mozilla-central/annotate/ad2a5a4f53ec/security/manager/ssl/src/CertVerifier.cpp#l150<br />
<br />
# Does the end-entity certificate have an EV policy OID from any of the CAs that have been [http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsIdentityChecking.cpp enabled for EV treatment.]<br />
# If yes, then verify that the certificate is valid for that policy OID, trusting only that CA's root. <br />
# During this validation, check OCSP, and fall back to CRLs using CRLDP. <br />
# If that validation succeeds, then return "Good EV certificate." <br />
# If that validation fails, check the certificate using the normal certificate checking path.<br />
<br />
The CABForum EV guidelines have required EV CAs to support OCSP for a very long time. So, there's no justification for Firefox to fall back to CRL fetching for EV certificate verification any more. Accordingly, to avoid various problems that CRLs pose on us, our users, and on CAs, we'll stop doing the fallback to CRLs for EV certificates very soon.<br />
<br />
Once that happens, for all practical purposes, Firefox will not have anything to do with CRLs. The only exception is that, if you use some specialized tools to important CRLs into Firefox's certificate database, then Firefox will recognize those specially-imported CRLs for a while. However, it is likely that that will stop too, when we switch to the new certificate validation library.<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/zgXqG_P3RIg/RozDfvB5t04J mozilla.dev.security.policy]<br />
<br />
* Code Change: {{Bug|585122#c34}}<br />
<br />
* Dependencies: [[CA:ImprovingRevocation#Remove_CRL_User-Interface | Remove CRL User-Interface]].<br />
<br />
* Policy Change: Remove any reference to CRLs from [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's CA Certificate Policy].<br />
<br />
* Process Change: In the CA root inclusion checklist change the instructions about checking CRL to use crlutil. NSS users still may use CRL even though Firefox won't.<br />
<br />
=== Preload Revocations of Certain End-Entity Certificates ===<br />
Push revocation information of certain revoked end-entity certificates to clients.<br />
<br />
Implement a revocation list push mechanism in Firefox, which will push revocation lists of end-entity certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This should only apply to certain revocation circumstances in order to keep the list small/manageable.<br />
<br />
* Discussion: ''Link to Discussion Thread''<br />
<br />
* Code Change: ''Bugzilla Bug Number''<br />
<br />
* Dependencies: <br />
** Will need to be very specific about the circumstances for which we want to include revocation information for end-entity certs.<br />
** Will require a notification mechanism for CAs to inform us of which end-entity certs to add to the revocation list.<br />
<br />
* Policy Change: Will need to discuss.<br />
<br />
'''When''' To Notify Mozilla: CAs must notify Mozilla of end-entity revocations when an end-entity certificate is revoked due to a technical issue that enabled the certificate to be inappropriately used, such as:<br />
* Wrong Key Usage<br />
* Certificate issued for a domain to somebody that doesn't own/control that domain <br />
* Mistakenly set isCA=true <br />
<br />
'''Time Frame''' for Notification: Same time frame as for revocation of intermediate certs?<br />
<br />
'''How''' to notify Mozilla of a revocation: Same method as used for revocation of intermediate certs?<br />
<br />
* Process Change: To be determined.</div>Wthayerhttps://wiki.mozilla.org/index.php?title=CA/History_of_Revocation_Checking&diff=1207946CA/History of Revocation Checking2019-02-19T23:05:47Z<p>Wthayer: Cut & paste from old page</p>
<hr />
<div>== History of Revocation Checking Improvements in Firefox ==<br />
This page is a historical record of revocation checking improvements made to Firefox as of March 2017.<br />
<br />
<big>'''This page is outdated and exists for reference only!'''</big><br />
<br />
Results of a research project commissioned by Mozilla to investigate the state of SSL Certificate Revocation: [[File:SSLcertRevocation.pdf]]<br />
== Changes Completed/Released ==<br />
The following changes have been implemented and released.<br />
=== OCSP Must-Staple ===<br />
Websites that implement OCSP Must-Staple will get Hard Fail Revocation.<br />
A website may use OCSP Must-Staple to mandate support for revocation checking via OCSP stapling. A site that tells clients that an OCSP status response will always be stapled enables the browser to immediately stop processing when the response is not stapled.<br />
[http://tools.ietf.org/html/rfc7633 The IETF have specified a standard mechanism], which is implemented in Firefox Nightly. This is expected to ship with Firefox 45.<br />
* Release: Mozilla 45<br />
* Discussion: [http://www.ietf.org/mail-archive/web/tls/current/msg10351.html Discussion Thread]<br />
* Code Change: [https://bugzilla.mozilla.org/show_bug.cgi?id=901698 bug 901698], [https://bugzilla.mozilla.org/show_bug.cgi?id=921907 bug 921907]<br />
* Dependencies: OCSP Stapling, insanity::pkix [https://bugzilla.mozilla.org/show_bug.cgi?id=915930 bug 915930]<br />
* Policy Change: None, though Must-Staple is a popular subject for proposals permitting "not short-lived" certificates in the future.<br />
* Process Change: None needed.<br />
<br />
=== Preload Revocations of Intermediate CA Certificates ===<br />
Push revocation information of revoked intermediate CA certificates to clients.<br />
Mozilla has implemented a revocation list push mechanism in Firefox called [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL], which pushes a revocation list of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This improves 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.<br />
Further information about revoked intermediate certificates: [[CA:RevokedSubCAcerts|https://wiki.mozilla.org/CA:RevokedSubCAcerts]]<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ mozilla.dev.security.policy]<br />
* Code Change: [https://bugzilla.mozilla.org/show_bug.cgi?id=1024809 bug 1024809]<br />
* Policy Change:<br />
** [[CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce|https://wiki.mozilla.org/CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce]]<br />
** https://github.com/mozilla/pkipolicy/issues/48<br />
=== No EV Treatment when OCSP Fails or Not Provided ===<br />
EV Treatment will not be given when the OCSP response fails or cannot be retrieved for end-entity and intermediate certificates. <br />
<br />
* Release: Mozilla 28<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/mYKaLIcP70I/255h8y4-0YYJ mozilla.dev.security.policy]<br />
<br />
* Code Change: {{Bug|585122#c34}}<br />
<br />
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]]<br />
** Some sites that are currently receiving EV treatment may stop getting EV treatment. If that happens, check that the OCSP URI is in the AIA of the end-entity and intermediate certificates (unless stapled OCSP response is provided), and that the OCSP responses are correctly being returned.<br />
<br />
* Policy Change: None. The EV guidelines already require OCSP.<br />
<br />
* Process Change: None. We already check for this when evaluating EV root inclusion/change requests.<br />
<br />
=== OCSP Stapling ===<br />
OCSP responders are not yet [http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html reliable enough for us to do hard fail]. OCSP stapling will help to make hard-fail possible. Must-Staple will be a way to opt into hard-fail. <br />
<br />
OCSP stapling has the site itself periodically ask the CA for a signed assertion of status and sends that statement in the TLS handshake at the beginning of new HTTPS connections. The browser takes that signed, stapled response, verifies it, and uses it to determine if the site’s certificate is still trustworthy. <br />
<br />
https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/<br />
<br />
* Release: Mozilla 26 <br />
<br />
* Discussion: This has been discussed in several forums.<br />
<br />
* Code Change: {{Bug|929617}}, {{Bug|700693}}, {{Bug|360420}}<br />
<br />
* Dependencies: Website operators turn on OCSP stapling to protect their users. <br />
** For websites using nginx as their server: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling<br />
** For Apache: https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslusestapling<br />
<br />
* Policy Change: None<br />
<br />
* Process Change: None<br />
<br />
=== Reduce OCSP Network Timeout for Soft-Fail ===<br />
When the OCSP preference is set to soft fail(default) and DV validation is being performed, the network timeout will be changed from 10 seconds to 3 seconds. When the OCSP preference is set to hard fail or EV validation is being performed, the network timeout will still be 10 seconds. <br />
<br />
* Release: Mozilla 27<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.tech.crypto/aUKIi8XVuQ0/7GwZn5-cI5QJ Discussed in mozilla.dev.tech.crypto]<br />
<br />
* Code Change: {{Bug|918120}}<br />
<br />
* Dependencies: None<br />
<br />
* Policy Change: None<br />
<br />
* Process Change: None<br />
<br />
=== Remove CRL User-Interface ===<br />
As of Firefox 24, the user-interface for importing CRLs via Firefox has been removed. Auto-importing/updating of CRLs through Firefox has also been removed. NSS still supports CRLs, but Firefox is moving away from checking CRLs, and moving towards using a [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]]. <br />
<br />
* Release: Mozilla 24 <br />
<br />
* Discussion: <br />
** Discussed pre-code-change in the [https://groups.google.com/d/msg/mozilla.dev.tech.crypto/_y9ReaRT91M/04WLqDs3tHcJ mozilla.dev.tech.crypto], [https://groups.google.com/d/msg/firefox-dev/Dmn_RQPClJ8/cfHw3m48dVIJ firefox-dev], and [https://groups.google.com/d/msg/mozilla.dev.security/AkyAD0l8btc/sYIHbOnAWt8J mozilla.dev.security] forums.<br />
** Policy and process discussion in the [https://groups.google.com/d/msg/mozilla.dev.security.policy/ilOoDiCU4JM/-iABltbxlWIJ mozilla.dev.security.policy forum.]<br />
<br />
* Code Change: <br />
** Firefox 24: {{Bug|867465#c12}}<br />
** Thunderbird 25: {{Bug|892255}}<br />
** SeaMonkey 2.22: {{Bug|886099}}<br />
<br />
* Dependencies: None. <br />
** Use [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil] to see and/or modify your list of CRLs in NSS.<br />
** The feature of auto-importing/updating CRLs through Firefox is gone, because CRLs won't be updated any more by Firefox. If you have another program that is adding/updating your CRLs in your NSS certificate database, then those CRLs will be used for the time being.<br />
** In the near future Firefox will not be checking CRLs that have been imported into NSS. Instead, Firefox will use a [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]].<br />
<br />
* Policy Change: No policy change for this, because CRLs are still supported in NSS so CRLs can continue to be used without the UI. Also, there are non-Mozilla products that use NSS and may continue to rely on CRLs.<br />
<br />
* Process Change: Update the [https://wiki.mozilla.org/CA:Information_checklist Root Inclusion Checklist] to provide information about how to manually test CRLs in NSS using [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil].<br />
<br />
== Changes '''In Progress''' ==<br />
<br />
The following changes have been discussed in a Mozilla discussion forum, and are in the implementation phase.<br />
<br />
=== OCSP GET ===<br />
Change OCSP client code to try HTTP GET first, and fall back to POST in case GET fails. GET has the advantage that it can be cached by an ordinary caching HTTP server. It is also possible for an OCSP responder to redirect a GET request, but not a POST request. <br />
<br />
* Release: NSS 3.15.4, Firefox ???<br />
<br />
* Discussion: ''Link to Discussion Thread''<br />
<br />
* Code Change: {{Bug|436414}}, {{Bug|871954}}<br />
<br />
* Dependencies: None<br />
<br />
* Policy Change: None<br />
<br />
* Process Change: None<br />
== Proposed Changes under Discussion ==<br />
The following changes are being discussed (or will be discussed soon) in the mozilla.dev.security.policy forum.<br />
<br />
Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction or outcome of the discussion.<br />
<br />
=== Remove CRL Checking via CRLDP===<br />
Remove CRL checking through CRLDP in the certificate (a.k.a. CRL fetching). The normal certificate checking path does not do CRL fetching, and it never has. So, for any CA that isn't enabled for EV treatment, Firefox has never done CRL fetching. Firefox has only done CRL checking for EV certs as per the following logic. The source code for this is here:<br />
http://hg.mozilla.org/mozilla-central/annotate/ad2a5a4f53ec/security/manager/ssl/src/CertVerifier.cpp#l150<br />
<br />
# Does the end-entity certificate have an EV policy OID from any of the CAs that have been [http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsIdentityChecking.cpp enabled for EV treatment.]<br />
# If yes, then verify that the certificate is valid for that policy OID, trusting only that CA's root. <br />
# During this validation, check OCSP, and fall back to CRLs using CRLDP. <br />
# If that validation succeeds, then return "Good EV certificate." <br />
# If that validation fails, check the certificate using the normal certificate checking path.<br />
<br />
The CABForum EV guidelines have required EV CAs to support OCSP for a very long time. So, there's no justification for Firefox to fall back to CRL fetching for EV certificate verification any more. Accordingly, to avoid various problems that CRLs pose on us, our users, and on CAs, we'll stop doing the fallback to CRLs for EV certificates very soon.<br />
<br />
Once that happens, for all practical purposes, Firefox will not have anything to do with CRLs. The only exception is that, if you use some specialized tools to important CRLs into Firefox's certificate database, then Firefox will recognize those specially-imported CRLs for a while. However, it is likely that that will stop too, when we switch to the new certificate validation library.<br />
<br />
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/zgXqG_P3RIg/RozDfvB5t04J mozilla.dev.security.policy]<br />
<br />
* Code Change: {{Bug|585122#c34}}<br />
<br />
* Dependencies: [[CA:ImprovingRevocation#Remove_CRL_User-Interface | Remove CRL User-Interface]].<br />
<br />
* Policy Change: Remove any reference to CRLs from [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's CA Certificate Policy].<br />
<br />
* Process Change: In the CA root inclusion checklist change the instructions about checking CRL to use crlutil. NSS users still may use CRL even though Firefox won't.<br />
<br />
=== Preload Revocations of Certain End-Entity Certificates ===<br />
Push revocation information of certain revoked end-entity certificates to clients.<br />
<br />
Implement a revocation list push mechanism in Firefox, which will push revocation lists of end-entity certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This should only apply to certain revocation circumstances in order to keep the list small/manageable.<br />
<br />
* Discussion: ''Link to Discussion Thread''<br />
<br />
* Code Change: ''Bugzilla Bug Number''<br />
<br />
* Dependencies: <br />
** Will need to be very specific about the circumstances for which we want to include revocation information for end-entity certs.<br />
** Will require a notification mechanism for CAs to inform us of which end-entity certs to add to the revocation list.<br />
<br />
* Policy Change: Will need to discuss.<br />
<br />
'''When''' To Notify Mozilla: CAs must notify Mozilla of end-entity revocations when an end-entity certificate is revoked due to a technical issue that enabled the certificate to be inappropriately used, such as:<br />
* Wrong Key Usage<br />
* Certificate issued for a domain to somebody that doesn't own/control that domain <br />
* Mistakenly set isCA=true <br />
<br />
'''Time Frame''' for Notification: Same time frame as for revocation of intermediate certs?<br />
<br />
'''How''' to notify Mozilla of a revocation: Same method as used for revocation of intermediate certs?<br />
<br />
* Process Change: To be determined.</div>Wthayer