User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Steps to reproduce:
- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
On 26 August 2020, we identified this mis-issued certificate during our routine internal audit.
- A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
August 25, 2020, 16:51:08 (UTC+8) – The certificate was issued;
August 26, 2020, 10:25 (UTC+8) – GDCA identified this mis-issued certificate;
August 26, 2020, 10:47 (UTC+8) – GDCA confirmed the mis-issuance, and decided to revoke the certificate, in the meantime the certificate revocation procedures started;
August 26, 2020, 11:00:10 (UTC+8) – The affected certificate was revoked;
August 26, 2020, 14:00 (UTC+8) – GDCA checked all the currently valid SSL certificates issued by us and found no other certificates with similar issue;
August 26, 2020, 14:20 (UTC+8) – We organized a meeting among the compliance, validation and technical teams, in which we revisited our certificates issuance procedures, discussed the part that involves manual validation. A consensus was reached in the meeting that we will develop a feature in the Certificate Management System to match the values to be included in the organizationName, streetAddress, and SerialNumber fields with the data from a Qualified Government Information Source. This feature allows the validation to be done with the combination of both manual validation and system matching, and we believe it will largely avoid the misjudgment incurred by solely relying on human eye validation. We expect to deploy this feature no later than 4 September 2020.
September 1, 2020, 13:53 (UTC+8) – We notified our WebTrust auditor of the mis-issuance.
- Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
GDCA stopped the issuance of certificates with similar problems immediately after we confirmed the mis-issuance.
- In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
One EV SSL certificate was affected, and it was issued on 25 August 2020.
- In a case involving certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
Please see: https://crt.sh/?id=3287428867
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
To comply with the latest Root Programs requirements with regard to the maximum validity of SSL/TLS certificates, on 24 August 2020, GDCA adjusted the SSL/TLS certificates templates configuration in the issuing system and changed the maximum validity of the SSL/TLS certificates to 397 days, we performed a boundary value test on 25 August 2020 by issuing two SSL certificates (an OV and an EV) for a domain controlled by GDCA itself, with the purpose of making sure no SSL certificates with a validity greater than 397 days can be issued by our system.
Certificate Application Submission
When enrolling the certificate information for the OV certificate, the customer service staff input the correct value (数安时代科技股份有限公司) for the organizationName field, while enrolling the certificate information for the EV certificate, an incorrect value(数安时代科技股份邮箱公司) for the organizationName field was filled in.
Validation and Issuance
In validating the certificate information, the Validation Specialist first completed the validation for the OV certificate, and the Issuance Specialist reexamined the certificate profile and issued the certificate. The validation specialist began to process the EV certificate order shortly after validation for the OV certificate was completed, and due to the organizationName value for the two certificates should be the same, the validation specialist relaxed the vigilance in validation and neglected the mistake, while the Issuance Specialist also failed to catch the mistake and issued the certificate.
Analysis on the Cause of the Mis-issuance
We believe that solely relying on human validation on the certificate information is the cause of the mis-issuance. And it is our opinion that in validating the identity of an organization, only combining human validation with technical assistance can largely avoid validation failures.
- List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
We noticed the industry wide validation issues reported in 2019, particularly with the incorrect value for the stateOrProvinceName field, and we paid close attention to the relevant remediation actions taken by some of our international counterparts. In January 2020, as part of our efforts to optimize our validation procedures, we created a list of acceptable locations, and corresponding states / provinces, jurisdictions using a third party authoritative database for the area we provide certification services, customer service staff can only input the values for the localityName, stateOrProvinceName and countryName fields by using a drop-down feature. We believe this will make sure the values in the localityName, stateOrProvinceName and countryName fields are correct.
Additionally, we plan to develop a feature in the Certificate Management System to match the values to be included in the organizationName, streetAddress, and SerialNumber fields with the data from a Qualified Government Information Source. This feature allows the validation to be done with the combination of both manual validation and system matching, and we believe it will largely avoid the misjudgment incurred by solely relying on human eye validation. We expect to deploy this feature no later than 4 September 2020.