SECOM: certificate for .test TLD
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: agwa-bugs, Assigned: h-kamo)
Details
(Whiteboard: [ca-compliance] [ov-misissuance])
On 2018-03-18, SECOM issued and then revoked the following precertificate, which contains a DNS SAN for test20180323.secom.test. .test is a reserved TLD, so it's impossible for SECOM to have validated this SAN. I can't find an incident report for this.
https://crt.sh/?sha256=96E2D63F67EE457636937DD6975A62B711A67269F99F729B8485172ABA594F6A
In addition to the test20180323.secom.test SAN, the cert contains an invalid country code in the subject (UK) and the CN is not present in the SANs.
Comment 1•7 years ago
|
||
Kamo-san: Please provide an incident report, as per https://wiki.mozilla.org/CA/Responding_To_An_Incident
Please explain why an incident report was not filed and what SECOM will do to ensure that incidents are promptly reported in the future.
| Assignee | ||
Comment 2•7 years ago
|
||
Wayne-san,
We are currently preparing an incident report and post it next week.
Thank you for your consideration.
Best regards,
Hisashi Kamo
| Assignee | ||
Comment 3•7 years ago
|
||
Wayne-san,
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 realized this issue by Bugzilla at 10:25 AM on February 02, 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/03/23 Issued one certificate and revoked it.
2019/02/02 Pointed out of this issue by Bugzilla.
2019/02/03 Permanent action (1) was implemented.
- 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.
This certificate has been revoked on the same day immediately after confirming the issuance.
- 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 a certificate including the top level domain name reserved in Subject Alt Name that exists in DNS and C containing a character string that is not listed in the ISO 2-letter country region code.
We realized this issue by Bugzilla.
This certificate has been revoked on the same day immediately after confirming the issuance.
https://crt.sh/?sha256=96E2D63F67EE457636937DD6975A62B711A67269F99F729B8485172ABA594F6A
- 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 system 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.
At that time, we planned to issue a certificate under the following conditions.
The operator unintentionally specified the DNS Name in the Subject Alt Name and C in the Subject DN.
· Being in our domain (.secomtrust.net etc.)
· Check only in our CA's room
· Issue a short expiration date (validity period: one month)
· Revoke promptly after issuing check
· The operators in charge is carried out by two(2)
In the confirmation process at issuance, it was confirmed that the certificate 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.
Permanent action
(1) Enhancement of the review process
New check items were added in the check sheet of the review point, and the measures were taken to prevent for the certificate information issued when we change the CA system.
(2) Enhance operation confirmation during work
New check items were added to the check sheet of the operation, and the measures were taken to prevent for the certificate information issued when we change the CA system.
(3) System enhancement
We will introduce a system for checking the checkpoint of erroneously specifying the DNS Name and Subject DN CA specified in Subject Alt Name and introducing a mechanism to prevent operational mistakes (under execution date planning).
Please explain why an incident report was not filed and what SECOM will do to ensure that incidents are promptly reported in the future.
Because we realized this issue by this Bugzilla, we could not post an incident report at the time of the issuance of the certificate. (March 23, 2018).
From now on, we will not reoccur the same kind of issue by "Permanent action" as mentioned above.
Thank you for your consideration.
Best regards,
Hisashi Kamo
Comment 4•7 years ago
|
||
Kamo-san: thank you for this incident report.
How was domain control validated on this certificate?
| Assignee | ||
Comment 5•7 years ago
|
||
Wayne-san,
How was domain control validated on this certificate?
This certificate was issued during CA system configuration.
We confirmed certificate profile during configuration.
The domain control was performed manually by an operator in charge (manually validated).
Currently, domain control is performed systematically (systematically validated).
Best regards,
Hisashi Kamo
Comment 6•7 years ago
|
||
We will introduce a system for checking the checkpoint of erroneously specifying the DNS Name and Subject DN CA specified in Subject Alt Name and introducing a mechanism to prevent operational mistakes (under execution date planning).
Kamo-san: when do you expect this to be implemented?
| Assignee | ||
Comment 7•7 years ago
|
||
Wayne-san,
We are now planning to implement by the end of March.
Best regards,
Hisashi Kamo
Updated•7 years ago
|
| Assignee | ||
Comment 8•7 years ago
|
||
Wayne-san,
Implementation was done on March 25.
Best regards,
Hisashi Kamo
Updated•7 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Description
•