Closed Bug 1819422 Opened 3 years ago Closed 3 years ago

Certainly: CRL Issuing Distribution Point Mismatch in CCADB

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wthayer, Assigned: wthayer)

Details

(Whiteboard: [ca-compliance] [disclosure-failure])

On 20 February 2023, Certainly became aware that our CCADB entries for the "JSON Array of Partitioned CRLs" did not precisely match the URL in the Issuing Distribution Point (IDP) extension of our end-entity CRLs, as may be required under section 6.1.2 of version 2.8.1 of the Mozilla Root Store Policy (MRSP).

1. How your CA first became aware of the problem.
Andrew Ayer announced the CRL Watch website, and it listed Certainly’s IDPs as having an error.

2. A timeline of the actions your CA took in response.
9/23/2022 Certainly deploys end-entity CRLs and updates CCADB with "JSON Array of Partitioned CRLs" for our two ICAs and two non-revoked cross-certs.
9/28/2022 Certainly changes configuration and updates CCADB to reference a single non-sharded CRL for each ICA.
10/1/2022 Mozilla and Apple policies requiring end-entity CRLs go into effect.
10/6/2022 CRL partitioning discussion thread is started by Corey Bonnell.
10/12/2022 Suggestion is made that using HTTPS might mitigate the concerns about the lack of IDPs raised in that thread.
11/15/2022 Certainly begins issuing sharded CRLs including IDP extensions. CCADB is updated to reference the new shards via the "JSON Array of Partitioned CRLs" with HTTPS URLs for the shards.
2/3/2023 Certainly reviews MRSP version 2.8.1 redline to ensure compliance. The IDP discrepancy is not apparent.
2/15/2023 MRSP version 2.8.1 goes into effect.
2/20/2023 Andrew Ayer announces CRL Watch on the CCADB mailing list.
2/20/2023 Certainly personnel check CRL Watch and become aware of this discrepancy.
2/20/2023 Certainly changes CCADB "JSON Array of Partitioned CRLs" entries for ICAs to use HTTP URLs.
2/21/2023 Certainly has the same changes made for the corresponding CCADB cross-certificate entries.
2/22/2023 Certainly adds a review of CRL Watch to weekly compliance monitoring activities.
2/28/2023 Incident report published

3. Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident.
The data in CCADB has been changed to comply with a strict interpretation of the MRSP.

4. In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
Not applicable.

5. In a case involving certificates, the complete certificate data for the problematic certificates.
Not applicable.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
When Certainly populated the "JSON Array of Partitioned CRLs" in CCADB for the affected ICAs after re-enabling CRL partitioning, we believed that there was no harm and possibly a modest benefit to using HTTPS URLs based on the earlier conversation on the Mozilla list. Certainly does not include CRL distribution points in end-entity certificates, so at this point the decision did not trigger any compliance concerns. However, this set up a potential conflict several months later with Mozilla’s updated root store policy that requires ‘a UniformResourceIdentifier whose value is derived from the URL as included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA‘. A “default deny” interpretation of that language is that a URL with an HTTP scheme is not “derived from” a URL that is identical except for the scheme. We did not identify this as a potential issue in a subsequent review of the MSRP 2.8.1 redline.

7. List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
Certainly has a number of compliance processes in place, including a review of each Mozilla policy update. We have now added a review of CRL Watch to our weekly compliance checklist as a second means of detecting future CRL issues.

We’d like to thank Andrew Ayer for providing CRL Watch to the community.

Assignee: nobody → wthayer
Status: NEW → ASSIGNED
Type: defect → task
Whiteboard: [ca-compliance] [disclosure-failure]

Certainly is monitoring this bug. We have completed all remediation steps.

We have no further updates, but Certainly will continue to monitor this bug for questions or suggestions.

Thanks, Wayne.

No further concern from the Chrome Root Program perspective. We think this report sufficiently satisfies the criteria described on the CCADB website.

Certainly has no further updates, but we continue to monitor this bug.

Unless there are other comments or concerns, I will close this on Friday, 24-Mar-2023.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.