2012274 - Chunghwa Telecom: Issuance of certificate using keys previously reported as compromised

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Tsung-Min Kuo]

Preliminary Incident Report

Summary

• Incident description: On January 23, 2026, we became aware of certificates issued using the same private key previously revoked with reason code keyCompromise. Chunghwa Telecom has initiated an investigation to confirm that no additional certificates are impacted and to determine the root cause. As of today, our preliminary investigation has identified 7 affected certificates (with 1 expired). All of them have been revoked within 24 hours in accordance with the BR, and we will submit a Full incident report by February 6 (UTC+8).
• Relevant policies: TLS BR 6.1.1.3

The CA SHALL reject a certificate request if one or more of the following conditions are met:
...
4.The CA has previously been notified that the Applicant’s Private Key has suffered a Key Compromise using the CA’s procedure for revocation request as described in Section 4.9.3 and Section 4.9.12;

• Source of incident disclosure: Third party reported.

Comment 1

[Tsung-Min Kuo]

Investigation Status Update
As of 2026-01-30, our investigation was completed, and we have identified 8 affected certificates (with 2 expired). We will submit a Full incident report by February 6 (UTC+8).

Comment 2

[incident-reporting]

Were the 8 affected certificates DV, OV, or of another type?

Comment 3

[Tsung-Min Kuo]

