2011865 - TrustAsia: SSL DV Mis-issuance against CP/CPS (IPAddress)

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[TrustAsia]

Attachment: dv-ip-certs.txt

Preliminary Incident Report

Summary

• Incident description:
  On 2026-01-22, while processing Bug 2011713,the TrustAsia compliance team conducted an internal review and discovered that the ICA "宝塔 TLS RSA CA 2025" had issued a total of 122 DV IP certificates (one of which has already been revoked) since 2025-11-24. This was in violation of Section 3.1.1 of the TrustAsia CP/CPS. We implemented a fix immediately upon confirming the issue. We will revoke all non-compliant certificates within 5 days and provide a full incident report as soon as possible. Progress on the revocations will be updated in a timely manner.

• Relevant policies:
  TrustAsia CP/CPS Section 3.1.1:"In the subjectAltName extension or subject:commonName field of DV and EV SSL/TLS server certificates, IP addresses will not be included. EV SSL/TLS server certificates do not contain wildcard."

• Source of incident disclosure:
  Self Reported

Comment 1

[TrustAsia]

All the affected certificates have been revoked.

Comment 2

[TrustAsia]

Information Correction

Based on further investigation conducted by the incident response team on 2026-01-24, we provide the following corrections to the Preliminary Incident Report and Comment #1:

1. Correction to ICA Information

