1907949 - iTrusChina: CRL Reason Codes

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ben Wilson]

Two revoked certificates are listed in iTrusChina's CRL with reason code 7, which is not defined in RFC 5280. Here's the crt.sh entry for one of the certificates: https://crt.sh/?id=13545712216. The other wasn't listed in crt.sh, but its issuer is "C = CN, O = "iTrusChina Co.,Ltd.", CN = vTrus DV SSL CA" and the serial number is 49270954BE5B66CE162B709ED02410702CC06963).

Comment 1

[iTrusChina Co.,Ltd.]

Thank you for pointing out the problem, we have started an investigation to review our processes. We are currently investigating the reason for the wrong CRL Reason Codes. The complete report will be published as soon as possible.

Comment 2

[iTrusChina Co.,Ltd.]

Attachment: www.quickcert.cn.cer

Comment 3

[iTrusChina Co.,Ltd.]

Incident Report

Summary

On 2024-7-16 , iTrusChina was notified that the CRL revocation code of its two certificates was “unknown #7”, which constituted a breach of the TLS BRs Section 7.2.2 and RFC 5280. The permitted revocation reasons only include keyCompromise #1, affiliationChanged #3, superseded #4, cessationOfOperation #5, privilegeWithdrawn #9, and unspecified(0).
Subsequent examination confirmed two certificates were affected, one certificate (https://crt.sh/?id=13545712216) and one precertificate (serial number is 49270954BE5B66CE162B709ED02410702CC06963).
For the precertificate issued and revoked on 2024-3-19, due to the CT Log Connection error, the issuance of the corresponding certificate failed, so the subscriber canceled the order. For such orders, our certificate management system revoked the precertificate with the default revocation reason of “unknown”, which did not comply with TLS BRs and RFC 5280.
For the certificate revoked on 2024-7-5, a system bug led our CA System could not correctly process unknown revocation reasons (such as the ones not permitted by BRs, wrong or irrelevant) provided by the subscriber, the system chose the wrong “unknown” as CRL reason code.

Impact

The incident impacted two revoked certificates (including one precertificate) but the incorrect revocation reason code does not affect subscribers' ability to revoke a certificate.

Timeline

All times are UTC+8.
For the first precertificate:
2024-03-19 14:10: A subscriber made a certificate request.
2024-03-19 16:23: Due to the CT Log connection error, the order was canceled by the subscriber, and our system revoked the corresponding precertificate with the revocation reason “unknown” .
For the second certificate:
2024-06-28 13:45: A subscriber made a certificate request, after verification in our CA System, the certificate was issued.
2024-07-05 10:15: The subscriber made a revocation request and the certificate was revoked automatically. Due to a similar system bug, the CRL reason code of the second certificate is also “unknown”.
2024-07-16 00:43: Ben sent an email to iTrusChina, notifying the CRL reason code of the above two certificates was wrong.
2024-07-16 9:08：iTrusChina was first aware of the incident and began the investigation.
2024-07-16: After internal examination, we confirmed only two certificates were impacted and corrected the CRL reason code to unspecified(0).

Root Cause Analysis

There are two root causes of this incident:

• The revocation reason for the precertificates of canceled orders in our system is “unknown”, which is not permitted by TLS BRs and RFC 5280.
• Our system allows subscribers to provide revocation reasons that may not permitted by TLS BRs or are incorrect or irrelevant, but the system could not correctly handle these unusual revocation reasons.

Lessons Learned

What went well

We have been consistently tracking changes in TLS BRs and RFC standards, and the revocation reason in our relevant systems has been correctly designed, so most CRL reason codes of revoked certificates were correct.

What didn't go well

• Because of the logic flaws, when revoking precertificates of canceled orders, their CRL reason was “unknown”, which does not comply with TLS-BRs and RFC 5280.
• We didn’t limit the revocation reasons which subscribers provide to the BR-permitted ones. When the revocation reasons are not BR-permitted, wrong, or irrelevant, the CRL reason codes of revoked certificates will be “unknown”.

Where we got lucky

• N/A

Action Items

Action Item	Kind	Due Date
Update our system to correctly process the precertificate revocation requests and unpermitted revocation reason requests per TLS BRs and RFC 5280.	Process	2040-8-10
Only allows subscribers to provide permitted revocation reasons.	Process	2040-7-19
Regularly scan the certificate revocation list to identify revocations reasons that do not comply with TLS BRs and RFC 5280.	Process	2040-7-23

Appendix

Details of affected certificates

• https://crt.sh/?id=13545712216.
• The precertificate’s serial number is: 49270954BE5B66CE162B709ED02410702CC06963

Comment 4

[Ben Wilson]

I think you meant "2024" for your Action Items.

Comment 5

[iTrusChina Co.,Ltd.]

Yes，that's "2024", thanks for your correction.

Comment 6

[iTrusChina Co.,Ltd.]

We have completed two processes in time as mentioned in action item.
the first one is that we prohibited subscribers from writing their own revocation reasons, instead requiring them to choose from a set of appropriate reasons.
the second one is that we have finished regularly scan in the certificate revocation list to identify revocations reasons that do not comply with TLS BRs and RFC 5280.

Comment 7

[iTrusChina Co.,Ltd.]

UPDATED Details of Action Items
We have updated our systems to correctly process the precertificate revocation requests and unpermitted revocation reason requests per TLS BRs and RFC 5280.
We have completed all the action items.

Comment 8

[Ben Wilson]

Before we close this, three items to address:

• Re: iTrusChina's remediation action item "Regularly scan the certificate revocation list to identify revocations reasons that do not comply with TLS BRs and RFC 5280." How often will you scan? Aside from that, from an ongoing compliance perspective, scanning is only a "detective" control. You need to be on top of preventative controls.
• Your remediation action items only addressed the direct causes of this singular incident. What are some preventative controls that you are implementing? For example, actively monitoring new and modified requirements so that you can incorporate those advancements into your code? (And thus avoid future incidents of non-compliance)
• Do you have programs in place for "continuous improvement" with PDCA cycles, which will help iTrusChina stay compliant with evolving standards and industry best practices?

Comment 9

[iTrusChina Co.,Ltd.]

(In reply to Ben Wilson from comment #8)
Hello Ben, thanks for your feedback.

Before we close this, three items to address:

• Re: iTrusChina's remediation action item "Regularly scan the certificate revocation list to identify revocations reasons that do not comply with TLS BRs and RFC 5280." How often will you scan? Aside from that, from an ongoing compliance perspective, scanning is only a "detective" control. You need to be on top of preventative controls.

We have set up a monitoring task on July 23, daily scanning our database to check whether the revoked certificates’ CRL reasons are BR-compliance. If not, the system will send an alarm to our compliance team and the alarm will be handled timely. To prevent such kind of incidents, we have improved our system to eliminate the root causes.

• Your remediation action items only addressed the direct causes of this singular incident. What are some preventative controls that you are implementing? For example, actively monitoring new and modified requirements so that you can incorporate those advancements into your code? (And thus avoid future incidents of non-compliance)

In addition to the system improvements, we also track changes in industry policies (quarterly, which includes BRs, root program policies, WebTrust Audit standards, etc) and Bugzilla incidents (monthly), and conduct internal self-examination to check whether we have similar problems. After that, we drive improvements in product development and operations to meet the changing requirements of different policies and prevent incidents. At present, we believe these measures are effective in preventing future non-compliance incidents.

• Do you have programs in place for "continuous improvement" with PDCA cycles, which will help iTrusChina stay compliant with evolving standards and industry best practices?

For your last question, iTrusChina has passed the ISO series certification, the PDCA model has been applied to the company's daily operation; For this incident, we will pay more attention to the effect of the improved system function and timely correct the deviation.

Comment 10

[Ben Wilson]

I will close this on or about Wed. 28-Aug-2024.