1914419 - Actalis: Use of CRLReason Code in Certificate Revocation

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Marco Menonna]

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.

Comment 1

[Marco Menonna]

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

Comment 2

[Marco Menonna]

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

Comment 3

[Marco Menonna]

We are writing to inform you of the progress on defined actions: to date we have completed development of the new revocation UI on our internal management application and are now testing it thoroughly.

Comment 4

[Marco Menonna]

To date, all action items have been completed as follows:

Action Item	Kind	Status
Retro-actively modify the reasonCodes of the affected revocations into the CA database so to conform them to the BR.	Correct	Done
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	Done
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	Done
Add more details to our internal documentation about the various circumstances requiring revocation and the appropriate CRLReason codes to be used accordingly.	Prevent	Done

Comment 5

[Adriano Santoni]

We do not have any further updates and would like to ask that this bug be closed.

Comment 6

[Ben Wilson]

Dear Marco,
Even though this has not yet been officially formalized as a bug-closure requirement, could you please provide a closing summary?
Thanks,
Ben

A closing summary should briefly:

• describe the incident, its root cause(s), and remediation;
• summarize any ongoing commitments made in response to the incident; and
• attest that all Action Items have been completed.

Here is a markdown template if needed:

Incident Report Closure Summary

• Incident Description: [Two or three sentences summarizing the incident.]
• Incident Root Cause(s): [Two or three sentences summarizing the root cause(s).]
• Remediation Description: [Two or three sentences summarizing the incident's remediation.]
• Commitment Summary: [A few sentences summarizing ongoing commitments made in response to this incident.]

All Action Items disclosed in this Incident Report have been completed as described, and we request its closure.

Comment 7

[Marco Menonna]

Incident Report Closure Summary

Incident Description:

We were notified that for the certificate revocations in Bugzilla reports #1906690 and #1883731, an incorrect CRLReason code was assigned. Instead of #4 (superseded), the revocations were marked with #0 (unspecified) or #5 (cessationOfOperation), not respecting the BRs that require - in the case of revocation due to non-compliance - the value #4.

Incident Root Cause(s):

The misclassification resulted from an outdated revocation UI in our internal certificate management application, where operators selected from ambiguous reason descriptions instead of BRs-compliant codes. Additionally, our compliance department did not formally specify the correct reason in the revocation request, leading to operator misinterpretation.

Remediation Description:

We corrected the reasonCodes in the CA database retroactively, redesigned the revocation UI to present clearer reason selections, and retrained operators. Additional internal documentation was created to ensure proper application of CRLReason codes.

Commitment Summary:

In addition of the completed actions our committment is to stay aligned with evolving BRs, continuously improving our tools and UI to prevent future misclassification. We will also provide ongoing retraining for our operators and we will ensure our documentation remains up to date.

All Action Items disclosed in this Incident Report have been completed as described, and we request its closure.

Comment 8

[Ben Wilson]

I'll close this sometime early next week, unless there are any additional issues or concerns.