1856503 - SHECA: Failure to revoke within 5 days

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[chenxiaotong]

Steps to reproduce:

SHECA became aware that https://crt.sh/?id=7398187286 was misissued on 2022-09-07 and the revocation date in the CRL is 2022-09-19.
It doesn't meet the five day requirement from the BRs and we provide a separate incident report.

Actual results:

SHECA became aware that https://crt.sh/?id=7398187286 was misissued on 2022-09-07 and the revocation date in the CRL is 2022-09-19.

Expected results:

SHECA should revoke the certificate within five days.
For more information, please see bug 1798626

Comment 1

[jasmine.tang]

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 the MDSP or CCADB public mailing list, a Bugzilla bug, or internal self-audit), and the time and date.

At 08:24 UTC on September 7, 2022, SHECA was made aware of this problem via this Bugzilla. The following is the relevant case.https://bugzilla.mozilla.org/show_bug.cgi?id=1798626

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 requirement became applicable, a document changed, a bug was introduced, or an audit was performed.

20220907 08:24 UTC SHECA learned through Bugzilla notification that the certificate needs to be revoked.
The relevant cases are as follows：
https://bugzilla.mozilla.org/show_bug.cgi?id=1787537
https://bugzilla.mozilla.org/show_bug.cgi?id=1798626
20220907 11:00 UTC investigation initiated by the Information Security and Compliance Department.
20220907 14:30 UTC asked the customer if they could immediately revoke the certificate.
20220909 15:30 UTC Contact customer to follow up on status.
20220919 14:00 UTC customer agrees to revoke the certificate.
20220919 14:15 UTC certificate revocation.

3、Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

N/A

4、In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g., OCSP failures, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help measure the severity of each problem.

Number of certificates: 1
https://crt.sh/?id=7398187286

5、In a case involving TLS server certificates, 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. It is also recommended that you use this form in your list “https://crt.sh/?sha256=[sha256-hash]”, unless circumstances dictate otherwise. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

https://crt.sh/?id=7398187286

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

After revoking the remaining certificates, the customer has not agreed to our revocation of this certificate. The customer is a banking business with over tens of millions of customers worldwide, and they attach great importance to user privacy and data transmission security, providing all services through HTTPS. If the SSL certificate is urgently revoked, it will have adverse effects and losses on the customer. After communication, SHECA agreed to wait for the revocation until September 19, 2022. We received a response from the customer agreeing to revoke this certificate, but did not report this situation to Bugzilla in a timely manner, which is our mistake.

7、List of steps your CA is taking to resolve the situation and ensure that such a situation or incident will not be repeated in the future. The steps should include the action(s) for resolving the issue, the status of each action, and the date each action will be completed.

This incident is a good lesson for us, and we are deeply aware of the operational issues. In response to this situation, we have further improved the relevant emergency procedures:
Certificate customers with a large number of internet users, certificate revocation emergency processing process

1. Immediately establish a rapid response team internally to handle certificate revocation incidents.
2. Immediately contact the customer's relevant liaison personnel and explain the reasons for the situation, and communicate the progress at any time.
3. Immediately issue a replaceable certificate, and relevant technical personnel will remotely support customers to replace the certificate at any time.
4. We have learned from this lesson. If due to customer reasons, we are unable to revoke all certificates within five days, we will report this situation to Bugzilla in advance and update the progress at any time.
5. When signing cooperation agreements with clients, we will focus on promoting SHECA's right to proactively revoke certificates and the reasons behind it. We suggest that clients prepare backup plans for important infrastructure switching and advocate for clients to deploy dual brand certificates.

Comment 2

[Matthias]

5. When signing cooperation agreements with clients, we will focus on promoting SHECA's right to proactively revoke certificates and the reasons behind it.

This may suggest that you did not include this possibility in your agreements before this incident.
Did you not have this in your agreements yet, or do you mean that you're now adding more emphasis than previously on your right to revoke?

Comment 3

[chenxiaotong]

(In reply to Matthias from comment #2)

5. When signing cooperation agreements with clients, we will focus on promoting SHECA's right to proactively revoke certificates and the reasons behind it.

This may suggest that you did not include this possibility in your agreements before this incident.
Did you not have this in your agreements yet, or do you mean that you're now adding more emphasis than previously on your right to revoke?

All possible cases of revocation have been written in SHECA's CPS and agreements. we also ask our subscribers to know the contents of our CPS when we cooperate.
Since many subscribers are non-professionals and have limited understanding of it, we will emphasize our right of active revocation and compliance requirements. This may helps our subscribers to understand the necessary steps we take to meet BRs, and avoids spending too much time on communication.

Comment 4

[jasmine.tang]

We have nothing else pending to correct on our side regarding this issue and considered it close.

Comment 5

[Ben Wilson]

I'll schedule to close this on Wed. 18-Oct-2023.