On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote: > > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy > > <[email protected]> wrote: > > > > I looked through the CT logs and found 15 more unexpired unrevoked > > certificates that are trusted by NSS and appear to have the same inaccurate > > organizationName of “U.S. Government” for a non-USG entity. > > > > The list is here: https://misissued.com/batch/10/ > > > > Can you explain why your review missed these? Are there any more in > > addition to these 15 and previous 5? > > > > Jonathan > > After looking into this more, I’ve found that the majority of certificates > issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates > are not BR-compliant. > > The issues fall into three categories: > > 1) Certificates with HTTPS OCSP URLs > 2) Certificates with otherName SANs > 3) Certificates that appear to be intended as client certificates, but have > the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root > Policy. > > I’ve found 33 certificates that have one or more of these issues that are > unexpired and unrevoked. > > Here is the full list: https://misissued.com/batch/11/ (note that it is a > superset of the batch I posted earlier today) > > Jonathan
In reference to number 1)"Certificates with HTTPS OCSP URLs" Here is IdenTust reply in the recommended format: Issue: Certificates issued with HTTPS OCSP responder URL (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 7, 2017 2. Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below. IdenTrust: IdenTrust immediately began researching the issue. In parallel, we consulted with the ACES certificate policy owners to ensure we had the right interpretation of policy requirements. Upon confirmation of the problem, we updated the relevant the certificate profile on August 7, 2017 so that future issuance of TLS/SSL certificates is free of the identified problem. 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: Besides the 5 reported certificates, on August 16, 2017 we have identified another 309 ACES certificates with this issue. 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: The date range of the ACES certificates with this issue is from 08/21/2015 to 07/26/2017 5. Explanation about how and why the mistakes were made, and not caught and fixed earlier. IdenTrust: IdenTrust ACES SSL Certificates have been issued by IdenTrust in accordance with the ACES certificate policy defined by U.S. General Service Administration (http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/documents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust CPS (https://secure.identrust.com/certificates/policy/aces/IdenTrust_ACES_CPS_v5.1_20161110.pdf) IdenTrust started issuing ACES SSL Certificates since 2006 using the above reference guidelines which accept either http or https as acceptable values in the AIA extension for the OCSP validation. The issue reported was not caught earlier as none of ACES SSL certificate clients or relevant Relying party(s) have reported issues validating their certificates. 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. Effective August 7, 2017 the ACES SSL profiles have been updated to include only HTTP OCSP URLs. 2. Other IdenTrust SSL Sub-CA’s have been examined and confirmed that this issue does not exist. 3. We have been proactively contacting clients via email notifications and phone calls inviting them to replace those certificates. As of August 17 2017 AM we have a 242 ACES SSL certificates with this issue and we are seeing a positive trend from clients coming forward for replacement/revocation. On August 31, 2017 at the latest, we will be making a decision regarding any outstanding certificates with this issue and will post an update to the forum. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
