Here is our incident report.
- 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.
We received an email notice from Mr. Jonathan Rudenberg at 3:16 AM on January 30, 2019.
- 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.
2018/9/10 Issued two certificates.
2018/9/12 Issued four certificates.
2018/10/3 Issued one certificate.
2019/01/30 Received the notice email.
2019/01/30 Revoked seven certificates.
- 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.
These seven certificates have been revoked on the day of the notice.
- 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.
We issued certificates that specified DNS name including an underscore.
We received the email notice from Mr. Jonathan Rudenberg, and the certificates have been revoked on the same day of the notice.
In addition to that, another certificate was found by our inspection on the same day, so that this certificate have been revoked on the same day.
- 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.
Described at #4.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
When setting change of the CA software (CA product) that we conducted in the past, the operator in charge has unintentionally set an incorrect value in the certificate for issuing check of the certificate profile.
In the task of directly changing the configuration of the CA software, we issued these certificates directly from the CA software.
At that time, we planned to issue certificates under the following conditions.
· Being in our domain (.secomtrust.net etc.)
· Check only in our CA's room
· The operators in charge is carried out by two(2)
In the confirmation process at issuance, it was confirmed that these certificates did not include high risk domain.
- List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
(1) Enhancement of the review process
New Check items were added to the check sheet of the review point, and the measures were taken to prevent for the certificate information issued when we conduct the task of directly changing the configuration of the CA software.
(2) Enhance operation confirmation during work
New Check items were added to the check sheet of the operation and measures were taken to prevent for the certificate information issued when we conduct the task of directly changing the configuration of the CA software.
(3) System enhancement
We will introduce a system for checking the checkpoint that the DNS name does not include an underscore and introducing a mechanism to prevent operational mistakes (under execution date planning).
Thank you for your consideration.