Open Bug 1993357 Opened 3 months ago Updated 4 days ago

SHECA: TLS certificate key generation online

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: charter77, Assigned: wangjiatai)

Details

(Whiteboard: [ca-compliance] [dv-misissuance] [ov-misissuance] Next update 2026-01-31)

Attachments

(3 files)

Appendix 1.png
97.05 KB, image/png
Details
Appendix 2.docx
37.98 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
Appendix 3.jpg
140.20 KB, image/jpeg
Details

Refer to thread at https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/sAHY8ZjBPhM/m/S81E2WFlAgAJ discussing private key in online keygen service, and potential need for revoking certificates.

Flags: needinfo?(wangjiatai)

SHECA is currently retrieving some log data and will issue a preliminary accident report today.

Flags: needinfo?(wangjiatai)

Preliminary Incident Report

Summary

Incident description

According to the third-party notification, which is the final discussion result of the Google forum, the following three API API provided by SHECA to its partners violate some requirements of BR. SHECA will revoke all involved certificates within five days in accordance with BR's requirements.

/openApi/v1/order/getCertInfo
Function: Download certificates in all formats
Subscriber-provided parameters: Private key and order number
SHECA returns: An encrypted ZIP file containing certificates in various formats, including Nginx, Tomcat, and Apache.

/open-api/v2/order/download-zip
Function: Download certificates in all formats
Subscriber-provided parameters: Private key and order number
SHECA returns: An encrypted ZIP file containing certificates in various formats, including Nginx, Tomcat, and Apache.

/open-api/v2/tools/gen-csr
Function: Generate a certificate request (CSR)
Subscriber-provided parameters: None
SHECA returns: Certificate request (CSR) and private key.

See the thread at https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/sAHY8ZjBPhM/m/S81E2WFlAgAJ for more details

Relevant policies

BR 6.1.1.3:
"If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA."

BR 9.6.3:
"The Applicant is obligated and warrants to take all reasonable measures to ensure control, confidentiality, and proper protection at all times of the private key corresponding to the public key included in the requested Certificate (as well as any related activation data or devices, such as passwords or tokens);"

BR 4.9.1.1
"The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed (CRLReason #1, keyCompromise)".

Source of incident disclosure

Third party reported

Assignee: nobody → wangjiatai
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance] [dv-misissuance] [ov-misissuance]

Full Incident Report

