Open Bug 1914419 Opened 1 month ago Updated 11 days ago

Actalis: Use of CRLReason Code in Certificate Revocation

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: marco.menonna, Assigned: marco.menonna)

Details

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

Preliminary Incident Report

We have been notified that for the bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=1906690 and https://bugzilla.mozilla.org/show_bug.cgi?id=1883731 , we used an inappropriate CRLReason revocation code when revoking the affected certificates.

A full incident report will be posted soon.

Assignee: nobody → marco.menonna
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [crl-failure]

Incident Report

Summary

We have been notified that in the certificate revocation we performed following the incidents described in bugs #1906690 and #1883731, we assigned an incorrect value to the reasonCode extension of the revoked certificates in light of the requirements in the BRs (section 7.2.2, Table 83: CRLReasons).

Impact

The CRLReason extension of revoked certificates should have had the value #4 (superseded), but instead it was assigned #0 (unspecified) or #5 (cessationOfOperation), thus not respecting the BRs that require - in the case of revocation due to non-compliance - the value #4.

Timeline

All times are CEST

  • 2023-07-15 - New CRL entries (for specific types of revocations) must have a revocation reason code due to BRs v1.8.7.

  • 2024-08-21 - 18:39: we received an e-mail notification reporting reporting a potential non-compliance in the use of CRLReason Code for the revoked certificates reported in the bugs #1906690 and #1883731

  • 2024-08-22 - 08:04: we aknowledged receipt of the problem report and confirmed that we had started investigating the issue.

  • 2024-08-22 - 8:17: a member of the compliance team started the analysis and involved the teams that revoked the certificates.

  • 2024-08-22 - 8:46: the revocation process and how the CRLReason Code is applied were analysed

  • 2024-08-22 - 9:00: Internal meeting for discussion of root cause analysis

  • 2024-08-22 - 17:13: we posted a preliminary report on Bugzilla

Root Cause Analysis

After receiving the notice, we started investigation in order to verify what was reported to us. We found that in fact those revocations were made with the wrong reasonCode in light of the BRs. This was materially caused by the selection of an incorrect revocation reason code when requesting the revocation to our CA.

Why an incorrect CRLReason code was applied for the revoked certificates?

We believe the root cause is two-fold.

  1. Actalis does not use a specific tool to revoke certificates in the case of mis-issuance, when the total number of certificates to be revoked is limited; instead, the internal certificate management application normally used by our CA operators. This application has a UI that, when the revocation of one or more certificates is requested, asks the operator to select from a drop-down menu not a reasonCode - which would be difficult to understand in itself - but a "reason for revocation" in natural language. Each reason is then internally associated with the suitable reasonCode. This part of our application was developed long before the BRs v1.8.7 came into force, which impose the use of specific reasonCodes in the various circumstances, and had not been modified since then. We have now realized that the various possible reasons that are proposed to the CA operator are not entirely clear and can be misunderstood. In fact, in the light of our investigations, it turned out that this is exactly what happened in the two occasions mentioned in the Summary. Therefore, it is necessary to modify the said UI so to present the operator with a clearer list of reasons and asks for explicit confirmation of the selected reason before the revocation is actually performed.
  2. Furthermore, when our compliance department requested the revocation of those certificates to our CA operators, they did not formally specify the reason for the revocation (although the reason was known, informally, to all internal stakeholders including CA operators), and this probably caused our CA operators to not pay much attention to the reason as to the need to revoke. Therefore, there is also a need to reinforce the procedural aspects.

Why wasn't this issue detected in time?

The problem was not detected because the reasonCode applied to those revocations was within the values ​​allowed by the BRs, although it was not appropriate for the circumstance. We have in place a linting of our CRLs that detects the use of non-allowed reasonCodes, but evidently such linting cannot detect the use of reasonCodes that are not appropriate for the circumstance.

Lessons Learned

What went well

This incident did not affect any active TLS certificates.

What didn't go well

We failed to identify the need to revise the revocation UI of our internal certificate management application following publication of BRs v1.8.7.

Action Items

Action Item Kind Status Due Date
Retro-actively modify the reasonCodes of the affected revocations into the CA database so to conform them to the BR. Correct Ongoing 2024-09-16
Re-design of the revocation UI on our internal certificate management application to remove any ambiguity in the list of revocation reasons and to ask the operator to confirm that the correct reason has been selected before proceeding with the operation Prevent Ongoing 2024-10-30
Re-training of our Revocation operators to improve understanding of the various possible causes for revocation provided for in the CAB Forum's BRs and the corresponding UI of our internal certificate management application. Prevent Ongoing 2024-10-30
Add more details to our internal documentation about the various circumstances requiring revocation and the appropriate CRLReason codes to be used accordingly. Prevent Ongoing 2024-10-30

To date we have completed following action items:

Action Item Kind Status Due Date
Retro-actively modify the reasonCodes of the affected revocations into the CA database so to conform them to the BR. Correct Done 2024-09-16
Re-design of the revocation UI on our internal certificate management application to remove any ambiguity in the list of revocation reasons and to ask the operator to confirm that the correct reason has been selected before proceeding with the operation Prevent Ongoing 2024-10-30
Re-training of our Revocation operators to improve understanding of the various possible causes for revocation provided for in the CAB Forum's BRs and the corresponding UI of our internal certificate management application. Prevent Ongoing 2024-10-30
Add more details to our internal documentation about the various circumstances requiring revocation and the appropriate CRLReason codes to be used accordingly. Prevent Ongoing 2024-10-30
You need to log in before you can comment on or make changes to this bug.