How your CA first became aware of the problem, and the time and date.
2019-05-13 04:55 UTC: We became aware of the problem while performing the daily check of the mozilla.dev-security-policy mailing list.
A timeline of the actions your CA took in response.
2019-05-13 04:55 UTC: We became aware of the problem.
2019-05-13 07:00 UTC: Start of the investigation (first problem related conference call). The analysis revealed that in accordance with BR 22.214.171.124, the certificates must be revoked within 5 days.
2019-05-13 08:25 UTC: Feedback in mozilla.dev-security-policy mailing list: “Thank you for reporting this issue. The certificates will be revoked in accordance with BR 126.96.36.199. We will provide an incident report after the internal investigation is finished.”
2019-05-13 10:20 UTC: The technical analysis revealed that no additional valid certificates were affected.
2019-05-13 11:10 UTC: The affected customers were informed to revoke the erroneous certificates immediately. If the customer does not revoke the certificates, we as the CA will revoke the certificates in accordance to BR 188.8.131.52 on 2019-05-16 13:00 UTC.
2019-05-16 13:15 UTC: The last affected certificate was revoked.
Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
The last affected certificate was issued on May 24, 2017.
A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
5 valid certificates were affected. The first certificate was issued on Nov. 17, 2016, the last on May 24, 2017.
The complete certificate data for the problematic certificates.
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Our RA team works hard to avoid making any mistakes. Each application is reviewed in detail.
As of May 2017, quality measures regarding validation processes took place as part of Incident 1391074. The focus then was on metadata and invalid characters, not on possible erroneous entries due to default settings. Since then, no additional certificates of this error type were issued due to the intensified sensitivity.
Before the quality measures, the application field "stateOrProvinceName" in very few individual instances were not assigned the necessary importance. During this time, the error was subsequently not revealed, because it was not detected by the linter or the internal test tool and was thus not noticeable.
List of steps CA is taking to resolve the situation and ensure it will not be repeated.
The RAs have been trained to ensure better reviewing of the applications. We are diligently at work to prevent mistakes from happening when issuing new certificates.
In order to avoid such problems in the future, we have detailed our specification and increased the entire RA team's awareness in regard to this topic. In this specific case, the existing work instructions have been revised and expanded.
The RA team was now provided with a lookup list of all allowed terms for the field "stateOrProvinceName".
Our blacklist will be extended until July 03, 2019 to block CSRs with invalid default values in the field "stateOrProvinceName". With this release from July 03, 2019 our validation process for OV-certificates will be extended by a 4-eye check of the SubjectDN.