(In reply to incident-reporting from comment #2)

Were the 8 affected certificates DV, OV, or of another type?

The 8 affected certificates were OV certificates.

Comment 4

[Tsung-Min Kuo]

Attachment: revokedcertsn_crtsh_v1_8.csv

Comment 5

[Tsung-Min Kuo]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A010946

• Incident description: On January 23, 2026, Chunghwa Telecom (CHT) received a third-party report indicating that certificates issued using the same private key previously revoked with reason code keyCompromise. Investigation revealed that due to missing system configuration, the issuance pipeline failed to reject CSRs using previously compromised keys.

  A comprehensive scan of all certificates issued by the affected Issuing CA revealed a total of 8 certificates associated with this incident—6 still valid at the time of detection and 2 already expired. After investigation, we confirmed 1 key that was first marked as keyCompromise was re-used to issue a new certificates(where a new issuance occurred after a keyCompromise revocation). However, we adopted a conservative interpretation to ensure subscriber safety: in all cases where two certificates shared the same key/CSR, if the newer certificate was revoked with keyCompromise at the subscriber’s request, the older certificate was also classified as affected and revoked. Within 24 hours, the affected certificates were revoked and system parameter corrections were introduced to prevent future issuance of reported compromised keys.

• Timeline summary:

  • Non-compliance start date: 2025-01-15
  • Non-compliance identified date: 2026-01-23
  • Non-compliance end date: 2026-01-29

• Relevant policies: TLS BR 6.1.1.3

The CA SHALL reject a certificate request if one or more of the following conditions are met:
...
4.The CA has previously been notified that the Applicant’s Private Key has suffered a Key Compromise using the CA’s procedure for revocation request as described in Section 4.9.3 and Section 4.9.12;

• Source of incident disclosure: Third party reported.

Impact

• Total number of certificates: 8
• Total number of "remaining valid" certificates: 0
• Affected certificate types: This incident affects OV certificates (with OID 2.23.140.1.2.2).
• Incident heuristic: The full corpus of affected certificates are disclosed in the Appendix.
• Was issuance stopped in response to this incident, and why or why not?: Apart from periodically issuing certificates for test websites, this CA has ceased issuing TLS certificates to subscribers as of 1 August 2025.
• Analysis:
  (a)Only 1 certificate issued using the key previously reported as compromised, and therefore should have been blocked from requesting a new certificate using the same key/CSR. The remaining cases involve subscribers having two certificates issued using the same key/CSR, where the most recent certificate was revoked at the subscriber’s request due to key loss. Since the newer certificate was revoked under keyCompromise, we determined that the older certificate should not remain valid. Accordingly, we strictly classify it as part of the affected set and revoke it as well.
  (b)After investigation, we confirmed that all revocation requests for the affected certificates were due to key loss. In accordance with the BR and RFC standards, the only permissible revocation reason is keyCompromise, rather than indicating that an attacker has obtained the key (compromise).
  (c)Over the past two years, other CAs have reported similar incidents, like 1927384, 1927532. We had implemented a tracking mechanism of related incidents to not miss the self-check of compliance. However, it was not established until early 2025, while those similar incident reports occurred in October 2024. As a result, these earlier cases were not incorporated into our tracking or review process.
• Additional considerations:

Timeline

All times are UTC+8.

2023-07-12

• Start time of the system configuration error / CA go live time.

2025-01-15

• First non-compliance certificate was issued. [start of the non-compliance]

2026-01-23

• 11:03 Received a third-party notification indicating a certificate issued using the same private key previously revoked with reason code keyCompromise.
• 11:40 CHT became aware of the incident. [Identify of the non-compliance]
• 11:51 Initiate preliminary internal review and check operations.
• 11:54 Verify whether the incident is factual, whether it violates the relevant requirements, and the timeframe to handling.
• 11:55 Identify the root cause of the incident.
• 11:56 Confirm the required timeframe for sending the preliminary investigation report to the third-party reported the non-compliance, and set up a notification.
• 12:10 Completed the initial investigation and confirmed that a total of 7 certificates were affected (including the reported one), with 6 still valid and 1 already expired.
• 15:20-17:05 Complete the process of notifying the affected subcribers by phone and email.
• 17:49 Complete the system parameter corrections to all our CA systems ensuring that the same issue will not occur again.
• 18:51 Complete the revocation of the first affected certificate.

2026-01-24

• 01:09 Send the Preliminary Report to the third party.
• 09:00-09:06 Complete the revocation of the remaining five affected certificates (6 revoked in total, with 1 expired).
• 10:00 Confirm that all OCSP response statuses are functioning normally.
• 18:44 Preliminary Incident Report posted on Bugzilla.

2026-01-26

• Scanned all expired certificates for potential impact and identified 1 additional expired certificate. (a total of 8 certificates were affected with 2 expired).

2026-01-27~2027-01-29

• Request the developer team to implement a linked revocation feature, ensuring that when the newer certificate is revoked under keyCompromise, any older certificates sharing the same key/CSR are automatically identified and included in the subsequent revocation process.

2026-01-29

• Investigation completed. [end of the non-compliance]

2026-02-02

• Deployment of the linked revocation feature to all CAs.

Related Incidents

Bug	Date	Description
1927384	2024-10-28	Issuance of certificate using keys previously reported as compromised.
1927532	2024-10-28	Issuance of certificate using keys previously reported as compromised.
2012157	2026-01-23	Issuance of certificate using keys previously reported as compromised.
2012326	2026-01-25	Issuance of certificate using keys previously reported as compromised.

Root Cause Analysis

Contributing Factor 1: Omission of KeyCompromise Validation Logic

• Description: A miscommunication during system updates resulted in the omission of the backend validator responsible for rejecting certificate requests that reused public keys associated with certificates previously revoked under keyCompromise.
  Because no secondary control or configuration audit was in place, the error persisted from the CA go‑live date (2023‑07‑12) until third‑party disclosure in 2026‑01‑23. This led to 1 certificate being improperly issued after a keyCompromise revocation, and additional certificates sharing the same key/CSR being conservatively treated as affected.
• Timeline:
  2023-07-12: Start time of the system configuration error / CA go live time.
  2025-01-15: First non-compliance certificate was issued.
  2026-01-23:
  • 11:03 Received a third-party notification indicating a certificate issued using the same private key previously revoked with reason code keyCompromise.
  • 11:40 CHT became aware of the incident.
• Detection: Notified by a third party.
• Interaction with other factors:
  (a)Our CA has a functional verification checklist, but the setting of Validation Logic was previously missing. It has now been added, and going forward we will periodically review it in line with updates to the BR.
  (b)Although only 1 certificate violated BR 6.1.1.3(4) by being issued after a keyCompromise revocation, we applied a conservative approach: whenever two certificates shared the same key/CSR and the newer one was revoked for keyCompromise, the older one was likewise deemed affected and revoked.

Contributing Factor 2: Insufficient Change Management and Configuration Controls

• Description: During system migration before 2025‑01‑15, the KeyCompromise validation logic was not transferred into the updated issuance workflow. We do have pre‑deployment checklist existed to do mandatory validation‑rule completeness checks and to ensure compliance rules remained correct. However, we found that the checklist was missing the key‑compromise validation logic check. This allowed the missing validator configuration to go undetected for an extended period.
• Timeline:
  2023-07-12: Start time of the system configuration error / CA go live time.
  2025-01-15: First non-compliance certificate was issued.
• Detection: Notified by a third party.
• Interaction with other factors: Missing Secondary Defense Mechanisms: tools such as zlint and pkimetal inspect only certificate structure. They are not designed to detect configuration oversight

Lessons Learned

• What went well:
  (a)Rapid internal coordination and timely response: Once the third party notification was received, CHT initiated the preliminary investigation within minutes and completed initial scoping within one hour, demonstrating strong readiness and cross team communication.
  (b)Prompt subscriber notification and incident communication: All affected subscribers were notified promptly by phone and email the same afternoon (15:20–17:05), ensuring transparency and mitigating subscriber impact.
  (c)Swift corrective actions: The system configuration corrections was completed the same day (17:49), and all valid affected certificates were revoked within the BR-required 24-hours timeframe.
• What didn’t go well:
  (a)Missing KeyCompromise validation logic due to configuration oversight.
  (b)Insufficient change management controls.
• Where we got lucky:
  (a)All misissued certificates belonged to the original subscribers.
  (b)No known exploitation of compromised keys
• Additional:

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Reinstated KeyCompromise Validation Logic	Prevent	Root Cause # 1 & 2	CSRs containing compromised keys must be rejected.	2026-01-23	Completed
Implement an "linked revocation" feature	Detect/Mitigate	Root Cause # 2	System automatically identifies older certificates sharing the same key/CSR whenever a newer certificate is revoked under keyCompromise	2026-02-02	Completed
Periodically secondary control or configuration audit	Detect/Prevent	Root Cause # 2	Periodically review system parameters to ensure correct configuration, and list the settings check as a check item in internal audit documents.	2026-02-10	Ongoing
Update the compliance tracking list to cover at least the past two years.	Detect/Prevent	Root Cause # 1	Conduct periodic reviews and develop CA self‑assessment checklists.	2026-02-12	Ongoing

Appendix

See Attached.

Comment 6

[Tsung-Min Kuo]

Action Items Update

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Reinstated KeyCompromise Validation Logic	Prevent	Root Cause # 1 & 2	CSRs containing compromised keys must be rejected.	2026-01-23	Completed
Implement an "linked revocation" feature	Detect/Mitigate	Root Cause # 2	System automatically identifies older certificates sharing the same key/CSR whenever a newer certificate is revoked under keyCompromise	2026-02-02	Completed
Periodically secondary control or configuration audit	Detect/Prevent	Root Cause # 2	Periodically review system parameters to ensure correct configuration, and list the settings check as a check item in internal audit documents.	2026-02-11	Completed
Update the compliance tracking list to cover at least the past two years.	Detect/Prevent	Root Cause # 1	Conduct periodic reviews and develop CA self‑assessment checklists.	2026-02-12	Delay

Comment 7

[Wayne]

(In reply to Tsung-Min Kuo from comment #6)

Action Items Update

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Update the compliance tracking list to cover at least the past two years.	Detect/Prevent	Root Cause # 1	Conduct periodic reviews and develop CA self‑assessment checklists.	2026-02-12	Delay

What delay have you ran into with this action item, and is there a new due date?

Comment 8

[Tsung-Min Kuo]

(In reply to Wayne from comment #7)

(In reply to Tsung-Min Kuo from comment #6)

Action Items Update

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Update the compliance tracking list to cover at least the past two years.	Detect/Prevent	Root Cause # 1	Conduct periodic reviews and develop CA self‑assessment checklists.	2026-02-12	Delay

What delay have you ran into with this action item, and is there a new due date?

We would like to conduct a more comprehensive review. The exact due date will be provided after the assessment.

Comment 9

[Tsung-Min Kuo]

We have updated the compliance tracking list to cover at least the past two years and integrated all identified issues into our CA self‑assessment checklists to support ongoing quarterly tracking and continuous compliance. Our CA team and compliance team conducted multiple rounds of confirmation and discussion on this issue, which required some time and could have potentially delayed the completion of the evaluation, we ultimately expedited and completed the final confirmation. Accordingly, we updated the following action items.

Action Items Update

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Reinstated KeyCompromise Validation Logic	Prevent	Root Cause # 1 & 2	CSRs containing compromised keys must be rejected.	2026-01-23	Completed
Implement an "linked revocation" feature	Detect/Mitigate	Root Cause # 2	System automatically identifies older certificates sharing the same key/CSR whenever a newer certificate is revoked under keyCompromise	2026-02-02	Completed
Periodically secondary control or configuration audit	Detect/Prevent	Root Cause # 2	Periodically review system parameters to ensure correct configuration, and list the settings check as a check item in internal audit documents.	2026-02-11	Completed
Update the compliance tracking list to cover at least the past two years.	Detect/Prevent	Root Cause # 1	Conduct periodic reviews and develop CA self‑assessment checklists.	2026-02-13	Completed

Comment 10

[Tsung-Min Kuo]

Chunghwa Telecom is monitoring this bug for comments and questions. We have no new information at the moment.

Comment 11

[Tsung-Min Kuo]

Chunghwa Telecom is monitoring this bug for comments and questions. We have no new information at the moment.

Comment 12

[Tsung-Min Kuo]

Report Closure Summary

• Incident description: On January 23, 2026, CHT received a third‑party report indicating that a TLS certificate had been issued using a private key that had previously been revoked with the reason code keyCompromise. Subsequent investigation confirmed that, due to a missing system configuration in the certificate issuance workflow, the CA did not reject CSRs that reused public keys associated with certificates previously revoked under keyCompromise, in violation of TLS BR 6.1.1.3(4).

  A comprehensive scan identified a total of 8 affected OV certificates, including 6 that were valid at the time of discovery and 2 that had already expired. Within 24 hours, the affected certificates were revoked and system parameter corrections were introduced to prevent future issuance of reported compromised keys.

• Incident Root Cause(s):
  (a)The primary root cause of this incident was the omission of KeyCompromise validation logic in the certificate issuance pipeline. During system migration and updates prior to 2025-01-15, the backend validator responsible for rejecting CSRs that reused keys from certificates previously revoked under keyCompromise was not migrated into the updated workflow.
  (b)This configuration oversight persisted from the CA go‑live date without detection due to insufficient change‑management and configuration controls. We do have pre‑deployment checklist existed to do mandatory validation‑rule completeness checks and to ensure compliance rules remained correct. However, we found that the checklist was missing the key‑compromise validation logic check. This allowed the missing validator configuration to go undetected for an extended period.

• Remediation description:
  Immediately after receiving the third‑party notification, CHT initiated an internal investigation, identified the affected certificates, and notified all impacted subscribers. All valid affected certificates were revoked within 24 hours in accordance with the Baseline Requirements, and OCSP status was verified to be functioning correctly.

  From a preventive perspective, the missing KeyCompromise validation logic was reinstated in the CA system on the same day, ensuring that any CSR reusing a key associated with a keyCompromise revocation is automatically rejected. In addition, a “linked revocation” feature was implemented and deployed in the CA system to ensure that, when a certificate is revoked under keyCompromise, any other certificates sharing the same key or CSR are automatically identified and included in the revocation process.

  Further remediation included the completion of secondary configuration audits, updates to internal deployment and audit checklists, and enhancements to compliance tracking to ensure that similar issues are proactively identified and addressed in the future.

• Commitment summary: CHT commits to maintaining continuous compliance with the TLS BR by ensuring that all key‑compromise related validation logic remains correctly configured and independently verified as part of system changes. We have strengthened configuration audits, compliance tracking, and self‑assessment processes, and will continue periodic reviews and monitoring of industry incidents to prevent recurrence and ensure sustained CA governance maturity.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 13

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2026-03-07.