Closed Bug 2006333 Opened 8 months ago Closed 6 months ago

CFCA: EV Certificates misissued with incorrect businessCategory

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: songxinlei, Assigned: songxinlei)

Details

(Whiteboard: [ca-compliance] [ev-misissuance])

Attachments

(3 files)

revoked-certs.txt
433 bytes, text/plain
Details
affected-certs-2.txt
836 bytes, text/plain
Details
EV_certificates_since_2020.csv
1.25 MB, text/csv
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36

Steps to reproduce:

CFCA identified that a number of Extended Validation (EV) certificates issued to Chinese government entities were incorrectly classified with the subject:businessCategory (OID: 2.5.4.15) field set to "Private Organization" instead of "Government Entity" as required by the Guidelines for the Issuance and Management of Extended Validation Certificates (Version 2.0.1).

Preliminary Incident Report

Summary

  • Incident description: CFCA identified that a number of Extended Validation (EV) certificates issued to Chinese government entities were incorrectly classified with the subject:businessCategory (OID: 2.5.4.15) field set to "Private Organization" instead of "Government Entity" as required by the Guidelines for the Issuance and Management of Extended Validation Certificates (Version 2.0.1).

    The issue was identified through a Certificate Problem Report (CPR) received from a security researcher on December 5, 2025. The researcher provided detailed analysis demonstrating that certificates issued to entities with Unified Social Credit Identifiers beginning with "11" (indicating state organs) or "12" (indicating public institutions) according to the national standard GB 32100-2015 were incorrectly classified as "Private Organization" rather than "Government Entity."

    Upon investigation, CFCA confirmed that 16 affected certificates were identified in the initial CPR report. Of these 16 certificates, 14 were active and have been revoked on December 12, 2025. Two certificates had already expired at the time of discovery and therefore were not subject to revocation. New compliant certificates with correct businessCategory classification have been issued to replace the revoked certificates. CFCA is currently conducting a comprehensive review of all EV certificates to identify any additional instances of this issue.

  • Relevant policies:

    • Guidelines for the Issuance and Management of Extended Validation Certificates (Version 2.0.1), Section 9.2.1: Verification of the Applicant's Legal Existence and Identity. The Guidelines require that CAs properly classify entities as either "Private Organization" or "Government Entity" based on their legal status. A Government Entity is defined as "a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates." A Private Organization is defined as "a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration."

    • CA/Browser Forum Server Certificates Baseline Requirements v2.1.9, Section 7.1.3.2: Revocation for Inaccurate Information. "The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: 13. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn)."

    • National Standard GB 32100-2015: Coding Rules for the Unified Social Credit Identifier for Legal Persons and Other Organizations. The first digit represents the registration administration and the second digit represents the organization category. Identifiers beginning with "11" indicate state organs registered under the administration of institutional organization establishment. Identifiers beginning with "12" indicate public institutions registered under the same administration.

  • Source of incident disclosure: Third Party Reported. CFCA received a Certificate Problem Report (CPR) on December 5, 2025, from security researchers Zeyu Wang and Jianjun Chen of Tsinghua University, who identified the issue through analysis of certificate transparency logs. The reporters provided detailed technical analysis, including a list of affected certificates with serial numbers, Unified Social Credit Identifiers, organization names, and expiry dates; analysis demonstrating the incorrect classification based on the GB 32100-2015 standard; and specific examples showing certificates for the same organization with inconsistent classifications. CFCA acknowledges and credits Zeyu Wang and Jianjun Chen of Tsinghua University for their responsible disclosure and comprehensive technical analysis, which was essential in enabling prompt identification and remediation of this compliance issue.

    Note on CPR Receipt and Response Timing: The CPR was sent to cloudpki@cfca.com.cn, which is not CFCA's published CPR submission channel. As a result, the email was not immediately noticed by CFCA personnel responsible for handling CPRs. The CPR was discovered by relevant CFCA staff on December 8, 2025, at which point immediate action was taken to acknowledge receipt, initiate investigation, and begin remediation procedures.

Assignee: nobody → songxinlei
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance] [ev-misissuance]
Attached file revoked-certs.txt —
Attached file affected-certs-2.txt —

We've finished inspecting all valid EV certificates for potential same issue, and found 27 more EV certificates, and the re-issue/revoke process has began today, revocation is schedualed to be done on 2025-12-26.

A full incident report will be prepared after the whole process done.

Update: All 27 certificates had been revoked on 2025-12-26.

The full incident report is still under preparation, will be posted here asap.

Please note the Full Incident Report is now considered delayed.

The CCADB Incident Reporting Guidelines require Full Reports within 14 days of the incident's initial disclosure.

Flags: needinfo?(songxinlei)

Full Incident Report

Summary

  • CA Owner CCADB unique ID: A000272

  • Incident description: CFCA issued Extended Validation (EV) certificates to Chinese government entities with businessCategory field values that classified them as "Private Organization" instead of "Government Entity". This resulted from a logic defect in the mapping system that failed to identify specific entity types based on registration authority prefixes.

  • Timeline summary:

    • Non-compliance start date: 2024-12-25 (The first EV certificate with incorrect businessCategory issued among the affected certificates)
    • Non-compliance identified date: 2025-12-05
    • Non-compliance end date: 2025-12-26

  • Relevant policies:

    • Guidelines for the Issuance and Management of Extended Validation Certificates (Version 2.0.1)
    • CA/Browser Forum Baseline Requirements v2.1.9, Section 4.9.1.1 (Item 13)

  • Source of incident disclosure: Third Party Reported. Disclosure by security researchers Zeyu Wang and Jianjun Chen from Tsinghua University via CPR (Certificate Problem Report) on 2025-12-05

