User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36 Edg/87.0.664.57
Steps to reproduce:
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.
We are following up incidents on Bugzilla. Based on the published bugs of Entrust (https://bugzilla.mozilla.org/show_bug.cgi?id=1673119) and DigiCert (https://bugzilla.mozilla.org/show_bug.cgi?id=1675684) we started an internal investigation on 2020-11-24 to see if we had a similar problem. A first quick analysis showed that potentially private keys could be provided via the interface of the application processing system. However, we found no evidence that a customer had provided a private key for a currently valid certificate.
A second analysis revealed that in the past, a private key was provided for a certificate at the end of a CSR. The certificate was revoked shortly after it was issued.
2.) 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.
2020-11-24: Start of investigation, first feedback with the result, that a private key is potentially transmittable during the application process. For no valid certificate, D-TRUST was sent a private key via this vulnerability.
2020-11-25: Planning of bug fix
2020-12-02: Feedback of thorough analysis of all certificate requests, a revoked certificate (https://crt.sh/?id=3028553596) was found for which a private key was submitted
2020-12-14: Successful completion of installation, testing and final approval of the bug fix
3.) 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.
D-TRUST has installed a bug fix to prevent issuing certificates where the private key is provided with the CSR based.
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.
Number of affected certificates: 1
Issuing date of first certificate: 2020-07-02
Issuing date of last certificate: 2020-07-02
5.) 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.
All affected certificates can be found here:
6.) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Within the framework of the certificate application, the applicant could also submit the corresponding private key by copy and paste at the end of the certificate request. The input interface had not recognised the private key input and had not rejected it. The certificate request with the addition of the private key was then saved within the scope of the TSP's documentation obligations.
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.
D-TRUST has installed a bug fix to prevent the submission of private keys with the CSR. Currently only correct CSRs are accepted. If there are additions or the CSR is not correct, it will be rejected and an error message will be generated. The CSR and its private key will not be saved.