SHECA: The stateOrProvinceName and streetAddress of the certificate DN item are issued incorrectly
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: wangjiatai, Assigned: wangjiatai)
Details
(Whiteboard: [ca-compliance] [ov-misissuance])
Incident Report
SHECA's compliance staff found in their daily spot check that the stateOrProvinceName and streetAddress of a certificate DN item were issued incorrectly. It should have been issued as "重庆市" (English translation: Chongqing City) but was mistakenly issued as "重庆币" (English translation: Chongqing Coin). In Chinese, "市"（City） and "币"（Coin） are very similar characters, so the auditors did not find this problem during the audit process.SHECA is checking whether other certificates have similar situations. A detailed case report will be released before July 25, 2025.
Summary
The stateOrProvinceName and streetAddress of the certificate DN item are issued incorrectly
|
||
Updated•22 days ago
|
Full Incident Report
There are some errors in the title description. The stateOrProvinceName and localityName of the certificate are issued incorrectly, and the streetAddress field is not involved.
Summary
-
CA Owner CCADB unique ID:
Shanghai Electronic Certification Authority Co., Ltd.
-
Incident description:
During a routine spot check, SHECA's compliance team identified an error in the issuance of a certificate's DN fields: the stateOrProvinceName and localityName were incorrectly issued. Instead of "重庆市" (Chongqing City), they were mistakenly issued as "重庆币" (Chongqing Coin). Since the Chinese characters "市" (City) and "币" (Coin) are visually similar, The certificate auditors did not find this problem during the initial review and re-review.
This data was submitted to the system by users of downstream agents through the API. However, the audit system lacked verification of the basic information in the certificate DN item, and manual audit errors occurred, resulting in the issuance of certificates containing incorrect stateOrProvinceName and localityName fields.
-
Timeline summary:
- Non-compliance start date: Unable to evaluate
- Non-compliance identified date: 2025-07-21
- Non-compliance end date: 2025-07-21
-
Relevant policies:
Section 3.2.2.1 of BR
3.2.2.1 Identity
If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant's address of existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:
- A government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition;
- A third party database that is periodically updated and considered a Reliable Data Source;
- A site visit by the CA or a third party who is acting as an agent for the CA; or
- An Attestation Letter.
The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant's identity and address.
Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.
-
Source of incident disclosure:
Found during the compliance internal audit
-
Impact
- Total number of certificates: 1
- Total number of "remaining valid" certificates: 0
- Affected certificate types: TLS Certificates
- Incident heuristic: SHECA scanned all valid certificates and found that only this certificate had this problem.
- Was issuance stopped in response to this incident? Yes, issuance was stopped.
- Analysis: Not applicable.
- Additional considerations: Not applicable.
Timeline
All timestamps are Beijing time (UTC+8)
- 2025-07-17 21:28: The client requested SHECA to issue a certificate through a downstream agent and used the Wubi input method, mistakenly entering "Chongqing City" as "Chongqing Coin".
- 2025-07-18 14:11: SHECA reviewed the certificate request per standard procedure.
- 2025-07-18 14:54: Both initial and secondary reviewers missed the “重庆币” (Chongqing Coin) error and issued the certificate.
- 2025-07-18 17:27: The compliance department discovered this issue during its weekly spot checks.
- 2025-07-18 18:09: After quick communication with the customer, the certificate was revoked.
- 2025-07-23 17:30: A full certificate scan script was completed and no certificates with similar issues were found.
Root Cause Analysis
Contributing Factor #1: Lack of system validation for stateOrProvinceName and localityName fields
- Description: The system lacks automatic verification of basic fields of the certificate DN, such as city, province, etc., and manual inspection is prone to errors.
- Timeline: This issue has existed but was not previously identified.
- Detection: An internal review of Compliance identified this issue; future improvements will include automated checks.
- Interaction with other factors: Not applicable.
Contributing Factor #2: Certificate reviewers lack additional review awareness of similar characters
- Description: in manual checking scenarios, reviewers lack awareness of paying attention to spelling errors (for example, mistakenly writing "重庆市" as "重庆币").
- Timeline: This issue has existed but was not previously identified.
- Detection: This problem was identified in the current incident; in manual checking scenarios, reviewer should be trained to pay attention to spelling errors.
- Interaction with other factors: Not applicable.
Lessons Learned
- What went well: The Compliance Department helped us discover this issue quickly during weekly spot checks.
- What didn’t go well: The system lacks automatic verification of basic fields of the certificate DN, such as city, province, etc.
- Where we got lucky: Not applicable.
- Additional: Not applicable.
Action Items
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Add training on checking visually similar characters in the regular audit training sessions. | Mitigate | Root Cause # 2 | Criteria | 2025-07-23 | Complete |
| Add a linter to verify the basic information in the DN field in the existing SHECA linter tool. | Prevent | Root Cause # 1 | Criteria | 2025-08-06 | Ongoing |
Appendix
| Field | Description |
|---|---|
| Precertificate SHA-256 hash | 7A2BC82C620FAC95E8583E383DBCFB5C2E9CEA767286FFF6F0B9D96A823EB53E |
| Certificate SHA-256 hash | 1595C349270E3C847BD71833D51449DE71A635B9C8F68D7125FDA458BAD10FA6 |
| Subject | *.qdcc.cn |
| Issuer | Keymatic Secure Business ECC CA G1 |
| Not before | 2025-07-18 14:54:06 |
| Not after | 2026-08-18 23:59:59 |
| Serial # | 6d7fe86303de70f3ccd7e1931b062f9e |
| dNSNames | *.qdcc.cn,qdcc.cn |
| Is revoked? | “Yes” |
| Revocation date | 2025-07-18 10:09:11 UTC |
| Revocation reason | superseded |
|
||
Comment 2•13 days ago
|
||
Thank you for this report. However, several sections do not comply with the CCADB IRGs and a revised Full Incident Report should be provided.
Summary Section
- CA Owner CCADB unique ID: The IRGs require the use of the CCADB unique ID. Please update the CA Owner CCADB unique ID field to use your six-digit ID number prefixed with an 'A', as required by the guidelines.
- Non-compliance start date: The non-compliance start date appears to be known from the detailed timeline. The detailed timeline indicates the non-compliant certificate request was made on '2025-07-17 21:28'. (Q1) Could you clarify if this date should be considered the start of the non-compliance?
- Relevant policies: The specific version of the relevant policy is missing. Please specify the version of the BRs that is applicable to this incident.
Impact Section
- Affected certificate types: The type of certificate affected is not specific enough. The IRGs request a summary of the CA/Browser Forum policy OIDs (e.g., DV, IV, OV, EV). While the whiteboard tag
[ov-misissuance]was added to indicate this was an OV certificate, please update this field in your revised Full Incident Report accordingly. - Was issuance stopped in response to this incident?: The reason for stopping issuance is not explained. Please provide the reason for stopping issuance and clarify the scope of this action (e.g., was all issuance halted, or only for certain profiles or customers).
Related Incidents Section
- The report is missing the mandatory “Related Incidents” section. Per the IRGs, this section is mandatory and must include a review of related incidents from all CAs over the past two years that share similarities with this one. Please provide this analysis.
Timeline Section
- “2025-07-17 21:28: The client requested SHECA to issue a certificate through a downstream agent and used the Wubi input method, mistakenly entering "Chongqing City" as "Chongqing Coin".” (Q2) Can you elaborate on “downstream agent” and “Wubi input method” to help us better understand this certificate issuance interface?
Root Cause Analysis Section
- Contributing Factor #1: Generally speaking, the RCA section offers little detail. It’s not clear what methodology was used to identify these two contributing factors, but we would encourage a more detailed analysis in the revised report. (Q3) Specific to factor #1, can you elaborate on how this contributing factor avoided detection?
- The interaction between the identified root causes could be explored further. For both contributing factors, the "Interaction with other factors" is listed as 'Not applicable'. However, it seems that a lack of system validation (Factor #1) would directly increase the risk from human error overlooking similar characters (Factor #2). (Q4) Could you please elaborate on why these factors are not considered interactive?
Action Items Section
- Evaluation Criteria: The evaluation criteria for the Action Items are not defined. The IRGs require a description of how the effectiveness of the action will be measured, with a preference for objective and publicly verifiable metrics. Please provide specific criteria.
- We note that training is referenced in multiple past SHECA incident reports as an action item (e.g., [1][2][3][4][5]) and in report 1815527 it’s specifically mentioned that training alone should not be seen as a sufficient mitigation, and rather focus should be made on removing error-prone manual steps from the system entirely. We encourage SHECA now, and in the future, to continue to focus on preventative measures that remove manual steps and focus less on training as a solution.
(In reply to chrome-root-program from comment #2)
Thank you for this report. However, several sections do not comply with the CCADB IRGs and a revised Full Incident Report should be provided.
Summary Section
- CA Owner CCADB unique ID: The IRGs require the use of the CCADB unique ID. Please update the CA Owner CCADB unique ID field to use your six-digit ID number prefixed with an 'A', as required by the guidelines.
- Non-compliance start date: The non-compliance start date appears to be known from the detailed timeline. The detailed timeline indicates the non-compliant certificate request was made on '2025-07-17 21:28'. (Q1) Could you clarify if this date should be considered the start of the non-compliance?
- Relevant policies: The specific version of the relevant policy is missing. Please specify the version of the BRs that is applicable to this incident.
Impact Section
- Affected certificate types: The type of certificate affected is not specific enough. The IRGs request a summary of the CA/Browser Forum policy OIDs (e.g., DV, IV, OV, EV). While the whiteboard tag
[ov-misissuance]was added to indicate this was an OV certificate, please update this field in your revised Full Incident Report accordingly.- Was issuance stopped in response to this incident?: The reason for stopping issuance is not explained. Please provide the reason for stopping issuance and clarify the scope of this action (e.g., was all issuance halted, or only for certain profiles or customers).
Related Incidents Section
- The report is missing the mandatory “Related Incidents” section. Per the IRGs, this section is mandatory and must include a review of related incidents from all CAs over the past two years that share similarities with this one. Please provide this analysis.
Timeline Section
- “2025-07-17 21:28: The client requested SHECA to issue a certificate through a downstream agent and used the Wubi input method, mistakenly entering "Chongqing City" as "Chongqing Coin".” (Q2) Can you elaborate on “downstream agent” and “Wubi input method” to help us better understand this certificate issuance interface?
Root Cause Analysis Section
- Contributing Factor #1: Generally speaking, the RCA section offers little detail. It’s not clear what methodology was used to identify these two contributing factors, but we would encourage a more detailed analysis in the revised report. (Q3) Specific to factor #1, can you elaborate on how this contributing factor avoided detection?
- The interaction between the identified root causes could be explored further. For both contributing factors, the "Interaction with other factors" is listed as 'Not applicable'. However, it seems that a lack of system validation (Factor #1) would directly increase the risk from human error overlooking similar characters (Factor #2). (Q4) Could you please elaborate on why these factors are not considered interactive?
Action Items Section
- Evaluation Criteria: The evaluation criteria for the Action Items are not defined. The IRGs require a description of how the effectiveness of the action will be measured, with a preference for objective and publicly verifiable metrics. Please provide specific criteria.
- We note that training is referenced in multiple past SHECA incident reports as an action item (e.g., [1][2][3][4][5]) and in report 1815527 it’s specifically mentioned that training alone should not be seen as a sufficient mitigation, and rather focus should be made on removing error-prone manual steps from the system entirely. We encourage SHECA now, and in the future, to continue to focus on preventative measures that remove manual steps and focus less on training as a solution.
Thank you very much for your feedback. SHECA will provide a new revised report as soon as possible and answer some of your questions.
Sorry, as it took me a lot of time to look up "Related Incidents", the time for this reply is also relatively long. The following are the point-to-point responses to the questions you replied to and the revised "Full Incident Report".
(Q1) Could you clarify if this date should be considered the start of the non-compliance?
Although the specific non-compliant certificate was issued on July 21, 2025, potential risks due to similar geographic information errors may have existed earlier than that, making it impossible to pinpoint the start time of the overall non-compliant status.
(Q2) Can you elaborate on “downstream agent” and “Wubi input method” to help us better understand this certificate issuance interface?
“downstream agent”：SHECA's SSL certificate reseller
“Wubi input method”:Wubi Input Method: Wubi Input Method is a Chinese character input method used in mainland China. It breaks down Chinese characters into strokes and components and uses five keyboard areas for input based on the shape and order of the strokes. This input method can only input Chinese characters.Wubi input radicals for the character "市" should be: 亠(y), 冂(m), 丨(h), finalized combination "ymh"，But agent typos "tmh",(t is closest key to y key on the keyboard), results "币".
(Q3) Specific to factor #1, can you elaborate on how this contributing factor avoided detection?
SHECA's certificate review system does not support automatic geographic information checking, and such errors are difficult to detect through manual review. Therefore, SHECA did not discover such problems for a long time.
(Q4) Could you please elaborate on why these factors are not considered interactive?
I apologize for my misunderstanding of the description of "Interaction with other factors" in the IBR. As you said, the lack of automated verification greatly increases the risk of errors in the audit. I have adjusted the relevant description.
Clarification on the Overabundance of Training-Related Items in SHECA's Action Items Section
In relation to the current case, since the auditor failed to identify the incorrect entry of "重庆市" (Chongqing Municipality) as "重庆币" (Chongqing Currency) during the review, Such problems have not been found in SHECA's previous operations. SHECA believes that relevant training is needed for certificate auditors, requiring them to pay attention to the accuracy of geographic information during the audit process.
Concurrently, SHECA is upgrading system-level geographical information validation by introducing source data comparisons for geographical fields within certificate Distinguished Names (DN), including stateOrProvinceName and localityName.
In my opinion, a combination of targeted training and automated system checks will more effectively mitigate similar errors.
As for the explanation regarding the excessive number of training-related items in the prior case action plan:
SHECA has automated key processes such as certificate issuance and review. The system can automatically detect operational anomalies at each stage, effectively improving operational efficiency and accuracy. However, some internal operations, such as updating and publishing CPS (Certificate Practice Statements) and synchronizing information with CCADB and System Testing, have not yet been automated and currently rely on manual processing. Due to the inevitable risk of error in manual operations, SHECA is currently focusing on strengthening operator training and improving internal process management to minimize the probability of human error.
To address this, SHECA is initiating relevant R&D initiatives. Moving forward, comparable internal CA operational workflows will be governed by programmed controls, thereby reducing human error and enhancing operational efficiency.
SHECA highly values your input. We will increase investment in automated operations R&D to minimize manual errors through programmatic checks. Thank you once again for your valuable feedback.
Full Incident Report
Summary
-
CA Owner CCADB unique ID:
SHECA（A000261）
-
Incident description:
During a routine spot check, SHECA's compliance team identified an error in the issuance of a certificate's DN fields: the stateOrProvinceName and localityName were incorrectly issued. Instead of "重庆市" (Chongqing City), they were mistakenly issued as "重庆币" (Chongqing Coin). Since the Chinese characters "市" (City) and "币" (Coin) are visually similar, The certificate auditors did not find this problem during the initial review and re-review.
This certificate application was submitted to the system by SHECA's SSL certificate reseller via the API. The audit system does not automatically verify the correctness of the geographic information, and manual review failed to identify this issue, resulting in the issued certificate containing incorrect stateOrProvinceName and localityName information.
-
Timeline summary:
- Non-compliance start date: 2025-07-21
- Non-compliance identified date: 2025-07-21
- Non-compliance end date: 2025-07-21
-
Relevant policies:
Section 3.2.2.1 of CA-Browser-Forum TLS BR 2.1.6
3.2.2.1 Identity
If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant's address of existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:
- A government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition;
- A third party database that is periodically updated and considered a Reliable Data Source;
- A site visit by the CA or a third party who is acting as an agent for the CA; or
- An Attestation Letter.
The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant's identity and address.
Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.
-
Source of incident disclosure:
Self Reported
-
Impact
-
Total number of certificates: 1
-
Total number of "remaining valid" certificates: 0
-
Affected certificate types: OV-TLS (OID:2.23.140.1.2.2)
-
Incident heuristic: SHECA scanned all valid certificates and found that only this certificate had this problem.
-
Was issuance stopped in response to this incident?
SHECA has stopped issuing certificates for its sub-CAs, Keymatic Secure Business ECC CA G1 and Keymatic Secure Business RSA CA G1. SHECA needs to understand why the certificate reseller passed incorrect values to the CA. After determining that the error was caused by subscriber input errors, SHECA has asked the distributor to modify the certificate application interface, replacing input fields with selection fields to prevent such errors from occurring again.After the reseller's application interface was modified, SHECA reopened the reseller's certificate application.
-
Analysis: Not applicable.
-
Additional considerations: Not applicable.
Timeline
All timestamps are Beijing time (UTC+8)
- 2025-07-17 21:28: A client applied for a certificate from SHECA through SHECA's SSL certificate reseller. Using the Wubi input method (Wubi is a Chinese character input method used in mainland China. It breaks down Chinese characters into strokes and components and inputs them using five keyboard areas based on the shape and order of these strokes). The client mistakenly wrote "重庆市" (Chongqing City) as "重庆币" (Chongqing Coin).
- 2025-07-18 14:11: SHECA reviewed the certificate application according to standard procedures.
- 2025-07-18 14:54: Neither the initial reviewer nor the re-reviewer discovered the "重庆币" error, and the certificate was issued.
- 2025-07-18 17:27: The compliance department discovered this issue during weekly spot checks. 2025-07-18 18:09: After quick communication with the customer, the certificate has been revoked.
2025-07-23 17:30: A full certificate scan script has completed and no certificates with similar issues have been found.
Related Incidents
Bug Date Description 1648997 2020-06-28 It is true that the geographic information submitted by subscribers was automatically verified, resulting in incorrect stateOrProvince and localityName information being checked into the certificate. 1715024 2021-06-07 Because the stateOrProvince and localityName fields are not automatically validated, misspelled information is written into the certificate DN item. 1710243 2021-05-08 Due to inaccurate data sources, stateOrProvince and localityName verification failed, and incorrect information was checked into the DN item of the certificate.
Root Cause Analysis
Contributing Factor #1: Lack of automated verification of geographic information
-
Description: The system lacks automatic verification of basic fields of the certificate DN, such as city, province, etc., and manual inspection is prone to errors.
-
Timeline: This issue has existed but was not previously identified.
-
Detection: SHECA compliance personnel conducted spot checks on certificates issued this week and discovered errors during this process. Because SHECA's certificate review system doesn't support automatic geographic information checking, and such errors are difficult to detect through manual review, SHECA was previously unaware of this issue. SHECA will subsequently integrate with ISO 3166-2 data sources to automatically compare submitted geographic information, helping reviewers identify such errors.
-
Interaction with other factors:
The lack of automated verification of basic data will greatly increase the probability of manual review errors.
-
Root Cause Analysis methodology used
SHECA uses "5-Whys" to analyze the above problems:
Why do certificates have errors in the stateOrProvinceName and localityName fields?
Because the errors weren't caught during manual review.
Why did manual review miss the errors?
Because manual review relies on human judgment and is prone to errors due to oversight.
Why is there no mechanism to compensate for the shortcomings of manual review?
Because the system lacks automatic validation for these two fields, preventing errors in advance.
Why does the system still lack this automatic validation feature?
Because automatic validation of these two basic fields wasn't included in the system design or requirements phase, possibly due to insufficient compliance risk assessment of the certificate DN field.
Why wasn't this validation feature considered during the requirements phase?
Because it was believed that manual review was sufficient to check these basic fields, and the limitations of manual review were not foreseen, or there was insufficient reference to similar error cases in the industry.
Lessons Learned
- What went well: The Compliance Department helped us discover this issue quickly during weekly spot checks.
- What didn’t go well: The system lacks automatic verification of basic fields of the certificate DN, such as city, province, etc.
- Where we got lucky: Not applicable.
- Additional: Not applicable.
-
Action Items
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Add checks on geographic information to the audit system, and refer to ISO 3166-2 for data sources. | Prevent | Root Cause # 1 | Submitting incorrect "stateOrProvinceName" and "localityName" to the review system will cause the reviewer to see an error prompt on the review interface. | 2025-08-06 | Ongoing |
Appendix
| Field | Description |
|---|---|
| Precertificate SHA-256 hash | 7A2BC82C620FAC95E8583E383DBCFB5C2E9CEA767286FFF6F0B9D96A823EB53E |
| Certificate SHA-256 hash | 1595C349270E3C847BD71833D51449DE71A635B9C8F68D7125FDA458BAD10FA6 |
| Subject | *.qdcc.cn |
| Issuer | Keymatic Secure Business ECC CA G1 |
| Not before | 2025-07-18 14:54:06 |
| Not after | 2026-08-18 23:59:59 |
| Serial # | 6d7fe86303de70f3ccd7e1931b062f9e |
| dNSNames | *.qdcc.cn,qdcc.cn |
| Is revoked? | “Yes” |
| Revocation date | 2025-07-18 10:09:11 UTC |
| Revocation reason | superseded |
Action Items update
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Add checks on geographic information to the audit system, and refer to ISO 3166-2 for data sources. | Prevent | Root Cause # 1 | Submitting incorrect "stateOrProvinceName" and "localityName" to the review system will cause the reviewer to see an error prompt on the review interface. | 2025-08-06 | Completed |
Description
•