Impact

  • Total number of certificates: 43 certificates (16 identified via report + 27 discovered during inspection)

  • Total number of "remaining valid" certificates: 0 (all affected certificates have been revoked)

  • Affected certificate types: Extended Validation (EV) SSL/TLS certificates

  • Incident heuristic: Incorrect classification of government entities as "Private Organization" in the subject:businessCategory (OID: 2.5.4.15) field, where the entities' Unified Social Credit Identifier indicates they are government entities (codes starting with "11" for state organs or "12" for public institutions)

  • Was issuance stopped in response to this incident, and why or why not?:
    Issuance of EV certificates was suspended while we conducted an investigation to identify the scope of the issue. Issuance resumed after we implemented manual verification of the businessCategory field as a step in our vetting process as an interim measure. Automated system logic was updated and deployed on 2025-12-25, and issuance via API resumed on 2025-12-26. This ensured that no further certificates would be issued with the same classification while investigation and remediation for existing certificates continued.

  • Analysis:
    The incident affected certificates issued through two application channels:

    1. CloudPKI system: An online application platform where customers fill out forms directly. An unknown logic defect in the original system's data mapping module caused the system incorrectly identify entity types based on registration prefixes provided by local Industry and Commerce Bureau when calling the RA interface.
    2. Certificate order system: A platform where customers upload application forms for processing. The vetting workflow and forms were also designed with the same data mapping logic as above provided by local Industry and Commerce Bureau.

    Both systems interface with Registration Authority system (CTRA). The CTRA interacts with Certificate Transparency Logs (CTLog) to obtain Signed Certificate Timestamps (SCTs), then passes the request to the CA systems for final issuance. The classification error occurred at the interface between the upstream application systems and the CTRA, where the businessCategory field was populated incorrectly.

  • Additional considerations:
    N/A

Timeline

All times are in UTC+8 (China Standard Time)

  • 2025-12-05 23:37: CPR email sent by Zeyu Wang to a system-specific mailbox (cloudpki@cfca.com.cn) rather than the reporting channel defined in the CP/CPS.
  • 2025-12-08 09:57: Report identified and forwarded to the compliance team.
  • 2025-12-08 16:02: Confirmed 16 affected certificates and acknowledged the report to the submitter.
  • 2025-12-08 16:53: Initiated research on mapping table for EV businessCategory and GB 32100 standards
  • 2025-12-09 16:01: Started inspection of all valid EV certificates for potential same issue
  • 2025-12-10 15:42: New compliant certificates for affected domains issued
  • 2025-12-12 09:41: Completed EV businessCategory and GB 32100 mapping table
  • 2025-12-12 16:49:23: Received reply from CPR submitter confirming observation of new certificates with correct businessCategory
  • 2025-12-12 17:35: Revoked all non-compliant certificates from initial report
  • 2025-12-12 20:07: CRL check passed for all revoked non-compliant certificates
  • 2025-12-16: System development for automation of businessCategory field classification completed
  • 2025-12-22 11:33: Inspection completed, 27 additional certificates identified, initiated re-issue/revoke process
  • 2025-12-23: System release testing and version packaging completed
  • 2025-12-24: System deployed to test environment and passed verification
  • 2025-12-25: Release to production system completed
  • 2025-12-26: EV certificate issuance resumed via API interface with the updated logic
  • 2025-12-26 17:43: All 27 additional certificates revoked within the 5-day required timeframe

Related Incidents

Bug Date Description
Bug 1567588 2019-07-19 D-TRUST: incorrectly formatted businessCategory entry
Bug 1590810 2019-10-24 Sectigo: EV SSL Certificates with incorrect businessCategory
Bug 1593357 2019-11-04 QuoVadis: Incorrect EV businessCategory
Bug 1599561 2019-11-27 D-TRUST: EV certificates with incorrectly used businessCategory entry
Bug 1715929 2021-06-10 Sectigo: Incorrect EV businessCategory
Bug 1744518 2021-12-06 GlobalSign: EV certificates with serialNumber Government Entity and businessCategory Private Organization
Bug 1808485 2023-01-04 WISeKey: Incorrect businessCategory in EV certificate
Bug 1836694 2023-06-06 Hongkong Post: Invalid EV cert businessCategory

Root Cause Analysis

Contributing Factor #1: Logic defect in application system mapping modules

  • Description: The unknown data mapping logic defect in the application systems (CloudPKI and Certificate Order System) caused to incorrectly interpret registration data when calling the CTRA (Registration Authority) interface. Since Chinese government agencies (prefix 11) and public institutions (prefix 12) use Unified Social Credit Codes (USCC) instead of commercial registration numbers, the systems (CloudPKI and Certificate Order System) defaulted the organization category to "2" (Private Organization/Enterprise) when calling to the RA system.
  • Timeline: 2024-12-25, the first EV certificate with incorrect businessCategory issued among the affected certificates, but this logic existed since the CloudPKI system's integration with the registration data interface in 2020. The issue remained undetected until the CPR in December 2025.
  • Detection: The issue was identified through researcher analysis of Certificate Transparency logs, cross-referencing Unified Social Credit Identifier codes with businessCategory values of certificates.
  • Interaction with other factors: This factor interacted with Contributing Factor #2, as the original vetting workflow lacked logic to override the default system mapping for these specific entity types.
  • Root Cause Analysis methodology used: 5 Whys analysis, system code review, and timeline reconstruction.

Contributing Factor #2: Implementations in both systems(CloudPKI and Certificate order system) followed the defect logic in contributing factor #1 without human intervene

  • Description: The vetting workflow and application forms were designed with the defect mapping logic as above provided by local Industry and Commerce Bureau. The original process lacked logic to handle government entities with USCCs but without industrial and commercial registration numbers. This gap existed in both systems (CloudPKI and Certificate order system), and during the manual issuing stage in the Certificate order system, RA operators would select incorrect categories due to a lack of established rules for these entity types.
  • Timeline: This gap existed since the design of the Certificate order system. Some businessCategory classification rules were not fully implemented in the vetting workflow for non-commercial entities.
  • Detection: The issue was identified during investigation following the CPR.
  • Interaction with other factors: This factor contributed the logic defect in the mapping module, as no manual or automated override was triggered during the vetting process.
  • Root Cause Analysis methodology used: Process documentation review, vetting workflow analysis, and gap identification.