Summary

  • CA Owner CCADB unique ID:

    SHECA（A000261）

  • Incident description:

    According to the third-party notification, which is the final discussion result of the Google forum, the following three API API provided by SHECA to its partners violate some requirements of BR. SHECA will revoke all involved certificates within five days in accordance with BR's requirements.

    /openApi/v1/order/getCertInfo
    Function: Download certificates in all formats
    Subscriber-provided parameters: Private key and order number
    SHECA returns: An encrypted ZIP file containing certificates in various formats, including Nginx, Tomcat, and Apache.

    /open-api/v2/order/download-zip
    Function: Download certificates in all formats
    Subscriber-provided parameters: Private key and order number
    SHECA returns: An encrypted ZIP file containing certificates in various formats, including Nginx, Tomcat, and Apache.

    /open-api/v2/tools/gen-csr
    Function: Generate a certificate request (CSR)
    Subscriber-provided parameters: None
    SHECA returns: Certificate request (CSR) and private key.

    See the thread at https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/sAHY8ZjBPhM/m/S81E2WFlAgAJ for more details

  • Timeline summary:

    • Non-compliance start date: 2023-05-30
    • Non-compliance identified date: 2025-10-07
    • Non-compliance end date: 2025-10-09

  • Relevant policies:

    BR 6.1.1.3:
    "If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA."

    BR 9.6.3:
    "The Applicant is obligated and warrants to take all reasonable measures to ensure control, confidentiality, and proper protection at all times of the private key corresponding to the public key included in the requested Certificate (as well as any related activation data or devices, such as passwords or tokens);"

    BR 4.9.1.1
    "The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed (CRLReason #1, keyCompromise)".

  • Source of incident disclosure:

    Third party reported

  • Impact

    • Total number of certificates: 18838

    • Total number of "remaining valid" certificates: 6920

    • Affected certificate types: OV-TLS (OID:2.23.140.1.2.2) and DV-TLS (OID:2.23.140.1.2.1）

    • Incident heuristic:

    • Was issuance stopped in response to this incident?

      Yes, as described in the timeline, SHECA has stopped certificate issuance through the non-compliant APIs by October 9, 2025. All three APIs have been taken offline, and subscribers have been notified that all certificates involved in this event will be revoked.

    • Analysis:

      This incident affects all certificates issued using the three aforementioned interfaces at 2025-10-09 23:59:59, and within their validity period.

      xinnet:

      UCA Global G2 Root - Xinnet DV SSL

      UCA Global G2 Root - Xinnet OV SSL

      All certificates issued under the two aforementioned ICAs at 2025-10-09 23:59:59, and within their validity period.

      Mobile Cloud:

      All valid certificates issued before 2025-10-09 23:59:59 in the Mobile Cloud account.

    • Additional considerations:

      Not applicable.

    Timeline

    All timestamps are Beijing time (UTC+8)

    2025-10-02 20:35: SHECA received a message in the MSDP discussion group regarding the online tool it provides to subscribers for generating CSRs and private keys.

    2025-10-04 05:42: SHECA obtained an initial response stating that if the relevant functions are implemented using JavaScript on the front-end interface and the CA itself does not access subscribers' private keys, this does not violate BR regulations. The community informed SHECA that there might be some issues with its current implementation code and provided professional rectification suggestions. SHECA has already started rectifying the relevant code, and the progress will be synchronized as a rectification item in this case.

    2025-10-06 06:57: SHECA received a notification indicating that the open APIs have accessed private keys, which may violate BR regulations. SHECA immediately launched an internal investigation to confirm the situation, identified BR violations, and promptly arranged for the offline deployment of the relevant APIs.

    2025-10-08 20:35: SHECA committed in the forum that it would revoke the affected certificates within the next five days according to the revocation timeframe in BR.

    2025-10-09 23:59: All three APIs have been taken offline, and subscribers have been notified that all certificates involved in this event will be revoked by 20:35 on October 13, 2025.

    2025-10-10 08:49: SHECA received a case notification from Bugzilla.

    2025-10-11 10:00: For users who have enabled the Xinnet automated service, automatic certificate reissue has been completed. Relevant users have been notified and are required to complete the replacement of their certificates within 24 hours to ensure the continued stable operation of their business systems and avoid service interruptions caused by untimely certificate updates.

    Related Incidents

    Bug Date Description
    1699756 2021-03-31 This Bug records the compliance review incident in 2021 where the Mozilla community checked whether the private key generation and storage process of ZeroSSL (a distributor under Sectigo) violated Mozilla's root certificate policy. After technical verification and multi-party communication, it was finally confirmed that ZeroSSL's process complied with the policy, and the Bug status was set to "RESOLVED INVALID".

    Root Cause Analysis

    Contributing Factor #1: Inadequate Pre-launch Compliance Review Mechanism for API Products

    • Description: The three problematic APIs were launched in 2023 (consistent with the non-compliance start date of 2023-05-30) but lacked a comprehensive BR compliance review process before launch. The pre-launch review only focused on functional realization and ignored compliance with core BR clauses related to private key management.

    • Timeline: The API design phase (Q1 2023) lacked compliance review; the APIs were formally launched in May 2023 (2023-05-30, the start date of non-compliance) and operated without correction until October 2025 when the violation was identified.

    • Detection: This issue was discovered by a third party and reported through the Google forum. However, due to the lack of API review during regular internal audits, this issue remained undetected.

    • Interaction with other factors:

      · This factor is the root cause of the incident. Without pre-launch compliance review, the API’s inherent non-compliance was not addressed, creating a long-term security loophole. Factor 2 further allowed the violation to persist.

    Contributing Factor #2: Incomplete Internal Inspection with Room for Coverage Improvement

    • Description: SHECA maintained regular internal inspections and self-assessments of certificate service processes, but there were blind spots in the coverage of API parameter design and private key flow tracking. In previous inspections, the focus was mainly on the CA system, RA system, and order systems—covering key links such as certificate issuance processes, data storage, and access control. The APIs involved in this incident were not included in the regular inspection framework, and they were not subject to in-depth compliance analysis and verification, forming a compliance blind spot

    • Timeline: From the API launch in May 2023 to the offline deployment in October 2025, internal inspections did not cover the aforementioned API compliance details.

    • Detection: The gaps were identified through internal investigation after receiving third-party notifications, prompting SHECA to recognize the need to improve inspection comprehensiveness.

    • Interaction with other factors:

      This factor prolonged the duration of the incident. Even though the pre-launch review had potential gaps (Factor 1), a more comprehensive internal inspection could have identified and addressed the issues earlier, reducing the number of affected certificates and the scope of impact.

      Root Cause Analysis methodology used

      This analysis adopts the Fishbone Analysis Method to systematically trace the causes of the incident: Core Problem (Fish Head): API products violated BR private key management regulations, and the non-compliant status lasted for 2 years (May 2023 - October 2025

    Categorization Dimension (Main Bone) pecific Influencing Factors (Sub-bones) Corresponding Details in the Case
    System Level Lack of pre-launch compliance review system There was no BR compliance review process for API products; only functional implementation was reviewed, while compliance with private key management was ignored
    Process Level Incomplete coverage of internal inspection processes Routine inspections only focused on CA/RA/order systems, and failed to include the private key management of the APIs in the inspection scope, resulting in compliance blind spots
    Awareness Level Insufficient awareness of compliance risks Failure to recognize that API products need to comply with BR private key management clauses, and failure to integrate compliance requirements into the entire lifecycle of API design, launch, and operation
    Tool/System Level Inadequate inspection tools/checklists Lack of dedicated inspection tools or checklists for API compliance, making it impossible to systematically verify whether APIs conform to BR regulations

    Lessons Learned

    • What went well:

      • Rapid emergency response: After receiving the third-party notification on October 6, SHECA immediately activated the emergency response mechanism, completed the internal investigation within a short time, confirmed the situation, and took the APIs offline by October 9—effectively preventing the expansion of potential risks and demonstrating event response capabilities.

    • What didn’t go well:

      During the National Day holiday (October 1st to October 8th), the team conducted the first round of inspections through remote collaboration. Due to the limitations of resource allocation and remote communication efficiency during the holiday, the call log of an API interface was missed.

    • Where we got lucky:

      • Smooth coordination with partners: During the incident handling process, partners actively cooperated with SHECA in the revocation and re-issuance of certificates, ensuring the efficient implementation of risk mitigation measures.

    • Additional: Not applicable.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Optimize the front-end Javascript code to generate CSR and private key Mitigate Not applicable Code optimization completed and deployed 2025-10-31 Ongoing
Optimize the pre-launch compliance review for products and services involving certificate services. Prevent Factor #1 The optimized review framework document is formally released. 2025-10-31 Ongoing
Establish a quarterly internal audit mechanism for certificate service APIs. Prevent Factor #1 The quarterly internal audit work plan is formulated and released. 2025-10-31 Ongoing
Strengthen communication and learning with the community to enhance understanding of BR, and consult the community for advice when in doubt. Mitigate Not applicable The training plan is completed and released. Training is conducted. 2025-10-31 Ongoing

Appendix

Xinnet cert:

https://raw.githubusercontent.com/SHECA-Alvin/CASE/refs/heads/main/xinet-cert.md

China Mobile Cloud cert

https://github.com/SHECA-Alvin/CASE/blob/main/ecloud-cert.md

SHECA will revoke all involved certificates within five days in accordance with BR's requirements.

The private keys involved in this incident were accessible to an unauthorised person (SHECA, which is explicitly not authorized to create private keys for subscriber certificates, per BR 6.1.1.3), which is the definition of a key compromise given in the BRs. Further, the private keys were "communicated to [...] an organization not affiliated with the subscriber" (SHECA), and thus must be revoked under 6.1.2. (which does not specify a time requirement, but it is a reasonable inference that this is also classified as a key compromise). Certificates for which the private key has been compromised must be revoked within 24 hours, per BR 4.9.1.1 point 3.

Inadequate Pre-launch Compliance Review Mechanism for API Products [...] This factor is the root cause of the incident.

No, it is not. What caused the compliance review of this API to be inadequate? Something down that rabbit hole is the actual root cause. Mistakes are never root causes, there are always systemic issues that need to be identified and rectified before anyone can be confident that this problem will not recur again.

All items are being executed, no other updates!

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Optimize the front-end Javascript code to generate CSR and private key Mitigate Not applicable Code optimization completed and deployed 2025-10-31 Ongoing
Optimize the pre-launch compliance review for products and services involving certificate services. Prevent Factor #1 The optimized review framework document is formally released. 2025-10-31 Ongoing
Establish a quarterly internal audit mechanism for certificate service APIs. Prevent Factor #1 The quarterly internal audit work plan is formulated and released. 2025-10-31 Ongoing
Strengthen communication and learning with the community to enhance understanding of BR, and consult the community for advice when in doubt. Mitigate Not applicable The training plan is completed and released. Training is conducted. 2025-10-31 Ongoing

(In reply to mpalmer from comment #4)

The private keys involved in this incident were accessible to an unauthorised person (SHECA, which is explicitly not authorized to create private keys for subscriber certificates, per BR 6.1.1.3), which is the definition of a key compromise given in the BRs. Further, the private keys were "communicated to [...] an organization not affiliated with the subscriber" (SHECA), and thus must be revoked under 6.1.2. (which does not specify a time requirement, but it is a reasonable inference that this is also classified as a key compromise). Certificates for which the private key has been compromised must be revoked within 24 hours, per BR 4.9.1.1 point 3.

We confirm that this should be classified as a key compromise, which requires revocation within 24 hours. We will update the report accordingly.

No, it is not. What caused the compliance review of this API to be inadequate? Something down that rabbit hole is the actual root cause. Mistakes are never root causes, there are always systemic issues that need to be identified and rectified before anyone can be confident that this problem will not recur again.

In the full report, SHECA used the fishbone diagram analysis method to conduct a systematic root cause analysis from four dimensions: system, process, awareness and tool, and formulated action plans for the problems found.

In the full report, SHECA used the fishbone diagram analysis method to conduct a systematic root cause analysis from four dimensions: system, process, awareness and tool, and formulated action plans for the problems found.

Applying any particular methodology does not guarantee that the actual root causes of a problem will be identified. In this case, I believe that the root causes have not been identified, as it is generally accepted within the safety culture community that human error cannot be a root cause, and "human error" is the root cause identified by SHECA's analysis.

Questions resulting from the MDSP Discussion

Reviewing the full incident report in comment 3 and comparing it with the discussion in MDSP, we would like SHECA to provide confirmation of the following points directly in this report:

  1. Please confirm that a full investigation of all ICAs under the UCA Global G2 Root and UCA Extended Validation Root has been completed. A community member in MDSP noted that over 15 ICAs could be affected, but the incident report focuses only on UCA Global G2 Root - Xinnet DV SSL and UCA Global G2 Root - Xinnet OV SSL. We need confirmation that the investigation concluded that no other ICAs utilized the problematic APIs.
  2. Please confirm that the TLS BR non-compliance was limited to the two server-side APIs identified in this report: (/openApi/v1/order/getCertInfo, /open-api/v2/order/download-zip)

Based on other information from the MDSP discussion that was not included in this incident report, we have a few questions.

In the MDSP thread, SHECA made the following statement on October 3, 2025, regarding the system that provides the online key generation: “This method generates CSRs by calling a back-end service interface. The back-end service is independent of SHECA's WebTrut systems (CA system, RA system, Validation system,etc.) and provides an access entry through a separate domain name. This system is not within the scope of the audit.”

On October 8, 2025, SHECA then stated: “SHECA acknowledges that the aforementioned two interfaces do violate the following rules in BR 6.1.1.3”

(Q1): Given that these APIs were used to generate private keys for TLS certificates subject to the TLS BRs, why did SHECA’s audit scoping process fail to include it?

(Q2): What changes are being made to ensure all applicable SHECA systems involved in the certificate lifecycle, regardless of their domain name or perceived independence, are included in future 3rd-party audits?

(Q3): In the MDSP discussion, a community member identified an online certificate format conversion tool (hosted on yuque.com) that instructed users to upload their private keys. This tool and its associated risks were not mentioned in this incident report. Can you confirm SHECAs stance on - and status of - this tool?

(Q4): In MDSP, SHECA stated that partners "signed corresponding subscriber agreements to obtain user authorization." However, a community member who purchased a certificate stated, "There was not any Subscriber Agreement during the ordering process." Please resolve this perceived contradiction. Was a subscriber agreement, which properly informs subscribers of their key protection responsibilities, presented to and agreed upon by every subscriber whose certificate was issued via these problematic APIs? Can you please describe how?

(Q5): It was also alleged in the MDSP discussion that the /open-api/v2/tools/gen-csr interface encrypted newly generated private keys with a default weak password of "123456" if a stronger password was not provided. Can you confirm if this was the case?

Additional questions

(Q6): Can you please directly confirm the following actions have taken place?

  1. SHECA has searched its full corpus (considering all its hierarchies) for any certificate containing a public key that corresponds to a private key generated by the tooling resulting in this incident.
  2. SHECA has added all of these keys to a blocklist, which will be considered by any of SHECA’s BR-compliant hierarchies going forward, regardless of whether that hierarchy was responsible for issuing a certificate corresponding to this incident.

(Q7): Your Root Cause Analysis identifies an "Inadequate Pre-launch Compliance Review Mechanism for API Products" as a contributing factor and also the root cause of the incident. The CCADB IRGs require the RCA to explain why a failure was possible, not just what failed. Please expand on this root cause. What specific systemic failures in SHECA (e.g., lack of compliance team authority, insufficient training for developers, absence of a formal security sign-off process for new APIs, etc.) allowed a non-compliant API to be designed, built, and launched without being detected?

(Q8): Your proposed Action Items include optimizing the pre-launch compliance review and establishing a quarterly internal audit. To ensure these actions are effective and not just procedural, please provide more detail:

  1. Will the pre-launch review now include a mandatory, formal sign-off from a dedicated compliance team or officer who has the authority to block the launch of any new product or API?
  2. What is the specific, documented scope of the new quarterly audit for certificate service APIs, and should its findings be made available to your Qualified Auditors for review during the annual audit?

(Q9): This incident was not caused by a software flaw but by a feature that was intentionally designed and deployed. This suggests a systemic gap in understanding the TLS BRs within SHECA product development and engineering teams. What specific, preventative process changes will be implemented for the product and engineering teams responsible for these APIs to ensure that non-compliant features are never designed or approved in the future?

Comment: The appendices of affected certificates is not in the CCADB IRG described format. Additionally, many of these final certificates are not disclosed to CT. The absence of posting the precert hash makes it difficult for community members to study these certificates (like this one: https://crt.sh/?q=1F489306F21A5BCC6B1201AE3A9909AF5300F5828347EA1D0F0983318B15ED5C, which corresponds to https://github.com/SHECA-Alvin/CASE/blob/main/ecloud-cert.md?plain=1#L5.)

Flags: needinfo?(wangjiatai)

(In reply to chrome-root-program from comment #8)

Questions resulting from the MDSP Discussion

Reviewing the full incident report in comment 3 and comparing it with the discussion in MDSP, we would like SHECA to provide confirmation of the following points directly in this report:

  1. Please confirm that a full investigation of all ICAs under the UCA Global G2 Root and UCA Extended Validation Root has been completed. A community member in MDSP noted that over 15 ICAs could be affected, but the incident report focuses only on UCA Global G2 Root - Xinnet DV SSL and UCA Global G2 Root - Xinnet OV SSL. We need confirmation that the investigation concluded that no other ICAs utilized the problematic APIs.

Scope of Investigation: All active ICAs under UCA Global G2 Root and UCA Extended Validation Root
Investigation Dimensions: API call logs, account permissions
Investigation Result: Xinnet and China Mobile Cloud have used the problematic APIs. Please refer to Appendix 1 for the corresponding mapping between customers and ICAs.

  1. Please confirm that the TLS BR non-compliance was limited to the two server-side APIs identified in this report: (/openApi/v1/order/getCertInfo, /open-api/v2/order/download-zip)

According to the full incident report, there are 3 APIs that violate BR regulations. The API paths and functions are as follows. SHECA has provided the complete English version of the OpenAPI documentation in Appendix 2 for your review.
1./openApi/v1/order/getCertInfo
Function: Download certificates in all formats
Subscriber-provided parameters: Private key and order number
SHECA returns: An encrypted ZIP file containing certificates in various formats, including Nginx, Tomcat, and Apache.

2./open-api/v2/order/download-zip
Function: Download certificates in all formats
Subscriber-provided parameters: Private key and order number
SHECA returns: An encrypted ZIP file containing certificates in various formats, including Nginx, Tomcat, and Apache.

3./open-api/v2/tools/gen-csr
Function: Generate a certificate request (CSR)
Subscriber-provided parameters: None
SHECA returns: Certificate request (CSR) and private key.

Based on other information from the MDSP discussion that was not included in this incident report, we have a few questions.

In the MDSP thread, SHECA made the following statement on October 3, 2025, regarding the system that provides the online key generation: “This method generates CSRs by calling a back-end service interface. The back-end service is independent of SHECA's WebTrut systems (CA system, RA system, Validation system,etc.) and provides an access entry through a separate domain name. This system is not within the scope of the audit.”

On October 8, 2025, SHECA then stated: “SHECA acknowledges that the aforementioned two interfaces do violate the following rules in BR 6.1.1.3”

(Q1): Given that these APIs were used to generate private keys for TLS certificates subject to the TLS BRs, why did SHECA’s audit scoping process fail to include it?

SHECA's compliance department used the inventory of maintenance systems for its annual audit but failed to identify these open APIs related to the certificate lifecycle.

(Q2): What changes are being made to ensure all applicable SHECA systems involved in the certificate lifecycle, regardless of their domain name or perceived independence, are included in future 3rd-party audits?

To ensure all applicable SHECA system involved in the certificate lifecycle are included in audits, SHECA will maintain a system list, organized by certificate lifecycle to ensure the identification of all relevant systems, components, and other related items, and require confirmation from all key stakeholders. Periodic review will be performed to ensure latest system environment is reflected in the system list.

(Q3): In the MDSP discussion, a community member identified an online certificate format conversion tool (hosted on yuque.com) that instructed users to upload their private keys. This tool and its associated risks were not mentioned in this incident report. Can you confirm SHECAs stance on - and status of - this tool?

As mentioned in its previous response, the certificate conversion functions implemented on the interface are all realized via JavaScript, and the relevant implementation codes have been provided for further review (address：https://github.com/SHECA-Alvin/js_cert-tools). Since the community has not yet fully confirmed whether this technical implementation complies with regulatory requirements, the relevant functions have been taken offline by SHECA.

(Q4): In MDSP, SHECA stated that partners "signed corresponding subscriber agreements to obtain user authorization." However, a community member who purchased a certificate stated, "There was not any Subscriber Agreement during the ordering process." Please resolve this perceived contradiction. Was a subscriber agreement, which properly informs subscribers of their key protection responsibilities, presented to and agreed upon by every subscriber whose certificate was issued via these problematic APIs? Can you please describe how?

SHECA investigated the application interfaces of Xinnet and Mobile Cloud and found that the "SSL Certificate Service Usage Statement" (as shown in Appendix 3) must be checked when initiating a procurement application, but the agreement does not contain any clauses regarding subscriber authorization keys.

(Q5): It was also alleged in the MDSP discussion that the /open-api/v2/tools/gen-csr interface encrypted newly generated private keys with a default weak password of "123456" if a stronger password was not provided. Can you confirm if this was the case?

Yes, SHECA has revoked all valid certificates related to this interface application and has deactivated the interface.

Additional questions

(Q6): Can you please directly confirm the following actions have taken place?

  1. SHECA has searched its full corpus (considering all its hierarchies) for any certificate containing a public key that corresponds to a private key generated by the tooling resulting in this incident.

SHECA has re-examined its pre-certificate database and formal certificate database and confirmed that there is no valid certificate in SHECA's PKI system corresponding to the public key involved in this case.

  1. SHECA has added all of these keys to a blocklist, which will be considered by any of SHECA’s BR-compliant hierarchies going forward, regardless of whether that hierarchy was responsible for issuing a certificate corresponding to this incident.

It is confirmed. SHECA has written the SHA-1 values of all public keys corresponding to the certificates involved in this case into the blocklist database. When users apply for SHECA certificates in the future, the system will automatically verify whether the SHA-1 value corresponding to the relevant public key in the CSR is included in the blacklist database. However, the public key information of certificates that expired prior to this incident has not yet been added to the blocklist database. The progress will be updated in subsequent responses.

(Q7): Your Root Cause Analysis identifies an "Inadequate Pre-launch Compliance Review Mechanism for API Products" as a contributing factor and also the root cause of the incident. The CCADB IRGs require the RCA to explain why a failure was possible, not just what failed. Please expand on this root cause. What specific systemic failures in SHECA (e.g., lack of compliance team authority, insufficient training for developers, absence of a formal security sign-off process for new APIs, etc.) allowed a non-compliant API to be designed, built, and launched without being detected?

SHECA’s programme development process follows a standard approval mechanism, specifically covering pre-launch requirements review, code review, standardized testing, and function launch approval. However, the processes fail to include the compliance team in the pre-launch approval. Currently, SHECA has revised the relevant internal processes, with detailed specifications to be elaborated in Question 8.

(Q8): Your proposed Action Items include optimizing the pre-launch compliance review and establishing a quarterly internal audit. To ensure these actions are effective and not just procedural, please provide more detail:

  1. Will the pre-launch review now include a mandatory, formal sign-off from a dedicated compliance team or officer who has the authority to block the launch of any new product or API?
  2. What is the specific, documented scope of the new quarterly audit for certificate service APIs, and should its findings be made available to your Qualified Auditors for review during the annual audit?

The following is SHECA's revised product release process for all systems applicable to the WebTrust framework, including CA, RA, and order systems:
1.Requirements Review Phase:
The compliance team must participate in requirements reviews to confirm and verify potential non-compliant functions in the requirements, with veto power. Any requirements that violate BR or CPS regulations will be directly rejected.

2.Testing Phase:
The compliance team will develop a checklist based on BR and CPS regulations. Testers are explicitly required to verify that all functions (including abnormal functions caused by bugs) comply with this compliance baseline during testing.

3.Function Launch Phase:
The compliance team and the product manager of the corresponding system will jointly conduct function acceptance to ensure that the launched functions fully align with the finally confirmed requirements without deviations or violations.After the compliance team signed off, the requirement was successfully implemented.

4.Strengthen API Auditing
SHECA will explicitly require that all interfaces of systems included in the WebTrust audit system that are invoked by third parties must provide complete and accurate documentation; the documentation must include the basic functions of the interface, request parameters and response parameters, and must include historical version records as audit evidence; updates to the API documentation must be provided to the compliance team for review, and these API documents must be included in the annual audit scope of WebTrust.

(Q9): This incident was not caused by a software flaw but by a feature that was intentionally designed and deployed. This suggests a systemic gap in understanding the TLS BRs within SHECA product development and engineering teams. What specific, preventative process changes will be implemented for the product and engineering teams responsible for these APIs to ensure that non-compliant features are never designed or approved in the future?

1.Comprehensive Launch Process:
SHECA has formulated a more comprehensive product development and launch process. As detailed in Question 8, the high-level participation of compliance personnel can greatly reduce the occurrence of such incidents.

2.Effective Training:
SHECA will conduct regular BR-related training for product and R&D teams of all systems included in the WebTrust audit framework. Additionally, an assessment will be held quarterly. Personnel who fail the assessment must retake it until they pass.

Comment: The appendices of affected certificates is not in the CCADB IRG described format. Additionally, many of these final certificates are not disclosed to CT. The absence of posting the precert hash makes it difficult for community members to study these certificates (like this one: https://crt.sh/?q=1F489306F21A5BCC6B1201AE3A9909AF5300F5828347EA1D0F0983318B15ED5C, which corresponds to https://github.com/SHECA-Alvin/CASE/blob/main/ecloud-cert.md?plain=1#L5.)

SHECA has updated the serial number links in crt.sh to point to the "Precertificate SHA-256 hash" for easier certificate lookup by the community:

https://crt.sh/?serial=3ECF582E074E0A5DCF665C6E09A65594 which corresponds tohttps://github.com/SHECA-Alvin/CASE/blob/main/ecloud-cert.md?plain=1#L4

Comment:SHECA is communicating with the external auditor to arrange a supplementary audit on the rectification of this incident. The purpose is to ensure that all systems (including external APIs and external sales systems) related to the certificate lifecycle management are audited, and that all listed action items are implemented.

Flags: needinfo?(wangjiatai)
Attached image Appendix 1.png —
Attached file Appendix 2.docx —
Attached image Appendix 3.jpg —

(In reply to mpalmer from comment #4)

SHECA will revoke all involved certificates within five days in accordance with BR's requirements.

The private keys involved in this incident were accessible to an unauthorised person (SHECA, which is explicitly not authorized to create private keys for subscriber certificates, per BR 6.1.1.3), which is the definition of a key compromise given in the BRs. Further, the private keys were "communicated to [...] an organization not affiliated with the subscriber" (SHECA), and thus must be revoked under 6.1.2. (which does not specify a time requirement, but it is a reasonable inference that this is also classified as a key compromise). Certificates for which the private key has been compromised must be revoked within 24 hours, per BR 4.9.1.1 point 3.

Inadequate Pre-launch Compliance Review Mechanism for API Products [...] This factor is the root cause of the incident.

No, it is not. What caused the compliance review of this API to be inadequate? Something down that rabbit hole is the actual root cause. Mistakes are never root causes, there are always systemic issues that need to be identified and rectified before anyone can be confident that this problem will not recur again.

SHECA will provide a further explanation of the root cause in its response to Chrome Comment 8, and your questions will be addressed in Q7 and Q8. Thank you.

(In reply to SHECA from comment #9)

Comment:SHECA is communicating with the external auditor to arrange a supplementary audit on the rectification of this incident. The purpose is to ensure that all systems (including external APIs and external sales systems) related to the certificate lifecycle management are audited, and that all listed action items are implemented.

CitadelCore Cyber Security Team here appreciates SHECA's decision to include the appointment of an auditing firm in its action items. This step will significantly enhance public trust and reinforce the perceived neutrality of SHECA's future comments.

To earlier and further confidence, we suggest disclosing more details about the external auditor at your earliest convenience. Specifically, information regarding the audit scope and the auditor's professionalism(or qualifications) in webPKI would be beneficial.

Based on feedback from the community, SHECA has made some adjustments to Action Item.

Action item update

Action Item Kind Root Cause(s) Evaluation Criteria Due Date Status
Improve the internal process of development management (covering four stages: requirement review, development implementation, test verification, and launch), require the approval from the compliance team in these stages of work to ensure that the development meets the requirements of BR. Prevent Factor #1 The adjustments of the internal processes are completed. 2025-10-31 Completed
Strengthen the management of OpenAPI documents: All internal OpenAPIs shall provide complete and accurate documents, which shall include basic function requests, request parameters, response parameters, and must be accompanied by historical version records as the basis for audit tracing. Any release and update of OpenAPI documents must be submitted to the compliance team for review and approval before they can be officially released. Prevent Factor #1 The requirements are communicated and implemented. All OpenAPI documents are organized and managed. 2025-11-30 Ongoing
Sort out the a system checklist within the WebTrust framework to ensure that all systems, APIs and auxiliary tools involved in certificate lifecycle management are included in the audit scope. Prevent Factor #2 The system checklist is completed, and confirmed by the third-party auditor. 2025-11-30 Ongoing
Formulate a more comprehensive special training plan for product managers and developers. The training plan needs to clarify the training content, implementation process and rigid assessment mechanism. Mitigate Factor #2 The training plan is established and implemented. 2025-11-30 Ongoing
Optimize the pre-launch compliance review for products and services involving certificate services. Prevent Factor #1 The quarterly internal audit work plan is formulated and released. 2025-10-31 Canceled （A new action item has been added that can override this action item.）
Establish a quarterly internal audit mechanism for certificate service APIs. Prevent Factor #1 The training plan is completed and released. Training is conducted. 2025-11-31 Canceled（A new action item has been added that can override this action item.）
Optimize the JavaScript code for generating CSR and private key. Prevent Factor #1 The code is optimized and released. 2025-10-31 Completed
Strengthen communication and learning with the community to enhance understanding of BR, and consult the community for advice when in doubt. Mitigate Factor #1&Factor #2 The work has been assigned 2025-10-30 Completed

1.SHECA disclosed that the affected ICAs included "UCA Global G2 Root - Xinnet DV SSL" and "UCA Global G2 Root - Xinnet OV SSL." China Mobile Cloud also used the bug-affected API interface but did not provide specific details regarding the impact on each ICAs.Comment 8Comment 10

Questions resulting from the MDSP Discussion
Reviewing the full incident report in comment 3 and comparing it with the discussion in MDSP, we would like SHECA to provide confirmation of the following points directly in this report:

Please confirm that a full investigation of all ICAs under the UCA Global G2 Root and UCA Extended Validation Root has been completed. A community member in MDSP noted that over 15 ICAs could be affected, but the incident report focuses only on UCA Global G2 Root - Xinnet DV SSL and UCA Global G2 Root - Xinnet OV SSL. We need confirmation that the investigation concluded that no other ICAs utilized the problematic APIs.

Reviewing the certificates revoked by Sheca, I noted that some were issued by "UCA Global G2 Root - KeepTrust OV TLS RSA CA G2." This seems inconsistent with the scope of impact previously outlined by SHECA.
Rather than relying solely on subjective statements that cannot be independently verified by the community—especially given the significant time invested by its members—SHECA should provide direct and verifiable evidence for both affected and unaffected certificates it has issued.
Also, about that list in Comment 10—it's just a screenshot of an Excel sheet. There's no real way for me to tell if it's legit or not.

2.According to SHECA’s response, the organization has revoked that were reportedly affected. However, my review of the crl （https://github.com/SHECA-Alvin/CASE/blob/main/ecloud-cert.md） has revealed several discrepancies.
China Mobile Cloud — which SHECA confirmed used the flawed API — continues to have multiple TLS certificates issued by SHECA for its commonly used domains (such as 10086.cn and cmecloud.cn) that have not been revoked.
https://crt.sh/?id=21361294838
https://crt.sh/?id=21240977462
https://crt.sh/?id=15517385159
https://crt.sh/?id=18903806657

3.Selective Revocation
My review of several already-revoked certificates for cmecloud.cn domains indicates that SHECA only executed revocations without issuing replacement certificates for the affected domains.
https://crt.sh/?id=20331179473
https://crt.sh/?id=19872504407
https://crt.sh/?id=15041156808
Based on the second point, could it be that SHECA selectively revoked certificates for sites with no real business operations simply to appease community concerns?
A timeline analysis suggests these revocations were only carried out after questions were raised by the chrome-root-program.
Meanwhile, sites matching SHECA's stated rationale for delayed revocation—such as those supporting critical infrastructure or other essential services—never actually materialized in their revocation plan.

This situation raises several critical questions that require direct clarification from the SHECA.

  1. Has the currently disclosed scope of affected certificates been subjected to a rigorous investigation across all ICAs,and has SHECA been fully transparent in providing the community with all necessary information?
  2. A significant number of certificates for the domain cmecloud.cn—issued by both the "KeepTrust OV TLS RSA CA G2" and "SHECA OV Server CA G5" intermediate CAs—are absent from the revocation list. SHECA must provide a reasonable explanation for these omissions and furnish a clear, verifiable chain of evidence.
  3. For the list of certificates acknowledged as having delayed revocations, SHECA must supplement each entry with its specific justification. For guidance on handling such disclosures appropriately, SHECA would do well to reference the Chunghwa Telecom case
  4. Based on the information released to date, can SHECA rule out the possibility that information has been intentionally concealed?

Members seem to have run out of patience.

Phoenix Nguyễn,

I am a security researcher from China, with no employment or business relation to SHECA. While I lack a compelling resume, I believe your comments evoked a sense of unease, a feeling stemming from accusations of malicious discrimination against Chinese companies.

I could have simply ignored your comment, but a few minutes of research were enough to deduce the complete flaws in some of your arguments, so I couldn't bear to leave in peace.

Please forgive my somewhat impolite manners.

3.Selective Revocation
My review of several already-revoked certificates for cmecloud.cn domains indicates that SHECA only executed revocations without issuing replacement certificates for the affected domains.
https://crt.sh/?id=20331179473
https://crt.sh/?id=19872504407
https://crt.sh/?id=15041156808
Based on the second point, could it be that SHECA selectively revoked certificates for sites with no real business operations simply to appease community concerns?

From my investegation,
https://crt.sh/?id=20331179473 - http://www.xn--100891-0s7ra866aurj.cmecloud.cn/ (ERR_NAME_NOT_RESOLVED)
https://crt.sh/?id=19872504407 - http://www.xn--10087-dq8os8v.cmecloud.cn/ (ERR_NAME_NOT_RESOLVED)
https://crt.sh/?id=15041156808 - *.100837.cmecloud.cn (Because it is a wildcard certificate i don't konw what exactlly FQDN domain the subscriber deployed, But i tried lookup in google and nothing found: https://www.google.com/search?q=100837.cmecloud.cn)
I thnk the certs were retired no longer to use, and no necessary to replace.

You could have taken a few minutes to avoid such a subjectively flawed accusation without meaningful evidence, and I am somewhat disappointed by the irresponsibility of your remarks.

(In reply to Phoenix Nguyễn from comment #16)

1.SHECA disclosed that the affected ICAs included "UCA Global G2 Root - Xinnet DV SSL" and "UCA Global G2 Root - Xinnet OV SSL." China Mobile Cloud also used the bug-affected API interface but did not provide specific details regarding the impact on each ICAs.Comment 8Comment 10

Questions resulting from the MDSP Discussion
Reviewing the full incident report in comment 3 and comparing it with the discussion in MDSP, we would like SHECA to provide confirmation of the following points directly in this report:

Please confirm that a full investigation of all ICAs under the UCA Global G2 Root and UCA Extended Validation Root has been completed. A community member in MDSP noted that over 15 ICAs could be affected, but the incident report focuses only on UCA Global G2 Root - Xinnet DV SSL and UCA Global G2 Root - Xinnet OV SSL. We need confirmation that the investigation concluded that no other ICAs utilized the problematic APIs.

Reviewing the certificates revoked by Sheca, I noted that some were issued by "UCA Global G2 Root - KeepTrust OV TLS RSA CA G2." This seems inconsistent with the scope of impact previously outlined by SHECA.
Rather than relying solely on subjective statements that cannot be independently verified by the community—especially given the significant time invested by its members—SHECA should provide direct and verifiable evidence for both affected and unaffected certificates it has issued.
Also, about that list in Comment 10—it's just a screenshot of an Excel sheet. There's no real way for me to tell if it's legit or not.

2.According to SHECA’s response, the organization has revoked that were reportedly affected. However, my review of the crl （https://github.com/SHECA-Alvin/CASE/blob/main/ecloud-cert.md） has revealed several discrepancies.
China Mobile Cloud — which SHECA confirmed used the flawed API — continues to have multiple TLS certificates issued by SHECA for its commonly used domains (such as 10086.cn and cmecloud.cn) that have not been revoked.
https://crt.sh/?id=21361294838
https://crt.sh/?id=21240977462
https://crt.sh/?id=15517385159
https://crt.sh/?id=18903806657

3.Selective Revocation
My review of several already-revoked certificates for cmecloud.cn domains indicates that SHECA only executed revocations without issuing replacement certificates for the affected domains.
https://crt.sh/?id=20331179473
https://crt.sh/?id=19872504407
https://crt.sh/?id=15041156808
Based on the second point, could it be that SHECA selectively revoked certificates for sites with no real business operations simply to appease community concerns?
A timeline analysis suggests these revocations were only carried out after questions were raised by the chrome-root-program.
Meanwhile, sites matching SHECA's stated rationale for delayed revocation—such as those supporting critical infrastructure or other essential services—never actually materialized in their revocation plan.

This situation raises several critical questions that require direct clarification from the SHECA.

  1. Has the currently disclosed scope of affected certificates been subjected to a rigorous investigation across all ICAs,and has SHECA been fully transparent in providing the community with all necessary information?
  2. A significant number of certificates for the domain cmecloud.cn—issued by both the "KeepTrust OV TLS RSA CA G2" and "SHECA OV Server CA G5" intermediate CAs—are absent from the revocation list. SHECA must provide a reasonable explanation for these omissions and furnish a clear, verifiable chain of evidence.
  3. For the list of certificates acknowledged as having delayed revocations, SHECA must supplement each entry with its specific justification. For guidance on handling such disclosures appropriately, SHECA would do well to reference the Chunghwa Telecom case
  4. Based on the information released to date, can SHECA rule out the possibility that information has been intentionally concealed?

Members seem to have run out of patience.

Before proceeding with our response, SHECA would like to provide more background information to help community members better understand the subsequent details.

China Mobile Group is the largest telecommunications operator in China, with hundreds of subsidiaries under its umbrella. "China Mobile Cloud" is merely a business unit of one of its subsidiaries. It is important to note that 10086.cn and cmecloud.cn are managed uniformly by China Mobile Group, all subsidiaries under the group are authorized to use these two primary domains or apply for and use corresponding subdomains derived from them for business operations.

As clearly shown in the CT data, even for certificates under the same domain (e.g., *.10086.cn, *.cmecloud.cn), different companies or departments under China Mobile Group purchase certificates through multiple CAs or agents and use their own certificates respectively. Note: All these certificates are within their validity periods.

*.10086.cn

Domain name crt link Issuer Valid to
*.10086.cn https://crt.sh/?id=21688908177 SHECA 2026-11-13
*.10086.cn https://crt.sh/?id=21220158644 Sectigo 2026-09-18
*.10086.cn https://crt.sh/?id=21097495082 Digicert 2026-09-18
*.10086.cn https://crt.sh/?id=15544918463 Digicert 2025-11-10

*.cmecloud.cn

Domain name crt link Issuer Valid to
*.cmecloud.cn https://crt.sh/?id=17410899880 Globalsign 2025-12-08
*.obs.joint.cmecloud.cn https://crt.sh/?id=22171843141 Globalsign 2026-12-05

SHECA maintains partnerships with multiple subsidiaries of China Mobile Group, all of which use the aforementioned domains to apply for certificates. In the context of this case, the only BU that invoked the non-compliant API (in violation of BR requirements) is the "China Mobile Cloud" department. Consequently, SHECA has revoked all certificates associated with this specific department’s account. Notably, certificates for the same domains issued by SHECA to other subsidiaries or departments of China Mobile Group are unaffected: these certificates were not generated using the non-compliant API and therefore fall outside the revocation scope.

Additionally, SHECA would like to correct some inaccuracies in your description.

Reviewing the certificates revoked by Sheca, I noted that some were issued by "UCA Global G2 Root - KeepTrust OV TLS RSA CA G2." This seems inconsistent with the scope of impact previously outlined by SHECA.

Certificates issued by KeepTrust OV TLS RSA CA G2 were already included in the revocation list published earlier. Furthermore, in SHECA’s subsequent response to Google, Appendix 1.png clearly identifies all Intermediate CAs (ICAs) involved in the revocation for "China Mobile Cloud"—including KeepTrust OV TLS RSA CA G2.

A timeline analysis suggests these revocations were only carried out after questions were raised by the chrome-root-program.

SHECA initiated revocation procedures immediately after confirming these APIs violated BR requirements. All subscriber certificates were fully revoked by 10:00 on October 17, 2025, and pre-certificates that had been omitted from initial statistics due to the bug were revoked by 20:15 on October 24, 2025.

1.Has the currently disclosed scope of affected certificates been subjected to a rigorous investigation across all ICAs,and has SHECA been fully transparent in providing the community with all necessary information?

SHECA has verified that only these two partners were using the APIs in violation of BR requirements. For the involved Intermediate CAs (ICAs), please refer to Appendix 1.png.

2.A significant number of certificates for the domain cmecloud.cn—issued by both the "KeepTrust OV TLS RSA CA G2" and "SHECA OV Server CA G5" intermediate CAs—are absent from the revocation list. SHECA must provide a reasonable explanation for these omissions and furnish a clear, verifiable chain of evidence.

https://crt.sh/?id=21361294838
https://crt.sh/?id=21240977462
https://crt.sh/?id=15517385159
https://crt.sh/?id=18903806657

================

https://crt.sh/?id=20331179473
https://crt.sh/?id=19872504407
https://crt.sh/?id=15041156808

The reason (background information) is mentioned above. SHECA has provided screenshots of the order logs for the certificates you listed (https://github.com/SHECA-Alvin/CASE/blob/main/order_log.md). These screenshots show that the requests originated from different accounts, each belonging to separate companies or departments under China Mobile Group. Given the large number of screenshots, they have been compiled into a single document. To protect personal privacy, the names of operators have been redacted.

3.For the list of certificates acknowledged as having delayed revocations, SHECA must supplement each entry with its specific justification. For guidance on handling such disclosures appropriately, SHECA would do well to reference the Chunghwa Telecom case

SHECA will supplement the relevant details in the next update (within one week).

4.Based on the information released to date, can SHECA rule out the possibility that information has been intentionally concealed?

SHECA has always maintained full transparency throughout the process. We will never conceal the facts from the community for any customer or partner.

If you have any further questions, please feel free to reach out.ons.

Supplementary reply：

The reason why the aforementioned certificates were not reissued is as follows: Among the revocation list published by SHECA, some certificates were applied for during joint functional testing between SHECA and "China Mobile Cloud". The domains used for these certificates are cmecloud.cn and its subdomains. These certificates are not used for actual business operations; some of the applied domains were generated through "Chinese-to-Punycode" conversion, where the Chinese characters typically describe the testing purpose of the application.

The following table listed the three certificates you mentioned, which confirms the testing-purpose nature of these domains.

crt.sh Original Punycode domain name Chinese characters decoded from Punycode English translation of the decoded Chinese characters
https://crt.sh/?id=20331179473 www.xn--100891-0s7ra866aurj.cmecloud.cn 10089订购退订1 10089 Subscription cancel1
https://crt.sh/?id=19872504407 www.xn--10087-dq8os8v.cmecloud.cn 10087订退 10087 cancel
https://crt.sh/?id=15041156808 *.100837.cmecloud.cn / /
  1. SHECA has added all of these keys to a blocklist, which will be considered by any of SHECA’s BR-compliant hierarchies going forward, regardless of whether that hierarchy was responsible for issuing a certificate corresponding to this incident.

It is confirmed. SHECA has written the SHA-1 values of all public keys corresponding to the certificates involved in this case into the blocklist database. When users apply for SHECA certificates in the future, the system will automatically verify whether the SHA-1 value corresponding to the relevant public key in the CSR is included in the blacklist database. However, the public key information of certificates that expired prior to this incident has not yet been added to the blocklist database. The progress will be updated in subsequent responses.

SHECA has added the SHA1 hashes of the public keys of all expired certificates prior to this case to SHECA's blocklist.

Comment:SHECA is communicating with the external auditor to arrange a supplementary audit on the rectification of this incident. The purpose is to ensure that all systems (including external APIs and external sales systems) related to the certificate lifecycle management are audited, and that all listed action items are implemented.

Updated information on audit arrangements

SHECA has consulted with external auditors regarding two recent incidents (Bug 1993357, Bug 1994051) and obtained the following information on potential audit arrangements.

1.Inclusion in the Annual WebTrust Audit
It was noted that these two incidents occurred within the annual WebTrust audit period (April 1, 2025 – March 31, 2026). As such, the annual WebTrust audit team will conduct targeted testing on the incidents—including their background, root causes, and remediation status—during on-site field work. Additionally, the remediation status of the two incidents will be disclosed in the appendix of the WebTrust audit report, which is planned to be issued in May 2026. If browsers have any questions regarding the incidents’ root causes or specific remediation actions, the audit team could provide detailed feedback based on their testing results following the 2025 audit.

2.Potential Supplementary Assessment Specific to the Two Incidents
Following consultation, a non-public assessment report regarding these two incidents could be provided by the external auditor (to be confirmed through procurement). Due to the auditor’s internal risk management policies, the detailed report will only be provided to SHECA management and cannot be disclosed to any third party. Should browsers have any inquiries regarding the remediation of these two incidents during the engagement, the auditor is willing to provide feedback via email based on their testing results. The assessment report is planned to be issued in January 2026.

Action item update

Action Item Kind Root Cause(s) Evaluation Criteria Due Date Status
Improve the internal process of development management (covering four stages: requirement review, development implementation, test verification, and launch), require the approval from the compliance team in these stages of work to ensure that the development meets the requirements of BR. Prevent Factor #1 The adjustments of the internal processes are completed. 2025-10-31 Completed
Strengthen the management of OpenAPI documents: All internal OpenAPIs shall provide complete and accurate documents, which shall include basic function requests, request parameters, response parameters, and must be accompanied by historical version records as the basis for audit tracing. Any release and update of OpenAPI documents must be submitted to the compliance team for review and approval before they can be officially released. Prevent Factor #1 The requirements are communicated and implemented. All OpenAPI documents are organized and managed. 2025-11-30 Ongoing
Sort out the a system checklist within the WebTrust framework to ensure that all systems, APIs and auxiliary tools involved in certificate lifecycle management are included in the audit scope. Prevent Factor #2 The system checklist is completed, and confirmed by the third-party auditor. 2025-11-30 Ongoing
Formulate a more comprehensive special training plan for product managers and developers. The training plan needs to clarify the training content, implementation process and rigid assessment mechanism. Mitigate Factor #2 The training plan is established and implemented. 2025-11-30 Ongoing
Optimize the JavaScript code for generating CSR and private key. Prevent Factor #1 The code is optimized and released. 2025-10-31 Completed
Strengthen communication and learning with the community to enhance understanding of BR, and consult the community for advice when in doubt. Mitigate Factor #1&Factor #2 The work has been assigned 2025-10-30 Completed

Action item update

Action Item Kind Root Cause(s) Evaluation Criteria Due Date Status
Improve the internal process of development management (covering four stages: requirement review, development implementation, test verification, and launch), require the approval from the compliance team in these stages of work to ensure that the development meets the requirements of BR. Prevent Factor #1 The adjustments of the internal processes are completed. 2025-10-31 Completed
Strengthen the management of OpenAPI documents: All internal OpenAPIs shall provide complete and accurate documents, which shall include basic function requests, request parameters, response parameters, and must be accompanied by historical version records as the basis for audit tracing. Any release and update of OpenAPI documents must be submitted to the compliance team for review and approval before they can be officially released. Prevent Factor #1 The requirements are communicated and implemented. All OpenAPI documents are organized and managed. 2025-11-30 Ongoing
Sort out the a system checklist within the WebTrust framework to ensure that all systems, APIs and auxiliary tools involved in certificate lifecycle management are included in the audit scope. Prevent Factor #2 The system checklist is completed, and confirmed by the third-party auditor. 2025-11-30 Ongoing
Formulate a more comprehensive special training plan for product managers and developers. The training plan needs to clarify the training content, implementation process and rigid assessment mechanism. Mitigate Factor #2 The training plan is established and implemented. 2025-11-30 Ongoing
Optimize the JavaScript code for generating CSR and private key. Prevent Factor #1 The code is optimized and released. 2025-10-31 Completed
Strengthen communication and learning with the community to enhance understanding of BR, and consult the community for advice when in doubt. Mitigate Factor #1&Factor #2 The work has been assigned 2025-10-30 Completed

Updated information on the Supplementary Assessment

  1. Schedule of the Supplementary Assessment
  • The audit firm has been identified, with engagement background and demand fully aligned.  Procurement procedures are in progress at both parties, and formal commissioning will be finalized upon completion of internal approvals.
  • Standards based on: Baseline Requirements and WebTrust Guidelines.
  • SHECA is progressively addressing the action items disclosed in Bugzilla, with full completion of all remediations targeted for November 2025. The audit team plans to commence assessment in December 2025 after remediations completed, and issue the report by January 2026.
     
  1. Scope of the assessment
    The assessment will cover:
  • processes and systems related to incidents 1993357 and 1994051
  • all private key generation processes
  • all certificate revocation processes (including mass revocations)
  • mechanisms for verifying compliance with Baseline Requirements

 
3. Availability and form of the assessment

  • A non-public assessment report will be issued by the auditor. Due to the auditor’s internal risk management policies, the detailed report will only be provided to SHECA management and cannot be disclosed to any third party.
  • Should Browsers have any inquiries regarding the remediation of these two incidents during the engagement, the auditor is willing to provide feedbacks via email based on the testing results.
  • A public summary of the key findings related to both incidents and the effectiveness of corrective actions will be provided by SHECA.

Action item update

Action Item Kind Root Cause(s) Evaluation Criteria Due Date Status
Improve the internal process of development management (covering four stages: requirement review, development implementation, test verification, and launch), require the approval from the compliance team in these stages of work to ensure that the development meets the requirements of BR. Prevent Factor #1 The adjustments of the internal processes are completed. 2025-10-31 Completed
Strengthen the management of OpenAPI documents: All internal OpenAPIs shall provide complete and accurate documents, which shall include basic function requests, request parameters, response parameters, and must be accompanied by historical version records as the basis for audit tracing. Any release and update of OpenAPI documents must be submitted to the compliance team for review and approval before they can be officially released. Prevent Factor #1 The requirements are communicated and implemented. All OpenAPI documents are organized and managed. 2025-11-30 Completed
Sort out a system checklist within the WebTrust framework to ensure that all systems, APIs and auxiliary tools involved in certificate lifecycle management are included in the audit scope. Prevent Factor #2 The system checklist is completed, and confirmed by the third-party auditor. 2025-11-30 Ongoing
Formulate a more comprehensive special training plan for product managers and developers. The training plan needs to clarify the training content, implementation process and rigid assessment mechanism. Mitigate Factor #2 The training plan is established and implemented. 2025-11-30 Completed
Optimize the JavaScript code for generating CSR and private key. Prevent Factor #1 The code is optimized and released. 2025-10-31 Completed
Strengthen communication and learning with the community to enhance understanding of BR, and consult the community for advice when in doubt. Mitigate Factor #1&Factor #2 The work has been assigned 2025-10-30 Completed

Action item update

Action Item Kind Root Cause(s) Evaluation Criteria Due Date Status
Improve the internal process of development management (covering four stages: requirement review, development implementation, test verification, and launch), require the approval from the compliance team in these stages of work to ensure that the development meets the requirements of BR. Prevent Factor #1 The adjustments of the internal processes are completed. 2025-10-31 Completed
Strengthen the management of OpenAPI documents: All internal OpenAPIs shall provide complete and accurate documents, which shall include basic function requests, request parameters, response parameters, and must be accompanied by historical version records as the basis for audit tracing. Any release and update of OpenAPI documents must be submitted to the compliance team for review and approval before they can be officially released. Prevent Factor #1 The requirements are communicated and implemented. All OpenAPI documents are organized and managed. 2025-11-30 Completed
Sort out a system checklist within the WebTrust framework to ensure that all systems, APIs and auxiliary tools involved in certificate lifecycle management are included in the audit scope. Prevent Factor #2 The system checklist is completed, and confirmed by the third-party auditor. 2025-11-30 Completed
Formulate a more comprehensive special training plan for product managers and developers. The training plan needs to clarify the training content, implementation process and rigid assessment mechanism. Mitigate Factor #2 The training plan is established and implemented. 2025-11-30 Completed
Optimize the JavaScript code for generating CSR and private key. Prevent Factor #1 The code is optimized and released. 2025-10-31 Completed
Strengthen communication and learning with the community to enhance understanding of BR, and consult the community for advice when in doubt. Mitigate Factor #1&Factor #2 The work has been assigned 2025-10-30 Completed

NOTES:
The listed action items have been completed. The case will remain open to update the progress of key milestones as well as the results/summaries of the supplementary assessment.

Action item update

No action item updates; the third-party supplementary assessment is ongoing.

Action item update

No action item updates; the third-party supplementary assessment is ongoing.

Action item update

No action item updates; the third-party supplementary assessment is ongoing.

The third-party audit team for supplementary assessment is expected to enter the site next week. (For detailed information on the supplementary assessment program, please refer to Comment 23 of this case.)
SHECA requests that the next update time be set to January 31, 2026.

SHECA requests that the next update time be set to January 31, 2026.

Whiteboard: [ca-compliance] [dv-misissuance] [ov-misissuance] → [ca-compliance] [dv-misissuance] [ov-misissuance] Next update 2026-01-31
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: