1838371 - CFCA: certificate with an incorrect OrganizationName

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[2018]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36

Steps to reproduce:

CFCA issued an OV SSL certificate to www.hncdi.gov.cn. However, www.hncdi.gov.cn is a government department, not 海南新境界软件有限公司. (a commercial company)
https://crt.sh/?id=8350672286

Comment 1

[Gao Fei]

CFCA follows the requirements of BR to verify the identity of the organization,and verify the ownership or control of the domain name.
Some organizations authorize domains to other organizations, and it is acceptable for CAs to issue certificates after completing the verification required by BR.

Comment 2

[Ben Wilson]

Is Comment #1 a request to close this bug as "Invalid"? If not, a full incident report is required.

Comment 3

[Gao Fei]

We will complete the response to this incident within 1 week.

Comment 4

[Gao Fei]

We are in the process of checking the historical certificate, so it will take about 3 days to respond.

Comment 5

[Gao Fei]

1. When CFCA accepts certificate applications and conducts reviews, it will identify the organization's identity and domain name in accordance with the requirements of CP*CPS.
   During the domain name identification process, after the applicant's domain name verification (DNS Change/Website Change, etc.) passes, we have a prescribed step - to check whether the domain name owner is consistent with the applicant. During this step of inspection, if there is any inconsistency between the domain name owner and the applicant, we will ask the domain name owner to authorize the proxy applicant (in the form of signature, email, etc.).
   According to statistics, among the certificates that are currently valid, we have a total of 21 certificates in this situation (if necessary, we can display them in subsequent replies). The review process of these certificates has been reviewed one by one to meet the above processing process.
2. Regarding certificate issuance cases where the applicant and the domain name owner are inconsistent, other CA institutions also have many such cases (for example, https://crt.sh/?id=9576335149). In the CDN scenario, after some organizations purchase CDN services, they will authorize all CDN management, certificate application, configuration and other tasks and hand them over to the CDN service provider for unified management. When the CDN service provider applies for a certificate, the organization name (O field) will be recorded Service provider name, domain name list contains domain names of multiple different customers.
3. There are additional requirements for cases where the domain name owner is inconsistent with the applicant. We have strict controls in processing such certificate applications to meet the BR standard requirements. At the same time, in order to reduce everyone's different understanding of this situation, we have adjusted the relevant requirements on October 13, 2023, and implemented them in accordance with the new requirements: a. The verification requirements will not be reduced. If the domain name owner is inconsistent with the applicant In this case, we will require the domain name owner to authorize the agent applicant (in the form of signature, email, etc.); b. The name of the domain name owner's organization will be recorded in the certificate.

Based on the recent review of certificates within the validity period that meet the requirements, we hope to close this bug with an "invalid" request.

Comment 6

[Ben Wilson]

When I translate 海南新境界软件有限公司, it says "Hainan New Realm Software Co., Ltd."

WHOIS says the domain registrant is "Hainan Provincial Commission for Discipline Inspection of the Communist Party of China" - 中国共产党海南省纪律检查委员会

The CA is ultimately responsible for the content of a certificate, so even if the CDN provides you with different information, you still need to fix it.

I am going to keep this listed as an OV-misissuance.

There is a new incident report form that you should use to file an incident report - https://www.ccadb.org/cas/incident-report#incident-report-template

Also, please refer to the revocation check errors listed at https://crt.sh/?id=8350672286 - please explain why there are so many errors listed for the CRL checking.

Comment 7

[Rob Stradling]

Also, please refer to the revocation check errors listed at https://crt.sh/?id=8350672286 - please explain why there are so many errors listed for the CRL checking.

The crt.sh crl_monitor's attempts to connect to crl.cfca.com.cn are timing out. Has CFCA blocked the crl_monitor's IP address (91.209.196.18)?

crt.sh's crl_monitor monitors all observed CRL URLs (except for a handful of subordinate CAs that issue both a Full CRL and a large number of Partitioned CRLs, where for performance reasons I've manually configured crt.sh to only monitor the Full CRL). crt.sh has so far observed 295 different CRL URLs in the CT-logged certificates and precertificates issued by the CFCA OV OCA subordinate CA.

It would appear that "CFCA OV OCA" is issuing both a Full CRL and lots of "Partitioned CRLs" that do not comply with MRSP section 6.1.2 because the Issuing Distribution Point CRL extension is absent. (CFCA will need to open a new CA Certificate Compliance bug for this).

Even when a CA issues compliant Partitioned CRLs, each crt.sh certificate page will show all monitoring errors relating to all CRLs issued by the issuing CA. This is because crt.sh does not currently consider the scope of each retrieved CRL.

Comment 8

[Gao Fei]

(In reply to Ben Wilson from comment #6)

When I translate 海南新境界软件有限公司, it says "Hainan New Realm Software Co., Ltd."

WHOIS says the domain registrant is "Hainan Provincial Commission for Discipline Inspection of the Communist Party of China" - 中国共产党海南省纪律检查委员会

The CA is ultimately responsible for the content of a certificate, so even if the CDN provides you with different information, you still need to fix it.

I am going to keep this listed as an OV-misissuance.

There is a new incident report form that you should use to file an incident report - https://www.ccadb.org/cas/incident-report#incident-report-template

Also, please refer to the revocation check errors listed at https://crt.sh/?id=8350672286 - please explain why there are so many errors listed for the CRL checking.

1. The incident report will be provided within this week.
2. Revocation check connection timeout error. It is initially confirmed that crl_monitor has been marked as blacklisted by our network security policy. We will complete the processing as soon as possible and add it to the whitelist.

Comment 9

[Gao Fei]

(In reply to Rob Stradling from comment #7)

Also, please refer to the revocation check errors listed at https://crt.sh/?id=8350672286 - please explain why there are so many errors listed for the CRL checking.

The crt.sh crl_monitor's attempts to connect to crl.cfca.com.cn are timing out. Has CFCA blocked the crl_monitor's IP address (91.209.196.18)?

crt.sh's crl_monitor monitors all observed CRL URLs (except for a handful of subordinate CAs that issue both a Full CRL and a large number of Partitioned CRLs, where for performance reasons I've manually configured crt.sh to only monitor the Full CRL). crt.sh has so far observed 295 different CRL URLs in the CT-logged certificates and precertificates issued by the CFCA OV OCA subordinate CA.

It would appear that "CFCA OV OCA" is issuing both a Full CRL and lots of "Partitioned CRLs" that do not comply with MRSP section 6.1.2 because the Issuing Distribution Point CRL extension is absent. (CFCA will need to open a new CA Certificate Compliance bug for this).

Even when a CA issues compliant Partitioned CRLs, each crt.sh certificate page will show all monitoring errors relating to all CRLs issued by the issuing CA. This is because crt.sh does not currently consider the scope of each retrieved CRL.

1. Revocation check connection timeout error. It is initially confirmed that crl_monitor has been marked as blacklisted by our network security policy. We will complete the processing as soon as possible and add it to the whitelist.
2. According to the requirements of MRSP and BR, CFCA needs to use the complete CRL to populate CRLDistributionPoint. CFCA will complete the analysis of problem causes, lessons learned, etc. as soon as possible, create a new incident bug and submit the report within this week.

Comment 10

[Gao Fei]

Summary
We have received reports that CFCA has issued an OV SSL certificate for www.hncdi.gov.cn. The WHOIS domain name registrant is "Hainan Provincial Commission for Discipline Inspection of the Communist Party of China" - 中国共产党海南省纪律检查委员会. Certificate The name of the organization recorded in is: Hainan New Realm Software Co., Ltd.- 海南新境界软件有限公司.
After discussion and communication, this type of certificate was determined to be an OV-misissuance.

Impact
There are a total of 22 certificates of this type that are still valid, please see the attachment.
We have adjusted the relevant requirements on October 13, 2023, and implemented them in accordance with the new requirements: If the domain name registrant is inconsistent with the applicant, we will require the domain name registrant to authorize the agent applicant (in the form of signature, email, etc.) , at the same time, the domain name registrant's organization name will be recorded in the certificate, consistent with the WHOIS domain name registrant.
These certificates will be revoked at 10:00 on 2023-11-05.

Timeline
All times are UTC.
2023-01-05 07:46 CFCA issued certificate https://crt.sh/?id=8350672286.
2023-06-14 06:33 [e-mail] reported that the certificate authority information in the above certificate is inconsistent with the WHOIS domain name registrant.
2023-06-19 09:00 CFCA responded and explained that the verification had been completed in accordance with the standards and there was no problem with the issuance of the certificate.
2023-09-26 21:35 Ben Wilson asked whether to close the bug as "invalid".
2023-10-02 01:14 CFCA submission response time.
2023-10-10 03:17 CFCA submission response time.
2023-10-16 12:22 CFCA responded in detail to the inconsistency between the certificate authority information and the WHOIS domain name registrant, and applied to close the bug as "invalid".
2023-10-26 17:10 Ben Wilson replied, identifying the certificate as OV-misissuance.
2023-10-31 05:44 CFCA received Ben Wilson’s comments and responded that an incident report will be provided.
2023-10-31 09:00 CFCA inquired about the certificates within the validity period. A total of 22 certificates had certificate authority information that was inconsistent with the WHOIS domain name registrant.
2023-10-31 15:00 After discussion, these certificates will be revoked at 2023-11-05 10:00.
2023-10-31 16:00 CFCA began to contact and notify the user to re-apply for a certificate. The original certificate will be revoked at 2023-11-05 10:00.

Root Cause Analysis
(1) In some scenarios, domain name registrants do not directly manage domain name operations, certificate applications, etc., but entrust their service providers to manage them on their behalf.
(2) The CFCA certificate review department has different understandings of the role of the agent applicant in the registration process. Therefore, after completing all verifications, the agent applicant's information will be recorded in the certificate.

Lessons Learned
1.What went well
(1) CFCA maintained communication and discussions with the audit agency during this year’s WebTrust audit. Before the above certificate was recognized as OV-misissuance, we had adjusted the relevant requirements on October 13, 2023. At the same time, our reviewers are trained to require that the organization information in the certificate must be consistent with the WHOIS domain name registrant.
(2) After receiving Ben Wilson’s opinion that this type of certificate is regarded as OV-misissuance. Relevant CFCA personnel quickly identified all certificates of this type and quickly made a decision: revoke these certificates within the specified time. In addition: We have summoned dozens of people to be responsible for contacting and notifying users, providing one-on-one technical support for user certificate applications, and assisting users in completing certificate replacements. Therefore, we will be able to complete all work within the specified time.
2.What didn't go well
WHOIS cannot query the domain name registrant information of all domain names, so we will communicate with the domain name registrar to find the required information.
3. Where we got lucky
The vast majority of organizations manage domain names, certificates, etc. by themselves, and will initiate certificate applications as their own organization. There will be no inconsistency between the organization information and the WHOIS domain name registrant.

Action Items
Action Item
In the Zlint verification process, multiple domain name registrar data are used to detect whether the domain name matches the organization name.
Kind
Detect
Due Date
2024-04-30

Appendix
Details of affected certificates
See attachments

Comment 11

[Gao Fei]

(In reply to Ben Wilson from comment #6)

When I translate 海南新境界软件有限公司, it says "Hainan New Realm Software Co., Ltd."

WHOIS says the domain registrant is "Hainan Provincial Commission for Discipline Inspection of the Communist Party of China" - 中国共产党海南省纪律检查委员会

The CA is ultimately responsible for the content of a certificate, so even if the CDN provides you with different information, you still need to fix it.

I am going to keep this listed as an OV-misissuance.

There is a new incident report form that you should use to file an incident report - https://www.ccadb.org/cas/incident-report#incident-report-template

Also, please refer to the revocation check errors listed at https://crt.sh/?id=8350672286 - please explain why there are so many errors listed for the CRL checking.

The analysis is that frequent scanning by crl_monitor triggered my security mechanism, resulting in being added to the blacklist. The IP of crl_monitor was added to the whitelist yesterday and returned to normal.

Comment 12

[Gao Fei]

(In reply to Rob Stradling from comment #7)

Also, please refer to the revocation check errors listed at https://crt.sh/?id=8350672286 - please explain why there are so many errors listed for the CRL checking.

The crt.sh crl_monitor's attempts to connect to crl.cfca.com.cn are timing out. Has CFCA blocked the crl_monitor's IP address (91.209.196.18)?

crt.sh's crl_monitor monitors all observed CRL URLs (except for a handful of subordinate CAs that issue both a Full CRL and a large number of Partitioned CRLs, where for performance reasons I've manually configured crt.sh to only monitor the Full CRL). crt.sh has so far observed 295 different CRL URLs in the CT-logged certificates and precertificates issued by the CFCA OV OCA subordinate CA.

It would appear that "CFCA OV OCA" is issuing both a Full CRL and lots of "Partitioned CRLs" that do not comply with MRSP section 6.1.2 because the Issuing Distribution Point CRL extension is absent. (CFCA will need to open a new CA Certificate Compliance bug for this).

Even when a CA issues compliant Partitioned CRLs, each crt.sh certificate page will show all monitoring errors relating to all CRLs issued by the issuing CA. This is because crt.sh does not currently consider the scope of each retrieved CRL.

Bug report has been created.
https://bugzilla.mozilla.org/show_bug.cgi?id=1863122

Comment 13

[Gao Fei]

Attachment: Certificate list.txt

Comment 14

[Gao Fei]

The revocation of these certificates has been completed at 2023-11-05 18:00.

Comment 15

[Gao Fei]

(In reply to Gao Fei from comment #14)

The revocation of these certificates has been completed at 2023-11-05 18:00.

The revocation of these certificates has been completed at 2023-11-05 10:00.（There is an error in filling in the time）

Comment 16

[Ben Wilson]

Are there any additional questions or comments? If not, I'll close this on Wed. 10-Jan-2024.

Comment 17

[amir]

Can you please let us know what you're going to do to ensure that these certificates are revoked a lot more expeditiously in the future?

There was about a five month gap between the original incident being filed, and the certificate being revoked. In most other CAs, a certificate would've expired in that time period.

Comment 18

[Gao Fei]

(In reply to amir from comment #17)

Can you please let us know what you're going to do to ensure that these certificates are revoked a lot more expeditiously in the future?

There was about a five month gap between the original incident being filed, and the certificate being revoked. In most other CAs, a certificate would've expired in that time period.

1. In this incident, we responded promptly from the time we received the problem report. During the discussion, we expressed our views and opinions and cited some cases to communicate the issues reported in the incident.
2. After discussion and receiving Ben’s opinions, we respect Ben and accept his opinions and results. Immediately, in accordance with the specifications and the "wrong certificate" process, we completed the revocation of these certificates within the time required by the specifications.In addition, related processes are improved.
3. CFCA has formulated "Risk Event Handling Specifications", "Certificate Operation Management Specifications", etc., and regularly organizes case sharing and training for relevant business personnel to ensure that problems can be handled correctly and timely.

In addition, we believe that the forum encourages everyone to discuss and communicate. When we encounter special problems, we can reach unified opinions and conclusions through communication, and we will deal with them in a timely manner. Earlier in 2023, before this incident, we also encountered a certificate revocation situation, and we all followed the standard requirements to complete the corresponding work.

Comment 19

[Ben Wilson]

I will close this on or about Friday, 19-Jan-2024, unless additional matters need to be discussed.

Comment 20

[amir]

Thanks for the answers! No further questions on my end.