SHECA: CRLReason code usage error
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: wangjiatai, Assigned: wangjiatai)
Details
(Whiteboard: [ca-compliance] [crl-failure])
Attachments
(1 file)
|
50.21 KB,
image/png
|
Details |
1724326234512.png
Incident Report
SHECA received an email reminder that in two cases of SHECA, the revoked certificates had confusing revocation reason codes.
https://bugzilla.mozilla.org/show_bug.cgi?id=1902947
https://bugzilla.mozilla.org/show_bug.cgi?id=1902592
Summary
SHECA is investigating this issue and will release a complete incident report within five days.
|
||
Updated•1 year ago
|
Incident Report
Summary
SHECA received an email notification that the revoked certificates in two recently closed cases had different revocation reason codes.
Impact
According to the BR guidelines, the CRLReason codes for subscriber certificates must comply with the requirements of TLS BR 4.9.1.1. In the mentioned case, the revoked certificates had multiple CRLReason codes, and the "privilegeWithdrawn" CRLReason code was used incorrectly.
According to the BR and Mozilla guidelines, the use of privilegeWithdrawn should be as follows:
privilegeWithdrawn
The CRLReason privilegeWithdrawn is intended to be used when there has been a subscriber-side infraction that has not resulted in key compromise, such as when the certificate subscriber provided misleading information in their certificate request or failed to uphold their material obligations under the subscriber agreement or terms of use.
Unless the keyCompromise CRLReason is being used, the CRLReason privilegeWithdrawn MUST be used when:
- The CA operator obtains evidence that the certificate was misused;
- The CA operator becomes aware that the certificate subscriber has violated one or more of its material obligations under the subscriber agreement or terms of use;
- The CA operator becomes aware that a wildcard certificate has been used to authenticate a fraudulently misleading subordinate fully-qualified domain name;
- The CA operator becomes aware of a material change in the information contained in the certificate;
- The CA operator determines or becomes aware that any of the information appearing in the certificate is inaccurate; or
- The CA operator becomes aware that the original certificate request was not authorized, and the subscriber does not retroactively grant authorization.
Otherwise, the privilegeWithdrawn CRLReason MUST NOT be used.
SHECA found that the CRLReason code of some revoked certificates does not comply with regulations. These certificates should not use privilegeWithdrawn as the CRLReason code。
SHECA adheres strictly to BR regulations in the use of CRLReason codes. Attached is a screenshot showing some of the reasons for certificate revocation selected by SHECA subscribers, all of which comply with BR regulations.
Detailed certificate revocation reasons are shown in the table below
Case 1: Bugzilla Case
| Link | Code | Revocation Date |
|---|---|---|
| Certificate 1 | unspecified (0) | 2024-06-14 |
| Certificate 2 | privilegeWithdrawn | 2024-06-14 |
| Certificate 3 | unspecified (0) | 2024-06-14 |
| Certificate 4 | unspecified (0) | 2024-06-19 |
| Certificate 5 | privilegeWithdrawn | 2023-11-08 |
| Certificate 6 | privilegeWithdrawn | 2023-11-08 |
| Certificate 7 | privilegeWithdrawn | 2023-10-17 |
| Certificate 8 | unspecified (0) | 2023-10-17 |
Case 2: Bugzilla Case
| Link | Code | Revocation Date |
|---|---|---|
| Certificate 1 | Expired | |
| Certificate 2 | privilegeWithdrawn | 2024-04-02 |
| Certificate 3 | privilegeWithdrawn | 2024-04-02 |
| Certificate 4 | superseded | 2024-06-17 |
| Certificate 5 | superseded | 2024-06-17 |
| Certificate 6 | privilegeWithdrawn | 2024-06-14 |
Timeline
All timestamps are in Beijing Time (UTC+8):
-
2023-08-22 00:00 Received notification email.
-
2023-08-22 09:00 Investigation began to determine the reasons behind the different revocation codes.
-
2023-08-22 12:47 Issue confirmed, and it was discovered that the system incorrectly assigned the wrong CRLReason codes.
-
2024-08-22 15:30 Reason for the issue:
-
unspecified (0): When SHECA's certificates encounter compliance issues, as a commercial CA, SHECA will do its utmost within the allowable regulations to ensure uninterrupted service for subscribers. We will promptly notify the subscribers to apply for a new replacement certificate through SHECA's issuance system. The subscriber will then request the revocation of their original certificate and choose the default CRLReason code "unspecified (0)," as most users do not understand the purposes of the other CRLReason code options.
-
privilegeWithdrawn: SHECA uses two RA systems, one of which has a defect. Even if the subscriber selects "unspecified (0)" the value ultimately transmitted to the CA system is "privilegeWithdrawn"
-
superseded: For subscribers who do not proactively request revocation, SHECA uses a script to batch revoke certificates, assigning the CRLReason code “superseded,” which is compliant with TLS BR 4.9.1.1 (12).
-
-
2024-08-22 15:31 Suspended all certificate revocation operations.
Root Cause Analysis
-
Why were different CRLReason codes used for the revoked certificates?
-
unspecified (0): When SHECA's certificates encounter compliance issues, as a commercial CA, SHECA will do its utmost within the allowable regulations to ensure uninterrupted service for subscribers. We will promptly notify the subscribers to apply for a new replacement certificate through SHECA's issuance system. The subscriber will then request the revocation of their original certificate and choose the default CRLReason code "unspecified (0)," as most users do not understand the purposes of the other CRLReason code options.
-
privilegeWithdrawn: SHECA uses two RA systems, one of which has a defect. Even if the subscriber selects "unspecified (0)" the value ultimately transmitted to the CA system is "privilegeWithdrawn"
-
superseded: For subscribers who do not proactively request revocation, SHECA uses a script to batch revoke certificates, assigning the CRLReason code “superseded,” which is compliant with TLS BR 4.9.1.1 (12).
-
-
Why wasn't this issue detected in time?
SHECA conducted a linting process on the signed CRL, but this process could not detect the issue. Although the value of the CRLReason code was correct, its usage did not strictly adhere to the BR guidelines, and SHECA's RA system imposed no special restrictions on the use of the "privilegeWithdrawn" CRLReason code.
Lessons Learned
What went well
SHECA strictly adheres to BR guidelines for using CRLReason codes and has established a comprehensive revocation process, allowing us to quickly identify the issue.
What didn't go well
This issue could not be detected using linting tools because the CRLReason codes were correct, but their usage context was incorrect.
Action Items
| Action Item | Type | Due Date |
|---|---|---|
| Fix the incorrect CRLReason code value transmission issue in the affected RA system. | Prevention | 2024-08-27 |
| Review all CRLReason code usage scenarios to confirm no further issues exist. | Prevention | 2024-08-30 |
| In the revocation process, restrictions on the use of the "privilegeWithdrawn" CRLReason code will be enhanced. If an operator chooses to revoke a certificate using the "privilegeWithdrawn" CRLReason code, they must upload relevant evidence of the subscriber's violation certificate. The certificate can only be officially revoked after the compliance department reviews and approves the evidence. | Prevention | 2024-08-30 |
Appendix
Detailed Information on Affected Certificates
| Link | CRLReason Code | Revocation Date |
|---|---|---|
| https://crt.sh/?id=10981773243 | unspecified (0） | 2024-06-14 |
| https://crt.sh/?id=11044872118 | privilegeWithdrawn | 2024-06-14 |
| https://crt.sh/?id=11033992247 | unspecified (0） | 2024-06-14 |
| https://crt.sh/?id=11032757670 | unspecified (0） | 2024-06-19 |
| https://crt.sh/?id=11031824086 | privilegeWithdrawn | 2023-11-08 |
| https://crt.sh/?id=11031824053 | privilegeWithdrawn | 2023-11-08 |
| https://crt.sh/?id=10810579104 | privilegeWithdrawn | 2023-10-17 |
| https://crt.sh/?id=10810577035 | unspecified (0） | 2023-10-17 |
| https://crt.sh/?id=12421772198（Expired） | ||
| https://crt.sh/?id=12573150826 | privilegeWithdrawn | 2024-04-02 |
| https://crt.sh/?id=12421770452 | privilegeWithdrawn | 2024-04-02 |
| https://crt.sh/?id=12421770586 | superseded | 2024-06-17 |
| https://crt.sh/?id=11917833535 | superseded | 2024-06-17 |
| https://crt.sh/?id=11044872118 | privilegeWithdrawn | 2024-06-14 |
Action Items
| Action Item | Type | Due Date | State |
|---|---|---|---|
| Fix the incorrect CRLReason code value transmission issue in the affected RA system. | Prevention | 2024-08-27 | completed |
| Review all CRLReason code usage scenarios to confirm no further issues exist. | Prevention | 2024-08-30 | completed |
| In the revocation process, restrictions on the use of the "privilegeWithdrawn" CRLReason code will be enhanced. If an operator chooses to revoke a certificate using the "privilegeWithdrawn" CRLReason code, they must upload relevant evidence of the subscriber's violation certificate. The certificate can only be officially revoked after the compliance department reviews and approves the evidence. | Prevention | 2024-08-30 | completed |
Hello Everyone, we have no further improvements to make regarding this case. I wonder if you still have any questions? If not, we would appreciate it if you could close this case.Thank you.
|
|
||
Comment 5•1 year ago
|
||
Are there any questions, comments, or issues that anyone would like to raise? If not, I will close this on or about Friday, 22-Nov-2024.
|
|
||
Updated•1 year ago
|
Hi Ben, it seems like everyone is aligned and there are no further questions regarding this case. Shall we go ahead and close it? Please let me know if there's anything else to address!
|
|
||
Comment 7•1 year ago
|
||
Hi,
You will need to provide a Closure Summary. See also https://www.ccadb.org/cas/incident-report#incident-closure-summary.
Thanks,
Ben
Incident Closure Summary
Incident description
During the system iteration process, the new and old RA systems run synchronously. Due to a bug in the newly developed RA system, the revocation reason code parameters transmitted to the CA system were inconsistent with the revocation code selected by the actual operator on the interface, resulting in abnormal revocation reasons for some certificates, which did not comply with BR regulations.
Incident Root Cause(s)
SHECA uses two RA systems, one of which has a defect. Even if the subscriber selects "unspecified (0)", the value finally transmitted to the CA system is still "privilegeWithdrawn".
Remediation description
-
Fix the CRLReason code value transmission problem in the affected RA system.
-
Check other functions related to revocation reasons in the system to ensure the correct use of revocation reason codes.
Commitment summary
- Strengthen the supervision of the use of revocation reason codes, and check 10% of the revoked certificates every month to ensure that the use of revocation reason codes meets BR requirements by querying the operation log. Mainly confirm the following behaviors:
-
Whether the revocation reason is consistent with the one selected by the subscriber on the application page.
-
Whether the reason code used by the operator to revoke the certificate is consistent with the actual reason why the certificate was actually revoked.
- Strengthen the operator's training on the use of revocation codes.
|
|
||
Comment 9•1 year ago
|
||
I will close this on Wed. 5-Mar-2025 unless additional discussion is needed.
|
|
||
Updated•1 year ago
|
Description
•