1814288 - SHECA: Delayed revocation of intermediate CA certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ben Wilson]

The following CAs were not revoked within 7 days as required by section 4.9.1.2 of the CA/Browser Forum Baseline Requirements (for TLS server certificates) and section 4.9.1.4 of the Baseline Requirements for Code Signing Certificates, which requires revocation when "The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with this document ...." Bug #1735908 provided notice in October 2021 that the certificates were defective and did not comply with X.690 as required by RFC 5280. According to the above-cited CABF requirements, certificates must comply with RFC 5280.

SHECA RSA Extended Validation Server CA
https://crt.sh/?sha256=4FD6FA527157EEA463689D7A4C2B934EF222279725413893D9847242C85CA9DF

SHECA RSA Domain Validation Server CA G3
https://crt.sh/?sha256=0A552A65F22FF820E7EC3D43BBF88B02ABC34BD247E0C3505891B6342F16A5F2

SHECA RSA Organization Validation Server CA G3
https://crt.sh/?sha256=26FD4C4367E463D39C71796AE4010E53380DC93BC132FB019D6718A6873E81F4

SHECA RSA Time Stamp Authority G1
https://crt.sh/?sha256=86EE4A2F93137CA8887674078B394070F189B3049DD2D24053AE92924254C668

SHECA RSA Code Signing CA G3
https://crt.sh/?sha256=C7E976AA77E92491C269840B2F1461E65147A2BB181EE59AB63BCD86704FE456

SHECA Extended Validation Code Signing CA
https://crt.sh/?sha256=A392C645B9A5AD6A214F19DE776346BC7DD6BB15818E433886DAC54EE6661852

Furthermore, a review of the revocation status of these certificates in crt.sh (links provided above) indicates the following error when checking OCSP for revocation status: "context deadline exceeded (Client.Timeout exceeded while awaiting headers)" and in some cases, "CRL status unknown" (due to a similar problem "context deadline exceeded (Client.Timeout exceeded while awaiting headers)").

SHECA is required to file an incident report, as explained here: https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report.

Comment 1

[Mathew Hodson]

SHECA should also explain why they provided no updates for 11 months in bug 1735908, which is contradictory to https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed and section 2.4 of the Mozilla Root Store Policy:

CA operators MUST regularly update the Incident Report until the corresponding bug is marked as resolved in the mozilla.org Bugzilla system by a Mozilla representative.

Comment 2

[chenxiaotong]

Accident Report

1.How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

In October 15th 2021, SHECA is made aware of this problem via this Bugzilla bug.

2.A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

As mentioned in Comment #2 of bug 1735908, when we were notified by Bugzilla, we took a series of actions to answer the issue, such as starting an investigation to find the cause of the issue, stopping these six affected ICAs, informing the subsribers of the leaf certificates issued by these problematic crts, and setting a quartly manual review of CA system configuration to avoid default value wrongly configured.
In addition, we evaluated the effects of the revocation on subscribers of these 6 sub-cas, so SHECA decided to revoke these 6 crts on late October, 2022.
During the 20th CPC National Congress, all online service providers are informed to operate smoothly to ensure the safety and normal operation of online service. So SHECA decided to postpone the revocation of these 6 crts to avoid negative effects.
In January 28th 2023, SHECA confirmed that all subscriber certificates under these 6 crts are invalid, revoked these 6 crts, and reported them to Mozilla.

3.Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

Yes, we have already stopped issuing any leaf certificates once we are aware of the issue，and make a statement of the termination about these 6 sub-CAs in the CP/CPS.

4.A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

Number: 6
First Cert:Mar 13 00:00:00 2015 GMT
Last cert: Apr 27 16:00:00 2018 GMT

5.The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

The problematic crts are list below:
https://crt.sh/?caid=83252,
https://crt.sh/?caid=83351,
https://crt.sh/?caid=83247,
https://crt.sh/?caid=83491,
https://crt.sh/?caid=83493,
https://crt.sh/?caid=50159

6.Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The improper encode componet is caused by improper configuration in CA system during issuance of intermediate root CA.
Since the validity start, all the leaf certs subscriber and other clients (relying parties) claim these problematic certs works normally, so SHECA didn't noticed this problem.

7.List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

SHECA's IT and technical team of CA system checked the configuration and notice the problem already fixed. Intermediate CA crts issued after the last problematic crt no longer have this problem.
SHECA had revoked these 6 crts on January 28th 2023

Furthermore, the problem you reported about OSCP and CRL, we guess it may caused by the network.We tried to use https://certificate.revocationcheck.com/, the OSCP and CRL which we provide is normal access.
We'd appreciate if you can provide any information about egress IP address of crt.sh, which we can add to the whitelist, to ensure correct revocation status are available via that channel.

Comment 3

[Mathew Hodson]

This incident report is woefully incomplete.

The provided timeline doesn't even include the date when SHECA was made aware. This is the core of the incident because the required revocation timeline is 7 days, and there are 471 days between 2021-10-14 and 2023-01-28.

The report doesn't even attempt to address the incident for this bug, which is why didn't SHECA revoke the certificates within 7 days as required. If SHECA miss-issued today, would you again take over a year to revoke? What changes are you making to ensure that your processes meet the requirements right now and that all future incident responses will meet the requirements?

Comment 4

[chenxiaotong]

Fo all the timeline you want and all the responde processes pelase refter to the prior bugzilla, https://bugzilla.mozilla.org/show_bug.cgi?id=1735908.

SHECA made it clear in bug 1735908 that we stopped issuing leaf certs of the 6 ICAs and we would revoke them after all the leaf certs expired.
The plan in the incident report was accepted that time, so we revoked these 6 ICAs after one year when the last leaf certs issued by these ICAs was expired.

In fact, I think if anything not conform to the Mozilla Trust Root policy in this case should be addressed in bug 1735908 one year ago after we filed that incident report, instead of brought up old scores today while had no comment that time, to make the affect to the lowest level and solve the problem efficiently.

But we still thank you for your attention to our compliance work.

Comment 5

[Ben Wilson]

I believe this can be closed and will do so on or about Friday, 7-Apr-2023.