Closed Bug 1391000 Opened 6 years ago Closed 5 years ago
Trust: Non-BR-Compliant Certificate Issuance
The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience. To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information: 1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date. 2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below. 3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem. 4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued. 5) Explanation about how and why the mistakes were made, and not caught and fixed earlier. 6) 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. 7) Regular updates to confirm when those steps have been completed. Note Section 188.8.131.52 of the CA/Browser Forum’s Baseline Requirements, which states: “The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: … 9. 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; 10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; … 14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time). However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement. We expect that 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. 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. The problems reported for your CA in the mozilla.dev.security.policy forum are as follows: ** Failure to respond within 24 hours after Problem Report submitted https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ The problems were reported via your CA’s Problem Reporting Mechanism as listed here: https://ccadb-public.secure.force.com/mozilla/CAInformationReport Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this. ** pathLenConstraint with CA:FALSE https://groups.google.com/d/msg/mozilla.dev.security.policy/1q_aq5e0El4/LmfGUDmHBwAJ ** OCSP responder URL that has a HTTPS URI https://groups.google.com/d/msg/mozilla.dev.security.policy/jSHuE-Oc7rY/660iCGPZBgAJ
IdenTrust posted this on mozilla.dev.security.policy today: > Formal reply addressing the questionnaire format: > Issue pathLenConstraint with CA:False (IdenTrust) > 1. How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date. > IdenTrust: Problem Reported to IdenTrust via the Mozilla Dev Security Policy Forum on August 9, 2017 > 2. Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below. > IdenTrust: The issue was addressed immediately and a formal reply was supplied on to forum on August 10, 2017 > 3. Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem. > IdenTrust: There were 5 certificates reported with this issue: > https://crt.sh/?id=77893170&opt=cablint > https://crt.sh/?id=77947625&opt=cablint > https://crt.sh/?id=78102129&opt=cablint > https://crt.sh/?id=92235995&opt=cablint > https://crt.sh/?id=92235998&opt=cablint > > 4. Summary of the problematic certificates. For each problem listed below: > number of certs, date first and last certs with that problem were issued. > IdenTrust: Those 5 certificates were issued between Jan-16 and Feb 14, 2017. > 2 of them were pre-certificates. > 5. Explanation about how and why the mistakes were made, and not caught and fixed earlier. > IdenTrust: IdenTrust identified this situation during a routine audit in March of 2017. The certificates (which are all internal to IdenTrust) were reissued and these that were incorrect were intended to be revoked; unfortunately the revocation did not occur. > These certificates were created during the process of building a new product, which has not yet been officially launched and no additional certificates have been issued under this profile. Quarterly audits, comprised of evaluating a sampling of certificates, have been conducted; however, due to the fact that a revocation order had been issued for these certificates and we have no active production certificates for this program, no sampling was warranted. > > With respect to lack of follow through on the revocation in March 2017, because these certificates were not production certificates issued to actual subscribers, our standard revocation process for certificates does not appear to have been followed; rather, an informal internal emailed request was initiated and was apparently overlooked. We have addressed this internally and put remediation steps into place that will alleviate this possibility in the future. > > 6. 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. > IdenTrust: > 1. The 5 certificates were revoked on August 10, 2017 > 2. Since March 2017 we have corrected the profiles to prevent recurrence of this issue Source: https://groups.google.com/d/msg/mozilla.dev.security.policy/1q_aq5e0El4/_J_SivH2AQAJ
I think this sufficient.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
There is one ongoing incident that has not been fully resolved yet, two IdenTrust ACES intermediates have been issuing certificates with a variety of BR violations. Details are in this thread: https://groups.google.com/d/topic/mozilla.dev.security.policy/jSHuE-Oc7rY/discussion
IdenTrust: can you please comment here on the issue raised in comment #3? Why has it taken a month for you to respond? Gerv
The issues referenced in Comment 3 have been fully resolved as provided in the tread: https://groups.google.com/d/topic/mozilla.dev.security.policy/jSHuE-Oc7rY/discussion The remediation was completed as of September 1, 2017. This includes the original issue described in this bug report as well the variety of other issues identified in the thread above. The lack of response to the comment #3 on this report was an oversight as we were responding and providing updates in the thread and believed this was sufficient update that covered this bug report. We will modify this assumption going forward and provide updates in all relevant threads and reports.
Status: REOPENED → RESOLVED
Closed: 6 years ago → 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.