Contributing Factor #3: Knowledge gap in system design specifications

  • Description: Knowledge of system design specifications were not well-documented and shared among team members.
  • Timeline: This knowledge gap persisted from 2020 until the incident was identified in December 2025.
  • Detection: Identified during root cause analysis when it was confirmed that current staff did not have sufficient knowledge regarding the historical design of the mapping logic.
  • Interaction with other factors: This makes the defects in both contributing factors (#1, #2) remain undetected.
  • Root Cause Analysis methodology used: Staff interviews, training record review, and compliance requirement gap analysis.

Lessons Learned

  • What went well:

    • Acknowledgment and response to the CPR report within 3 days
    • Completed investigation and revocation of initial 16 certificates within the 5-day requirement (Baseline Requirements Section 4.9.1.1, Item 13)
    • Inspection of valid EV certificates, leading to discovery of 27 affected certificates
    • Coordination with affected customers to replace revoked certificates
    • Development of EV businessCategory and GB 32100 mapping table to aid future classification
    • Root cause analysis and corrective action planning

  • What didn't go well:

    • The logic defect existed for approximately 5 years (since 2020) before being detected.
    • Vetting processes did not have sufficient knowledge to conduct businessCategory verification for non-commercial entities when designed.

  • Where we got lucky:

    • The issue was discovered through disclosure by security researchers rather than a security incident.
    • All affected certificates were identified and revoked.
    • The GB 32100-2015 standard provided an additional reference to validate entity types.

  • Additional:

    • The incident highlights the importance of knowledge sharing and training when team members changed.
    • Default values of businessCategory in automated systems must be validated against compliance requirements.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Revoke affected certificates identified through the report and inspection Correct Remediation Certificates revoked, verified in CRL and CCADB 2025-12-26 Completed
Correct the CloudPKI system logic to allow verification of organization category Correct Root Cause #1 Logic updated and verified in production 2025-12-25 Completed
Develop and implement organization category vetting rules Prevent Root Cause #2 Documented vetting rules integrated into SMM 2025-12-29 Completed
Establish vetting process requiring verification staff to determine organization classification during review Prevent Root Cause #2 Vetting checklist in use 2025-12-29 Completed
Require certificate production staff to follow vetting-determined organization classification Prevent Root Cause #2 Staff trained and process verified 2025-12-29 Completed
Implement validation of businessCategory based on Unified Social Credit Code prefix Detect Root Cause #1, #2 Scripts running and alerting on discrepancies 2025-12-25 Completed
Enhance compliance requirements documentation in requirement specifications Prevent Root Cause #3 Updated templates in use 2026-01-31 In Progress
Conduct compliance training for development and testing teams on certificate profile and field requirements Prevent Root Cause #3 Training logs and assessment results 2026-01-31 Planned
Consolidate certificate profile specifications to update system validation logic and automated linting Prevent Root Cause #1, #2, #3 Updated specifications and validation rules 2026-02-28 Planned

Appendix

CPR Reporter Attribution:

  • Zeyu Wang, Tsinghua University
  • Jianjun Chen, Tsinghua University

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

Please note the Full Incident Report is now considered delayed.

The CCADB Incident Reporting Guidelines require Full Reports within 14 days of the incident's initial disclosure.

Hi incident-reporting,

Thanks for pointing this out, we will file another bug later for this.

Flags: needinfo?(songxinlei)

(In reply to Michael from comment #9)

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

Please note the Full Incident Report is now considered delayed.

The CCADB Incident Reporting Guidelines require Full Reports within 14 days of the incident's initial disclosure.

Hi incident-reporting,

Thanks for pointing this out, we will file another bug later for this.

Hi incident-reporting,

The bug was filed here Bug #2010525.

Hi,

We're still monitoring this. Since there're no other further comments, we'll prepare the closure report.

(In reply to Michael from comment #11)

Hi,

We're still monitoring this. Since there're no other further comments, we'll prepare the closure report.

Hi,
Thank you for your report. I have two questions about your full incident report.

Question 1, non-compliance start date

In the incident report, you state that the non-compliance started in December 2024. However, based on the description, the underlying logical defect appears to have been introduced as early as 2020.

Could you please clarify how the start date of non-compliance was determined?

Additionally, could you provide a complete list of all affected certificates from 2020 to the present, including certificates that have already expired? This would help external reviewers fully assess the scope and historical impact of the issue.

For reference, I have observed affected certificates issued in 2020, for example:
https://crt.sh/?id=3605794381

Question 2, the classification of one organization changed overtime.

Regarding the organization “中国民主同盟中央委员会”(English translation: Central Committee of the Chinese Democratic League), I noticed that its businessCategory value changed over time prior to my disclosure. Please refer to the table below:

crtsh ID not before not after Common Name Organization serial number of this organization Business Category
https://crt.sh/?id=4048040856 2021-02-08 2022-02-08 www.mmzy.org.cn 中国民主同盟中央委员会 11100000000017179M Non-Commercial Entity
https://crt.sh/?id=6056834388 2022-01-27 2023-02-27 www.mmzy.org.cn 中国民主同盟中央委员会 11100000000017179M Non-Commercial Entity
https://crt.sh/?id=8586999689 2023-02-06 2024-02-27 www.mmzy.org.cn 中国民主同盟中央委员会 11100000000017179M Non-Commercial Entity
https://crt.sh/?id=12194466432 2024-02-26 2025-02-26 www.mmzy.org.cn 中国民主同盟中央委员会 11100000000017179M Private Organization
https://crt.sh/?id=12497284896 2024-03-27 2025-03-26 www.mmzy.org.cn 中国民主同盟中央委员会 11100000000017179M Private Organization

Given that the organization name and serial number remain unchanged while only the businessCategory field has changed, could you please explain how the RA determines and inputs this field, and why the classification changed over time for the same organization? I would also like to know whether this field is determined through a documented, verifiable process or if it depends on manual judgment by individual operators. In particular, I would like to understand whether this change indicates that the value was entered based primarily on subjective assessment rather than consistent validation criteria. Thank you in advance for your clarification.

Flags: needinfo?(songxinlei)

Hi Zeyu Wang,

Thank you for your continuous attention to the security of webpki.

Could you please clarify how the start date of non-compliance was determined?

As stated in the full incident report:

Non-compliance start date: 2024-12-25 (The first EV certificate with incorrect businessCategory issued among the affected certificates)

The date was determined by the first non-compliant EV certificate among the inspection of all EV certificates which were still valid.

could you provide a complete list of all affected certificates from 2020 to the present, including certificates that have already expired?

Yes, we're exporting and inspecting all EV certificates from 2020 till now, the list will be provided later. This takes some time.

could you please explain how the RA determines and inputs this field, and why the classification changed over time for the same organization?

The certificate order switched to CloudPKI system in 2024, which has a design defect and caused the businessCategory field can't be set correctly according to vetting team members' decision.

We're now checking all EV certificates issued through CloudPKI after the system online in 2020 for mis-issuance.

whether this field is determined through a documented, verifiable process or if it depends on manual judgment by individual operators

We use a documented, verifiable process to determine this field, but as mentioned in the Contributing Factor #2, the original process lacked logic to handle government entities with USCCs but without industrial and commercial registration numbers. This gap existed in both systems (CloudPKI and Certificate order system), and during the manual issuing stage in the Certificate order system, RA operators would select incorrect categories due to a lack of established rules for these entity types.

Now, a mapping table between USCC and businessCategory is used to determine the businessCategory, but since exceptions exist among the mappings, we may need to manually verify the businessCategory field.

Flags: needinfo?(songxinlei)

Hi, we're updating the progress of Action Items:

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Revoke affected certificates identified through the report and inspection Correct Remediation Certificates revoked, verified in CRL and CCADB 2025-12-26 Completed
Correct the CloudPKI system logic to allow verification of organization category Correct Root Cause #1 Logic updated and verified in production 2025-12-25 Completed
Develop and implement organization category vetting rules Prevent Root Cause #2 Documented vetting rules integrated into SMM 2025-12-29 Completed
Establish vetting process requiring verification staff to determine organization classification during review Prevent Root Cause #2 Vetting checklist in use 2025-12-29 Completed
Require certificate production staff to follow vetting-determined organization classification Prevent Root Cause #2 Staff trained and process verified 2025-12-29 Completed
Implement validation of businessCategory based on Unified Social Credit Code prefix Detect Root Cause #1, #2 Scripts running and alerting on discrepancies 2025-12-25 Completed
Enhance compliance requirements documentation in requirement specifications Prevent Root Cause #3 Updated templates in use 2026-01-31 Completed
Conduct compliance training for development and testing teams on certificate profile and field requirements Prevent Root Cause #3 Training logs and assessment results 2026-01-31 Completed
Consolidate certificate profile specifications to update system validation logic and automated linting Prevent Root Cause #1, #2, #3 Updated specifications and validation rules 2026-02-28 Planned

(In reply to Zeyu Wang from comment #12)

Could you please clarify how the start date of non-compliance was determined?

Additionally, could you provide a complete list of all affected certificates from 2020 to the present, including certificates that have already expired? This would help external reviewers fully assess the scope and historical impact of the issue.

Hi, Zeyu Wang,

Please check out the attachment EV_certificates_since_2020.csv for the complete list of all affected certificates from 2020 to the present.

And we're updating the Full Incident Report, modify the non-compliance date according to the attachment EV_certificates_since_2020.csv:

Full Incident Report

Summary

  • CA Owner CCADB unique ID: A000272

  • Incident description: CFCA issued Extended Validation (EV) certificates to Chinese government entities with businessCategory field values that classified them as "Private Organization" instead of "Government Entity". This resulted from a logic defect in the mapping system that failed to identify specific entity types based on registration authority prefixes.

  • Timeline summary: All times below are in UTC+8.

    • Non-compliance start date: 2020-02-24 (The first EV certificate with incorrect businessCategory issued since 2020)
    • Non-compliance identified date: 2025-12-05
    • Non-compliance end date: 2025-12-26

  • Relevant policies:

    • Guidelines for the Issuance and Management of Extended Validation Certificates (Version 2.0.1)
    • CA/Browser Forum Baseline Requirements v2.1.9, Section 4.9.1.1 (Item 13)

  • Source of incident disclosure: Third Party Reported. Disclosure by security researchers Zeyu Wang and Jianjun Chen from Tsinghua University via CPR (Certificate Problem Report) on 2025-12-05

Impact

  • Total number of certificates: 300 certificates (16 identified via report + 27 discovered during inspection +257 expired certificates since 2020)

  • Total number of "remaining valid" certificates: 0 (all affected certificates have been revoked)

  • Affected certificate types: Extended Validation (EV) SSL/TLS certificates

  • Incident heuristic: Incorrect classification of government entities as "Private Organization" in the subject:businessCategory (OID: 2.5.4.15) field, where the entities' Unified Social Credit Identifier indicates they are government entities (codes starting with "11" for state organs or "12" for public institutions)

  • Was issuance stopped in response to this incident, and why or why not?:
    Issuance of EV certificates was suspended while we conducted an investigation to identify the scope of the issue. Issuance resumed after we implemented manual verification of the businessCategory field as a step in our vetting process as an interim measure. Automated system logic was updated and deployed on 2025-12-25, and issuance via API resumed on 2025-12-26. This ensured that no further certificates would be issued with the same classification while investigation and remediation for existing certificates continued.

  • Analysis:
    The incident affected certificates issued through two application channels:

    1. CloudPKI system: An online application platform where customers fill out forms directly. An unknown logic defect in the original system's data mapping module caused the system incorrectly identify entity types based on registration prefixes provided by local Industry and Commerce Bureau when calling the RA interface.
    2. Certificate order system: A platform where customers upload application forms for processing. The vetting workflow and forms were also designed with the same data mapping logic as above provided by local Industry and Commerce Bureau.

    Both systems interface with Registration Authority system (CTRA). The CTRA interacts with Certificate Transparency Logs (CTLog) to obtain Signed Certificate Timestamps (SCTs), then passes the request to the CA systems for final issuance. The classification error occurred at the interface between the upstream application systems and the CTRA, where the businessCategory field was populated incorrectly.

  • Additional considerations:
    N/A

Timeline

All times are in UTC+8 (China Standard Time)

  • 2025-12-05 23:37: CPR email sent by Zeyu Wang to a system-specific mailbox (cloudpki@cfca.com.cn) rather than the reporting channel defined in the CP/CPS.
  • 2025-12-08 09:57: Report identified and forwarded to the compliance team.
  • 2025-12-08 16:02: Confirmed 16 affected certificates and acknowledged the report to the submitter.
  • 2025-12-08 16:53: Initiated research on mapping table for EV businessCategory and GB 32100 standards
  • 2025-12-09 16:01: Started inspection of all valid EV certificates for potential same issue
  • 2025-12-10 15:42: New compliant certificates for affected domains issued
  • 2025-12-12 09:41: Completed EV businessCategory and GB 32100 mapping table
  • 2025-12-12 16:49:23: Received reply from CPR submitter confirming observation of new certificates with correct businessCategory
  • 2025-12-12 17:35: Revoked all non-compliant certificates from initial report
  • 2025-12-12 20:07: CRL check passed for all revoked non-compliant certificates
  • 2025-12-16: System development for automation of businessCategory field classification completed
  • 2025-12-22 11:33: Inspection completed, 27 additional certificates identified, initiated re-issue/revoke process
  • 2025-12-23: System release testing and version packaging completed
  • 2025-12-24: System deployed to test environment and passed verification
  • 2025-12-25: Release to production system completed
  • 2025-12-26: EV certificate issuance resumed via API interface with the updated logic
  • 2025-12-26 17:43: All 27 additional certificates revoked within the 5-day required timeframe

Related Incidents

Bug Date Description
Bug 1567588 2019-07-19 D-TRUST: incorrectly formatted businessCategory entry
Bug 1590810 2019-10-24 Sectigo: EV SSL Certificates with incorrect businessCategory
Bug 1593357 2019-11-04 QuoVadis: Incorrect EV businessCategory
Bug 1599561 2019-11-27 D-TRUST: EV certificates with incorrectly used businessCategory entry
Bug 1715929 2021-06-10 Sectigo: Incorrect EV businessCategory
Bug 1744518 2021-12-06 GlobalSign: EV certificates with serialNumber Government Entity and businessCategory Private Organization
Bug 1808485 2023-01-04 WISeKey: Incorrect businessCategory in EV certificate
Bug 1836694 2023-06-06 Hongkong Post: Invalid EV cert businessCategory

Root Cause Analysis

Contributing Factor #1: Logic defect in application system mapping modules

  • Description: The unknown data mapping logic defect in the application systems (CloudPKI and Certificate Order System) caused to incorrectly interpret registration data when calling the CTRA (Registration Authority) interface. Since Chinese government agencies (prefix 11) and public institutions (prefix 12) use Unified Social Credit Codes (USCC) instead of commercial registration numbers, the systems (CloudPKI and Certificate Order System) defaulted the organization category to "2" (Private Organization/Enterprise) when calling to the RA system.
  • Timeline: 2024-12-25, the first EV certificate with incorrect businessCategory issued among the affected certificates, but this logic existed since the CloudPKI system's integration with the registration data interface in 2020. The issue remained undetected until the CPR in December 2025.
  • Detection: The issue was identified through researcher analysis of Certificate Transparency logs, cross-referencing Unified Social Credit Identifier codes with businessCategory values of certificates.
  • Interaction with other factors: This factor interacted with Contributing Factor #2, as the original vetting workflow lacked logic to override the default system mapping for these specific entity types.
  • Root Cause Analysis methodology used: 5 Whys analysis, system code review, and timeline reconstruction.

Contributing Factor #2: Implementations in both systems(CloudPKI and Certificate order system) followed the defect logic in contributing factor #1 without human intervene

  • Description: The vetting workflow and application forms were designed with the defect mapping logic as above provided by local Industry and Commerce Bureau. The original process lacked logic to handle government entities with USCCs but without industrial and commercial registration numbers. This gap existed in both systems (CloudPKI and Certificate order system), and during the manual issuing stage in the Certificate order system, RA operators would select incorrect categories due to a lack of established rules for these entity types.
  • Timeline: This gap existed since the design of the Certificate order system. Some businessCategory classification rules were not fully implemented in the vetting workflow for non-commercial entities.
  • Detection: The issue was identified during investigation following the CPR.
  • Interaction with other factors: This factor contributed the logic defect in the mapping module, as no manual or automated override was triggered during the vetting process.
  • Root Cause Analysis methodology used: Process documentation review, vetting workflow analysis, and gap identification.

Contributing Factor #3: Knowledge gap in system design specifications

  • Description: Knowledge of system design specifications were not well-documented and shared among team members.
  • Timeline: This knowledge gap persisted from 2020 until the incident was identified in December 2025.
  • Detection: Identified during root cause analysis when it was confirmed that current staff did not have sufficient knowledge regarding the historical design of the mapping logic.
  • Interaction with other factors: This makes the defects in both contributing factors (#1, #2) remain undetected.
  • Root Cause Analysis methodology used: Staff interviews, training record review, and compliance requirement gap analysis.

Lessons Learned

  • What went well:

    • Acknowledgment and response to the CPR report within 3 days
    • Completed investigation and revocation of initial 16 certificates within the 5-day requirement (Baseline Requirements Section 4.9.1.1, Item 13)
    • Inspection of valid EV certificates, leading to discovery of 27 affected certificates
    • Coordination with affected customers to replace revoked certificates
    • Development of EV businessCategory and GB 32100 mapping table to aid future classification
    • Root cause analysis and corrective action planning

  • What didn't go well:

    • The logic defect existed for approximately 5 years (since 2020) before being detected.
    • Vetting processes did not have sufficient knowledge to conduct businessCategory verification for non-commercial entities when designed.

  • Where we got lucky:

    • The issue was discovered through disclosure by security researchers rather than a security incident.
    • All affected certificates were identified and revoked.
    • The GB 32100-2015 standard provided an additional reference to validate entity types.

  • Additional:

    • The incident highlights the importance of knowledge sharing and training when team members changed.
    • Default values of businessCategory in automated systems must be validated against compliance requirements.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Revoke affected certificates identified through the report and inspection Correct Remediation Certificates revoked, verified in CRL and CCADB 2025-12-26 Completed
Correct the CloudPKI system logic to allow verification of organization category Correct Root Cause #1 Logic updated and verified in production 2025-12-25 Completed
Develop and implement organization category vetting rules Prevent Root Cause #2 Documented vetting rules integrated into SMM 2025-12-29 Completed
Establish vetting process requiring verification staff to determine organization classification during review Prevent Root Cause #2 Vetting checklist in use 2025-12-29 Completed
Require certificate production staff to follow vetting-determined organization classification Prevent Root Cause #2 Staff trained and process verified 2025-12-29 Completed
Implement validation of businessCategory based on Unified Social Credit Code prefix Detect Root Cause #1, #2 Scripts running and alerting on discrepancies 2025-12-25 Completed
Enhance compliance requirements documentation in requirement specifications Prevent Root Cause #3 Updated templates in use 2026-01-31 Completed
Conduct compliance training for development and testing teams on certificate profile and field requirements Prevent Root Cause #3 Training logs and assessment results 2026-01-31 Completed
Consolidate certificate profile specifications to update system validation logic and automated linting Prevent Root Cause #1, #2, #3 Updated specifications and validation rules 2026-02-28 Planned

Appendix

CPR Reporter Attribution:

  • Zeyu Wang, Tsinghua University
  • Jianjun Chen, Tsinghua University

The modified report still has the Timeline summary containing a date that precedes the earliest date in the Timeline section.

Timeline summary: All times below are in UTC+8.
Non-compliance start date: 2020-02-24 (The first EV certificate with incorrect businessCategory issued since 2020)

and

Timeline
All times are in UTC+8 (China Standard Time)

2025-12-05 23:37: CPR email sent by Zeyu Wang to a system-specific mailbox (cloudpki@cfca.com.cn) rather than the reporting channel defined in the CP/CPS.

Please correct the latter, as this section needs to present the full timeline associated with the incident.

(In reply to Malcolm D from comment #17)

The modified report still has the Timeline summary containing a date that precedes the earliest date in the Timeline section.

Timeline summary: All times below are in UTC+8.
Non-compliance start date: 2020-02-24 (The first EV certificate with incorrect businessCategory issued since 2020)

and

Timeline
All times are in UTC+8 (China Standard Time)

2025-12-05 23:37: CPR email sent by Zeyu Wang to a system-specific mailbox (cloudpki@cfca.com.cn) rather than the reporting channel defined in the CP/CPS.

Please correct the latter, as this section needs to present the full timeline associated with the incident.

Hi Malcolm,

Thanks for flagging this error in the full report. Here goes the updated Full Incident Report:

Full Incident Report

Summary

  • CA Owner CCADB unique ID: A000272

  • Incident description: CFCA issued Extended Validation (EV) certificates to Chinese government entities with businessCategory field values that classified them as "Private Organization" instead of "Government Entity". This resulted from a logic defect in the mapping system that failed to identify specific entity types based on registration authority prefixes.

  • Timeline summary: All times below are in UTC+8.

    • Non-compliance start date: 2020-02-24 (The first EV certificate with incorrect businessCategory issued since 2020)
    • Non-compliance identified date: 2025-12-05
    • Non-compliance end date: 2025-12-26

  • Relevant policies:

    • Guidelines for the Issuance and Management of Extended Validation Certificates (Version 2.0.1)
    • CA/Browser Forum Baseline Requirements v2.1.9, Section 4.9.1.1 (Item 13)

  • Source of incident disclosure: Third Party Reported. Disclosure by security researchers Zeyu Wang and Jianjun Chen from Tsinghua University via CPR (Certificate Problem Report) on 2025-12-05

Impact

  • Total number of certificates: 300 certificates (16 identified via report + 27 discovered during inspection +257 expired certificates since 2020)

  • Total number of "remaining valid" certificates: 0 (all affected certificates have been revoked)

  • Affected certificate types: Extended Validation (EV) SSL/TLS certificates

  • Incident heuristic: Incorrect classification of government entities as "Private Organization" in the subject:businessCategory (OID: 2.5.4.15) field, where the entities' Unified Social Credit Identifier indicates they are government entities (codes starting with "11" for state organs or "12" for public institutions)

  • Was issuance stopped in response to this incident, and why or why not?:
    Issuance of EV certificates was suspended while we conducted an investigation to identify the scope of the issue. Issuance resumed after we implemented manual verification of the businessCategory field as a step in our vetting process as an interim measure. Automated system logic was updated and deployed on 2025-12-25, and issuance via API resumed on 2025-12-26. This ensured that no further certificates would be issued with the same classification while investigation and remediation for existing certificates continued.

  • Analysis:
    The incident affected certificates issued through two application channels:

    1. CloudPKI system: An online application platform where customers fill out forms directly. An unknown logic defect in the original system's data mapping module caused the system incorrectly identify entity types based on registration prefixes provided by local Industry and Commerce Bureau when calling the RA interface.
    2. Certificate order system: A platform where customers upload application forms for processing. The vetting workflow and forms were also designed with the same data mapping logic as above provided by local Industry and Commerce Bureau.

    Both systems interface with Registration Authority system (CTRA). The CTRA interacts with Certificate Transparency Logs (CTLog) to obtain Signed Certificate Timestamps (SCTs), then passes the request to the CA systems for final issuance. The classification error occurred at the interface between the upstream application systems and the CTRA, where the businessCategory field was populated incorrectly.

  • Additional considerations:
    N/A

Timeline

All times are in UTC+8 (China Standard Time)

  • 2020-02-24: The first EV certificate with incorrect businessCategory issued since 2020
  • 2025-12-05 23:37: CPR email sent by Zeyu Wang to a system-specific mailbox (cloudpki@cfca.com.cn) rather than the reporting channel defined in the CP/CPS.
  • 2025-12-08 09:57: Report identified and forwarded to the compliance team.
  • 2025-12-08 16:02: Confirmed 16 affected certificates and acknowledged the report to the submitter.
  • 2025-12-08 16:53: Initiated research on mapping table for EV businessCategory and GB 32100 standards
  • 2025-12-09 16:01: Started inspection of all valid EV certificates for potential same issue
  • 2025-12-10 15:42: New compliant certificates for affected domains issued
  • 2025-12-12 09:41: Completed EV businessCategory and GB 32100 mapping table
  • 2025-12-12 16:49:23: Received reply from CPR submitter confirming observation of new certificates with correct businessCategory
  • 2025-12-12 17:35: Revoked all non-compliant certificates from initial report
  • 2025-12-12 20:07: CRL check passed for all revoked non-compliant certificates
  • 2025-12-16: System development for automation of businessCategory field classification completed
  • 2025-12-22 11:33: Inspection completed, 27 additional certificates identified, initiated re-issue/revoke process
  • 2025-12-23: System release testing and version packaging completed
  • 2025-12-24: System deployed to test environment and passed verification
  • 2025-12-25: Release to production system completed
  • 2025-12-26: EV certificate issuance resumed via API interface with the updated logic
  • 2025-12-26 17:43: All 27 additional certificates revoked within the 5-day required timeframe

Related Incidents

Bug Date Description
Bug 1567588 2019-07-19 D-TRUST: incorrectly formatted businessCategory entry
Bug 1590810 2019-10-24 Sectigo: EV SSL Certificates with incorrect businessCategory
Bug 1593357 2019-11-04 QuoVadis: Incorrect EV businessCategory
Bug 1599561 2019-11-27 D-TRUST: EV certificates with incorrectly used businessCategory entry
Bug 1715929 2021-06-10 Sectigo: Incorrect EV businessCategory
Bug 1744518 2021-12-06 GlobalSign: EV certificates with serialNumber Government Entity and businessCategory Private Organization
Bug 1808485 2023-01-04 WISeKey: Incorrect businessCategory in EV certificate
Bug 1836694 2023-06-06 Hongkong Post: Invalid EV cert businessCategory

Root Cause Analysis

Contributing Factor #1: Logic defect in application system mapping modules

  • Description: The unknown data mapping logic defect in the application systems (CloudPKI and Certificate Order System) caused to incorrectly interpret registration data when calling the CTRA (Registration Authority) interface. Since Chinese government agencies (prefix 11) and public institutions (prefix 12) use Unified Social Credit Codes (USCC) instead of commercial registration numbers, the systems (CloudPKI and Certificate Order System) defaulted the organization category to "2" (Private Organization/Enterprise) when calling to the RA system.
  • Timeline: 2024-12-25, the first EV certificate with incorrect businessCategory issued among the affected certificates, but this logic existed since the CloudPKI system's integration with the registration data interface in 2020. The issue remained undetected until the CPR in December 2025.
  • Detection: The issue was identified through researcher analysis of Certificate Transparency logs, cross-referencing Unified Social Credit Identifier codes with businessCategory values of certificates.
  • Interaction with other factors: This factor interacted with Contributing Factor #2, as the original vetting workflow lacked logic to override the default system mapping for these specific entity types.
  • Root Cause Analysis methodology used: 5 Whys analysis, system code review, and timeline reconstruction.

Contributing Factor #2: Implementations in both systems(CloudPKI and Certificate order system) followed the defect logic in contributing factor #1 without human intervene

  • Description: The vetting workflow and application forms were designed with the defect mapping logic as above provided by local Industry and Commerce Bureau. The original process lacked logic to handle government entities with USCCs but without industrial and commercial registration numbers. This gap existed in both systems (CloudPKI and Certificate order system), and during the manual issuing stage in the Certificate order system, RA operators would select incorrect categories due to a lack of established rules for these entity types.
  • Timeline: This gap existed since the design of the Certificate order system. Some businessCategory classification rules were not fully implemented in the vetting workflow for non-commercial entities.
  • Detection: The issue was identified during investigation following the CPR.
  • Interaction with other factors: This factor contributed the logic defect in the mapping module, as no manual or automated override was triggered during the vetting process.
  • Root Cause Analysis methodology used: Process documentation review, vetting workflow analysis, and gap identification.

Contributing Factor #3: Knowledge gap in system design specifications

  • Description: Knowledge of system design specifications were not well-documented and shared among team members.
  • Timeline: This knowledge gap persisted from 2020 until the incident was identified in December 2025.
  • Detection: Identified during root cause analysis when it was confirmed that current staff did not have sufficient knowledge regarding the historical design of the mapping logic.
  • Interaction with other factors: This makes the defects in both contributing factors (#1, #2) remain undetected.
  • Root Cause Analysis methodology used: Staff interviews, training record review, and compliance requirement gap analysis.

Lessons Learned

  • What went well:

    • Acknowledgment and response to the CPR report within 3 days
    • Completed investigation and revocation of initial 16 certificates within the 5-day requirement (Baseline Requirements Section 4.9.1.1, Item 13)
    • Inspection of valid EV certificates, leading to discovery of 27 affected certificates
    • Coordination with affected customers to replace revoked certificates
    • Development of EV businessCategory and GB 32100 mapping table to aid future classification
    • Root cause analysis and corrective action planning

  • What didn't go well:

    • The logic defect existed for approximately 5 years (since 2020) before being detected.
    • Vetting processes did not have sufficient knowledge to conduct businessCategory verification for non-commercial entities when designed.

  • Where we got lucky:

    • The issue was discovered through disclosure by security researchers rather than a security incident.
    • All affected certificates were identified and revoked.
    • The GB 32100-2015 standard provided an additional reference to validate entity types.

  • Additional:

    • The incident highlights the importance of knowledge sharing and training when team members changed.
    • Default values of businessCategory in automated systems must be validated against compliance requirements.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Revoke affected certificates identified through the report and inspection Correct Remediation Certificates revoked, verified in CRL and CCADB 2025-12-26 Completed
Correct the CloudPKI system logic to allow verification of organization category Correct Root Cause #1 Logic updated and verified in production 2025-12-25 Completed
Develop and implement organization category vetting rules Prevent Root Cause #2 Documented vetting rules integrated into SMM 2025-12-29 Completed
Establish vetting process requiring verification staff to determine organization classification during review Prevent Root Cause #2 Vetting checklist in use 2025-12-29 Completed
Require certificate production staff to follow vetting-determined organization classification Prevent Root Cause #2 Staff trained and process verified 2025-12-29 Completed
Implement validation of businessCategory based on Unified Social Credit Code prefix Detect Root Cause #1, #2 Scripts running and alerting on discrepancies 2025-12-25 Completed
Enhance compliance requirements documentation in requirement specifications Prevent Root Cause #3 Updated templates in use 2026-01-31 Completed
Conduct compliance training for development and testing teams on certificate profile and field requirements Prevent Root Cause #3 Training logs and assessment results 2026-01-31 Completed
Consolidate certificate profile specifications to update system validation logic and automated linting Prevent Root Cause #1, #2, #3 Updated specifications and validation rules 2026-02-28 Planned

Appendix

CPR Reporter Attribution:

  • Zeyu Wang, Tsinghua University
  • Jianjun Chen, Tsinghua University

Hi, there's one Action Item left to be done, and we're working on it. No further updates yet.

Hi, we're tracking this bug, not further updates yet.

Hi, we're tracking this bug, not further updates yet.

Hi, the specifications and validation rules are updated, and will take effect on 2026-02-28, so we're updating the Action Item as Completed.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Revoke affected certificates identified through the report and inspection Correct Remediation Certificates revoked, verified in CRL and CCADB 2025-12-26 Completed
Correct the CloudPKI system logic to allow verification of organization category Correct Root Cause #1 Logic updated and verified in production 2025-12-25 Completed
Develop and implement organization category vetting rules Prevent Root Cause #2 Documented vetting rules integrated into SMM 2025-12-29 Completed
Establish vetting process requiring verification staff to determine organization classification during review Prevent Root Cause #2 Vetting checklist in use 2025-12-29 Completed
Require certificate production staff to follow vetting-determined organization classification Prevent Root Cause #2 Staff trained and process verified 2025-12-29 Completed
Implement validation of businessCategory based on Unified Social Credit Code prefix Detect Root Cause #1, #2 Scripts running and alerting on discrepancies 2025-12-25 Completed
Enhance compliance requirements documentation in requirement specifications Prevent Root Cause #3 Updated templates in use 2026-01-31 Completed
Conduct compliance training for development and testing teams on certificate profile and field requirements Prevent Root Cause #3 Training logs and assessment results 2026-01-31 Completed
Consolidate certificate profile specifications to update system validation logic and automated linting Prevent Root Cause #1, #2, #3 Updated specifications and validation rules 2026-02-28 Completed

Hi, as all Action items being completed, and no further comments, we're submitting the closure report.

Report Closure Summary

  • Incident description: CFCA issued Extended Validation (EV) certificates to Chinese government entities with businessCategory field values that classified them as "Private Organization" instead of "Government Entity". This resulted from a logic defect in the mapping system that failed to identify specific entity types based on registration authority prefixes.
  • Incident Root Cause(s): Logic defect in application system mapping modules; Implementations in both systems(CloudPKI and Certificate order system) followed the defect logic in contributing factor #1 without human intervene; Knowledge gap in system design specifications.
  • Remediation description: There're 9 Actions taken for remediations: Revoke affected certificates identified through the report and inspection, correct the CloudPKI system logic to allow verification of organization category, develop and implement organization category vetting rules, establish vetting process requiring verification staff to determine organization classification during review, require certificate production staff to follow vetting-determined organization classification, implement validation of businessCategory based on Unified Social Credit Code prefix, enhance compliance requirements documentation in requirement specifications, conduct compliance training for development and testing teams on certificate profile and field requirements, consolidate certificate profile specifications to update system validation logic and automated linting.
  • Commitment summary: We have improved detailed businessCategory SOP and related systems. We will enhance the vetting process during issuing certificates, and keep improving related SOPs.

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

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

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

Whiteboard: [ca-compliance] [ev-misissuance] → [close on 2026-03-10] [ca-compliance] [ev-misissuance]
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Whiteboard: [close on 2026-03-10] [ca-compliance] [ev-misissuance] → [ca-compliance] [ev-misissuance]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: