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.
The problem was identified during post-issuance linting procedure on 14/01/19 by operator and sent for further verification.
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.
14/01/19 One certificate without OCSP AIA and KeyUsage extension not marked as critical was issued.
14/01/19 We investigation the root cause began.
15/01/19 We identified and removed from system the registration policy that issued the problematic certificate. The problematic policy template was not listed in policies allowed for Certificate Transparency logging but contained Signed Certificate Timestamp extension. The usage of such policy template should be blocked by the CT functionality. We had only one policy in such state.
16/01/19 We described and raised the issue to software vendor with highest priority.
21/01/19 In agreement with the customer we revoked the one problem certificate.
23/01/19 We got response from software vendor with the patch.
25/01/19 The fix was tested and implemented. During the test phase when testing nagative scenarios we have found one more configuration issue. We were able to log intentionally malformed certificate request for server from KIR domain szafir.kir.pl
(with validity period greater than 825 days https://crt.sh/?id=1142862481). The goal of the test was to block this kind of request. The configuration was fixed, retested with possitive result and the test certificate was immediately revoked.
25/01/19 We ran a script over our existing certificate and police database to identify ojects that could be affected by this issue. No additional objects were identified.
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.
On 15/01/19 we removed from system the registration policy that issued the problematic certificate to prevent this problem from re-occurring. We have also fixed and retested with possitive result test scenario configuration.
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.
Impact of one certificate, issued on 14/01/2019 and another one during the test phase issued 25/01/2019.
The complete certificate data for the problematic certificates.
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The policy was previously used for Certificate Transparency logging but some time ago it was removed from the list of approved CT logging policies. The usage of the policy removed from allowed CT logging list but available for operator
should be blocked by the system but it didn't work this way.
- List of steps CA is taking to resolve the situation and ensure it will not be repeated.
We implemented patch from software vendor and did reconfiguration to prevent this kinds of issues to happen again. We have also changed certificate policy management procedure to make sure that teamplates removed from CT functionality are unavailable for operators even if they were to be blocked by system. We have also double checked CT configuration and test scenarios.