• Correction Details: On 2026-01-24 18:50 (UTC+8), we identified that the issuing ICA was misidentified as "宝塔 TLS RSA CA 2025" in our Preliminary Incident Report. The correct ICA name is "宝塔 DV TLS RSA CA 2025" (https://crt.sh/?id=21942204861).

• Cause: This inaccuracy was caused by an inconsistency in internal information transfer during the rapid synthesis of the preliminary investigation results.

• Prevention: In subsequent processing workflows, we will rely on information parsed directly from certificates to ensure accuracy and avoid manual spelling errors.

2. Update on Affected Certificates and Revocation Status

• Correction Details:

  1. The certificate disclosed in the preliminary incident report (https://crt.sh/?sha256=BD8CD323B71A951DD9FFF866E06E2C9B7945B275B4B2767BEE6936F3966E3FF6) was revoked on 2026-01-24 19:26:03 (UTC+8).
  2. We are adding one affected certificate (https://crt.sh/?sha256=55529B9D826FDB131C4F35B0D54701B925F62A1867AAFBBE4402818E8DC76C3B). This certificate was revoked on 2026-01-23 00:00:00 (UTC+8) but was omitted from the information disclosed in the preliminary incident report.

  The final total of affected certificates is 123 (previously reported as 122), and all have been successfully revoked.

• Cause: The omission occurred because, in cases where one order corresponds to multiple certificates, the revocation operation previously only processed one certificate.

• Prevention: We have optimized the bulk revocation logic to prevent this issue from recurring.

Comment 3

[TrustAsia]

Investigation of the incident in progress and a full incident report will follow.

Comment 4

[TrustAsia]

Attachment: Bug2011865_Appendix.csv

Comment 5

[TrustAsia]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A007539

• Incident description: On 2026-01-22, while conducting an internal correlation review for another incident (Bug 2011713), the TrustAsia compliance team discovered that the Intermediate CA "宝塔 DV TLS RSA CA 2025" had issued DV SSL certificates containing IP addresses. This behavior violated Section 3.1.1 of TrustAsia CP/CPS v2.1.0, which explicitly does not allow the inclusion of IP addresses in DV certificates.

  • The root cause of this incident is the failure to fully assess CP/CPS constraints when responding to business requirement changes, along with a lack of mandatory compliance mapping in the system configuration change process. Additionally, the pre-issuance linting tools relied upon by TrustAsia primarily detect violations against CA/Browser Forum Baseline Requirements and lack customized checks for stricter internal CP/CPS regulations (prohibiting IPs in DV certificates).
  • A total of 123 certificates were affected, and all were revoked by 2026-01-24.

• Timeline summary:

  • Non-compliance start date: 2025-11-24 13:26 UTC+8
  • Non-compliance identified date: 2026-01-22 10:14 UTC+8
  • Non-compliance end date: 2026-01-22 14:36 UTC+8

• Relevant policies: TrustAsia CP/CPS v2.1.0 Section 3.1.1: "In the subjectAltName extension or subject:commonName field of DV and EV SSL/TLS server certificates, IP addresses will not be included. EV SSL/TLS server certificates do not contain wildcard."

• Source of incident disclosure: Self Reported

Impact

• Total number of certificates: 123
• Total number of "remaining valid" certificates: 0
• Affected certificate types: DV
• Incident heuristic: This incident affected all DV certificates containing IP addresses issued by the ICA "宝塔 DV TLS RSA CA 2025" (https://crt.sh/?id=21942204861).
• Was issuance stopped in response to this incident, and why or why not?:
  Yes. Upon confirming the violation of CP/CPS policies, we immediately rolled back the certificate system configuration and rejected any DV certificate orders containing IP addresses. Furthermore, we updated certificate profiles in the certificate system to technically prevent such issuances.
• Analysis: N/A
• Additional considerations: In the preliminary investigation, due to internal communication discrepancies, the ICA name was incorrectly reported as "宝塔 TLS RSA CA 2025"; after verification, the correct name is "宝塔 DV TLS RSA CA 2025". Additionally, due to an error in the batch revocation logic (which failed when processing multiple certificates under a single order), one revoked certificate was omitted from the initial report. This issue has been resolved in subsequent updates.

Timeline

All times are UTC+8.

2025-10-20

• CP/CPS v2.1.0 was published, in which Section 3.1.1 explicitly prohibits including IP addresses in DV TLS certificates.

2025-10-23

• 17:22 Modified certificate system configuration, and enabled certificate application and issuance service to the public for the ICA "宝塔 DV TLS RSA CA 2025".

2025-11-24

• 13:26 Modified the certificate system configuration to allow this ICA to accept DV certificate applications containing IP addresses.

2026-01-22

• 10:14 Internal audit discovered the violation of the CP/CPS.
• 10:32 Blocked IP certificate applications at the distribution system to prevent them from being submitted to the certificate system.
• 14:36 Modified the "宝塔 DV TLS RSA CA 2025" configuraations in the certificate system to disallow the submissions of IP certificate applications.
• 20:28 Changed the certificate profile configuration in the certificate system to no longer support IP addresses for DV certificates.
• 20:50 Preliminary incident report submitted.

2026-01-23

• ~00:00 Completed the revocation of 122 affected certificates.

2026-01-24

• 18:57 The internal team discovered the ICA name incorrectness and a missing certificate in the preliminary report.
• 19:30 Revoked the final affected certificate (https://crt.sh/?sha256=BD8CD323B71A951DD9FFF866E06E2C9B7945B275B4B2767BEE6936F3966E3FF6). All 123 affected certificates have been revoked.

2026-01-25

• 02:05 Corrected the preliminary report.

Related Incidents

Bug	Date	Description
1981680	2025-08-06	OV certificates contained Email attributes which are not allowed by the CP/CPS. This incident was attributed to insufficient post-change verification and an over-reliance on automated systems, which led to the oversight of CP/CPS specific constraints.
1979475	2025-07-24	Certificate extension configuration violated its CP/CPS requirements, specifically missing BasicConstraints extension. This incident similarly involved an inconsistency between system configurations and CP/CPS requirements.
1962830	2025-04-25	Key usage in TLS certificates was inconsistent with CP/CPS requirements.
1886876	2025-07-24	Violation of CP/CPS due to failure to revoke public keys associated with compromised keys.
1962829	2025-04-25	Mis-issuance caused by missing key usage which is explicitly required in the CP/CPS.

Root Cause Analysis

Contributing Factor #1: Lack of Custom Linting Tools for CP/CPS Requirements

• Description: The TrustAsia system lacked customized linting checks for its specific CP/CPS requirements. We have implemented standard linting tools including pkimetal for pre-issuance validation. However, since the CA/Browser Forum Baseline requirements do not prohibit the inclusion of IP addresses in DV certificates, the pkimetal failed to identify the error.
• Timeline: This flaw existed since the initial integration of standard linting tools into the system design. It was triggered following a configuration change on 2025-11-24, leading to non-compliance issuances until 2026-01-22.
• Detection: Discovered by the compliance team during an internal audit on 2026-01-22.
• Interaction with other factors: Had a customized CP/CPS linting with mandatory enforcement of CP/CPS Section 3.1.1 been in place, it would have served as a second line of defense to block the issuance despite human error in system configuration.
• Root Cause Analysis methodology used: 5 Whys

Contributing Factor #2: Incomplete Compliance Assessment (Gap between BRs and CP/CPS)

• Description: During the review of the configuration change request, the compliance team conducted an evaluation but primarily focused on CA/Browser Forum BRs. Because the BRs do not prohibit IP addresses in DV certificates, the team incorrectly assessed the change as "compliant".
  The evaluation process failed to mandate a cross-check against TrustAsia’s own CP/CPS requirements (specifically Section 3.1.1), which imposes stricter limitations than the BRs. This compliance gap resulted in the approval of a change that met industry requirements but violated CP/CPS policies.
• Timeline:
  • 2025-11-24 13:26 (UTC+8): Configuration change implemented without a comprehensive assessment against CP/CPS requirements.
  • 2026-01-22 14:36 (UTC+8): Configuration rolled back immediately following the discovery of the violation.
• Detection: Identified during the RCA phase following the incident.
• Interaction with other factors: This insufficient assessment led to the failure in identifying specific CP/CPS requirements. And combined with the lack of technical enforcement (Factor 1), this led to the certificate mis-issuances.
• Root Cause Analysis methodology used: 5 Whys

Lessons Learned

• What went well:
  • The issue was discovered internally and corrected promptly.
• What didn’t go well:
  • Technical controls were insufficient, specifically the failure to implement linting for CP/CPS specific requirements.
• Where we got lucky:
  • The incident was primarily localized to the ICA "宝塔 DV TLS RSA CA 2025", facilitating the effective control of the impact scope.
• Additional: N/A

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Revoke affected certificates	Mitigate	Root Cause #2	Status of all affected certificates is "Revoked".	2026-01-22	Complete
Roll back configuration changes	Mitigate	Root Cause #2	The certificate system is unable to issue DV-type IP certificates.	2026-01-22	Complete
Modify certificate profiles in certificate system	Prevent	Root Cause #2	Certificate profiles are updated in the certificate system and the issuance of IP certificates for all DV-type products are prohibited technically.	2026-01-22	Complete
Develop certificate linting tools for CP/CPS requirements	Prevent	Root Cause #1 & 2	Validate pre-certificates against CP/CPS requirements before issuance, and reject any certificate requests that are not compliant with CP/CPS requirements.	2026-03-05	Ongoing
Establish a mandatory "Change Checklist" in the configuration change process	Prevent	Root Cause #2	The change management process requires the compliance team to complete a Change Checklist for any modification affecting certificate content or issuance rules. This checklist explicitly verifies compliance with both the BRs and the CP/CPS. Internal audits verify that such changes include a completed checklist approved by the compliance team.	2026-03-05	Ongoing

Appendix

Refer to the attachment(Bug2011865_Appendix.csv).

Comment 6

[TrustAsia]

Action items #4 and #5 are in progress as scheduled. We kindly request setting the “Next update” date to 2026-03-05.

Comment 7

[TrustAsia]

We have completed all action items associated with this bug and will be posting our Report Closure Summary soon.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Revoke affected certificates	Mitigate	Root Cause #2	Status of all affected certificates is "Revoked".	2026-01-22	Complete
Roll back configuration changes	Mitigate	Root Cause #2	The certificate system is unable to issue DV-type IP certificates.	2026-01-22	Complete
Modify certificate profiles in certificate system	Prevent	Root Cause #2	Certificate profiles are updated in the certificate system and the issuance of IP certificates for all DV-type products are prohibited technically.	2026-01-22	Complete
Develop certificate linting tools for CP/CPS requirements	Prevent	Root Cause #1 & 2	Validate pre-certificates against CP/CPS requirements before issuance, and reject any certificate requests that are not compliant with CP/CPS requirements.	2026-03-05	Complete
Establish a mandatory "Change Checklist" in the configuration change process	Prevent	Root Cause #2	The change management process requires the compliance team to complete a Change Checklist for any modification affecting certificate content or issuance rules. This checklist explicitly verifies compliance with both the BRs and the CP/CPS. Internal audits verify that such changes include a completed checklist approved by the compliance team.	2026-03-05	Complete

Comment 8

[TrustAsia]

Report Closure Summary

• Incident description: Between 2025-11-24 and 2026-01-22, the TrustAsia Intermediate CA "宝塔 DV TLS RSA CA 2025" issued 123 DV SSL certificates containing IP addresses, which violated Section 3.1.1 of the TrustAsia CP/CPS. All affected certificates were successfully revoked by 2026-01-24.
• Incident Root Cause(s): This incident was caused by the lack of custom pre-issuance linting tools designed to enforce CP/CPS-specific business rules, combined with an incomplete compliance assessment during a configuration change that focused on CA/Browser Forum Baseline Requirements(BRs) but missed TrustAsia CP/CPS restrictions.
• Remediation description: We immediately revoked all 123 affected certificates, rolled back the configuration changes, and updated the CA system profiles to technically prohibit IP issuance for DV products. To prevent recurrence, we have successfully developed and deployed custom certificate linting tools to verify CP/CPS rules prior to issuance, and established a mandatory "Change Checklist" in our change management process to ensure all future modifications are evaluated against both the BRs and our CP/CPS.
• Commitment summary: Beyond the completed action items, TrustAsia will continue to refine our custom linting tools to better align our system configurations with our policies, helping to reduce the likelihood of misissuance caused by human error and configuration discrepancies.

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

Comment 9

[incident-reporting]

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

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