Dear Dev.Sec.Policy,
Following you can find our report about the problem reported about the Bug 1462423. 1. 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 2018-05-17 Andrew Ayer reported the problem through the standard email channel: visszavo...@netlock.hu<mailto:visszavo...@netlock.hu> used for revoking certificates. Unfortunately we missed the Mozilla bug ticked reminder at this time. 1. 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. After we got Andrews mail, we immediately stopped the issuance until the investigation. We identified 7 certificates with this problem (which have problematic CT certificates) and communicated with the end user about the problem. It was a configuration error in the production system on these certificates, which was the root cause. 1. 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. Upon receiving Andrew's email, we stopped the issuing certificates until the conclusion of the investigation. After the identification of affected certificates and cause, we made the necessary corrections, double checked, and then restarted the issuing. 4. 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. 7 incorrect CT certificates were issued between 2018-05-10 and 2018-05-17 connected to issuing 7 standard certificates. 1. 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. The problematic CT certificates have the following ids: https://crt.sh/?id=453465677 https://crt.sh/?id=453471736 https://crt.sh/?id=454888650 https://crt.sh/?id=455334246 https://crt.sh/?id=463346340 https://crt.sh/?id=463665252 https://crt.sh/?id=465748957 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. It was a misconfiguration in the production system. A placeholder config entry was left in a specific cert type. We have new test cases and protocol in place to avoid this problem in the future. 7. 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. We already modified the configuration and also added extra validation to block these types of errors. sincerely yours, Viktor Varga Netlock chief architect _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
