1848240 - TWCA: Undisclosed CA

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ben Wilson]

Section 5.3.2 of the Mozilla Root Store Policy (MRSP) requires CCADB disclosure of new subordinate CAs "within one week of certificate creation". https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited

There appears to be a subordinate CA that is not yet disclosed in the CCADB. It appears to have the same name as a prior certificate for TWCA Secure SSL Certification Authority (expiring on Oct. 28, 2024), but different keys.

Here is some pertinent information:

New CA Certificate (Not-Before Date: April 13, 2023)
https://crt.sh/?sha256=0ed5671aee9616cde7a2b1b3dd2398b6e11e591da9744922d8c32d17f67cca93&opt=mozilladisclosure
X509v3 Subject Key Identifier:
B5:B2:76:04:24:99:11:38:FD:11:D0:48:A6:B3:2A:52:12:8A:82:FC

Prior CA Certificate
https://crt.sh/?sha256=9B16F2F680D7C4BD6A67F609340DA6416ABF9E43F1326B01B988192271D0B5F2
X509v3 Subject Key Identifier:
F8:07:C2:68:24:FF:85:95:CB:DB:1E:E3:33:9C:2A:4F:97:20:56:7B

Neither of these CA certificates has been revoked.

Pursuant to section 2.4 of the MRSP, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents, TWCA is required to file an Incident Report - see https://wiki.mozilla.org/CA/Responding_To_An_Incident

Comment 1

[Hao-Chun Li]

Hi,
This CA certificate is indeed the new generation of "TWCA Secure SSL Certification Authority".
I have uploaded the certificate to CCADB and we have started investigation the issue.

Comment 2

[Hao-Chun Li]

Incident Report

Times are in UTC+8

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.

2023-08-11 10:00 I have received the notice from Bugzilla that a bug was posted by Mozilla that TWCA did not disclosed an intermediate CA certificate.

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.

2023-04-13 16:38 The CA certificate is issued to replace the prior CA certificate which is going to expire at 2023-10-28 23:59:59
2023-04-20 16:38 7 days passed since the certificate issuance and the CA certificate is not disclosed in CCADB, thus in violation of MRSP.
2023-08-10 07:00 We have switched our TLS certificate issuance system to use the new CA key and certificate.
2023-08-11 10:00 I received the notice from Bugzilla.
2023-08-11 10:46 We have confirmed the incident and begin actions to resolve the issue.
2023-08-11 11:28 We have uploaded the CA certificate in the CCADB (https://ccadb.force.com/0018Z000037HUHdQAO)
2023-08-11 11:50 We have switched certificate issuance back to the old CA certificate and stopped using the new CA certificate.

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.

We have stopped issue certificates from the CA certificate.

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.

1 CA certificate, issued on 2023-04-13

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.

The CA certificate:
https://crt.sh/?sha256=0ed5671aee9616cde7a2b1b3dd2398b6e11e591da9744922d8c32d17f67cca93

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

We did not properly communicated the requirement of disclosing intermediate CA certificates to the operational staff, and we did not revise the SOP of renewing CA certificate to add a step that the CCADB POCs must be noticed after CA certificate issuance.

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.

We are revising our SOP of CA certificate issuance to ensure that disclosing CA certificate in the CCADB is done and must be confirmed by compliance staff.

Comment 3

[Hao-Chun Li]

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

2023-08-11 10:00 I have received the notice from Bugzilla that a bug was posted by Mozilla that TWCA did not disclosed an intermediate CA certificate.

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.

2023-04-13 16:38 The CA certificate is issued to replace the prior CA certificate which is going to expire at 2023-10-28 23:59:59
2023-04-20 16:38 7 days passed since the certificate issuance and the CA certificate is not disclosed in CCADB, thus in violation of MRSP.
2023-08-10 07:00 We have switched our TLS certificate issuance system to use the new CA key and certificate.
2023-08-11 10:00 I received the notice from Bugzilla.
2023-08-11 10:46 We have confirmed the incident and begin actions to resolve the issue.
2023-08-11 11:28 We have uploaded the CA certificate in the CCADB (https://ccadb.force.com/0018Z000037HUHdQAO)
2023-08-11 11:50 We have switched certificate issuance back to the old CA certificate and stopped using the new CA certificate.
2023-08-17 14:59 We have revoked the CA certificate due to another issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1848306)
2023-09-07 16:50 Posting this report

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.

We have stopped issue certificates from the CA certificate immediately.

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.

1 CA certificate, issued on 2023-04-13, revoked at 2023-08-17 14:59

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.

The CA certificate:
https://crt.sh/?sha256=0ed5671aee9616cde7a2b1b3dd2398b6e11e591da9744922d8c32d17f67cca93

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   of disclosing intermediate CA certificates to the operational staff, and we did not revise the SOP of renewing CA certificate to add a step that the CCADB POCs must be noticed after CA certificate issuance.

• For us renewing issuing CA certificate is not a frequent task, so we have not been actively updating related SOPs.
• We did not sufficiently communicated the requirements (MRSP、CCADB) to operation team and urged them to revise related SOPs.
• The operation team was operating with outdated SOPs, which did not included the procedure to notify the CCADB contacts to upload the CA certificate to CCADB.
• The operation team was not aware of the requirements and did not understand the necessity to notify the CCADB contacts of the renewed CA certificate.

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.
   We are revising our SOP of CA certificate issuance to ensure that disclosing CA certificate in the CCADB is done and must be confirmed by compliance staff.

• Internally review all operational requirements, including BR, Root Program policies, and our CP/CPS, and create checklists for CA operational tasks (not limited to renewal of issuing CA certificate).
• Provide the aforementioned checklists to the operations team and incorporate them into the SOP for CA operational tasks.
• Whenever there are changes in the requirements, review and update the checklists in accordance with the changes.
• We expect to complete the checklists by the end of October.

Comment 4

[Ben Wilson]

In Comment #3, you indicated that your checklists would be completed by the end of October.
Please let me know when this has been accomplished so that we can close this matter.
Thanks,
Ben

Comment 5

[Hao-Chun Li]

Hi,

The checklists have been completed.
As stated in Comment #3, there are checklists for each CA lifecycle operations including but not limited to key generation and destroy, CA certificate issuance and revocation, CRL and OCSP service setups and profile changes, and comprise requirements from CA/B forum, Root Program policies, and our CP/CPS.

Comment 6

[Ben Wilson]

I will close this on or about 2023-11-01, unless there are comments or concerns.