This is the final report.
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 2020-01-20, 08:51 UTC one certificate with S/MIME attributes was wrongly issued by the SSL intermediate CA D-TRUST SSL Class 2 CA 1 2009. The customer revoked the certificate shortly after issuance. Due to our internal alerting systems the case came to our attention on 2020-01-20, 08:59 UTC.
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-01-20, 08:30 UTC: Installation and activation of a set of configuration changes for several PKI products of D-TRUST on the production system at the same time
2020-01-20, 08:51 UTC: Issuance of one certificate (https://crt.sh/?id=2347922247) with SMIME attributes by the SSL intermediate CA D-TRUST SSL Class 3 CA 1 2009
2020-01-20, 08:53 UTC: Revocation of the certificate by customer
2020-01-20, 08:59 UTC: Stop of production line and begin of investigation of the error
2020-01-20, 09:36 UTC: Correction of configuration and verification
2020-01-20, 10:21 UTC: Restart of production line
2020-01-22, 10:48 UTC: Informing Conformity Assessment Body about the issue
2020-01-23, 11:30 UTC: End of thorough analysis and release of an action plan
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 stopped the production and corrected the configuration.
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-01-20
Issuing date of last certificate: 2020-01-20
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.
Due to a misconfiguration it was possible to issue non-conformant certificates for a short period. The misconfiguration took place in a larger configuration change of several PKI products (product life cycle) on the production system. The configuration of the SSL production line contained an error which allowed the acceptance of non-conformant data.
After the change, one customer applied for a certificate. After the certificate was received and checked by the customer, the customer recognized that the certificate was wrongly issued and revoked it. At the same time, our post-linting system created a notification, so the PKI surveillance team stopped the production system.
We corrected the configuration and started a thorough analysis to avoid further errors. We discovered that the error was introduced due to human error. One configuration attribute for producing S/MIME certificates was wrongly transferred to the configuration set of SSL certificates. The error was not recognized during several checks because of a huge amount of changed attributes at the same time and a similar naming.
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 corrected the configuration. No further certificates can be produced with a similar error.
Here is our action plan:
- We already carried out additional training of all members of the configuration team.
- As of now, if changes are necessary, we limit the number of affected attributes at the same time to an amount which can be overseen on one screen.
- We are working on a process redesign to improve our extended check routines of configuration changes. We expect this work to be finished within the first half of 2020.