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.
SwissSign took notice of this issue as it was reported in Bugzilla
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.
- 20200430 06:43:54 UTC Issuing of Precert: precert
- 20200504 10:30 - 12:00 CEST Change to OCSP-configuration for leaf certificates (see point 6)
- 20200506 09:18:59 UTC Issuing of corresponding cert: cert
- 20200508 07:30 CEST SwissSign took notice of the this Bugzilla and validated the information
- 20200508 07:45 CEST An investigation is started to explore the reason of the mismatch. Additionally we started to look for similar cases.
- 20200508 11:00 CEST Initial Information of our auditors
- 20200508 12:15 CEST First results showed no additional certs
- 20200508 14:30 CEST Reason for mismatch in precert/cert has been identified (see point 6)
- 20200508 15:30 CEST Update to our auditors
- 20200508 19:00 CEST Publishing of this report
- 20200508 ongoing Searching for 'open' precerts issued before the OCSP-configuration change
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.
- We are not issuing any new mismatching precerts/certificates because the mismatch is connected to a specific action taken on 2020054 (see point 6)
- Our first investigation shows only one Precert/certificate was issued with this mismatch
- We are currently checking for other precerts without corresponding certificates and will update this report next week
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.
Current status of investigation shows no other affected certificates: Total number: 1 precert (20200430), 1 cert (20200506)
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.
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
SwissSign has several DNS-aliases for OCSP responders (such as http://silver-server-g2.ocsp.swisssign.net/<keyID>) which all connect to http://ocsp.swisssign.net/<keyID> . Any DNS-alias would work with any of our certificates. The status information was and still is always available as required.
The change of the OCSP configuration has been triggered by a recommendation of our auditors during the last audit. As we did not find any good value in the current setup we decided to drop the DNS aliases in the leaf certificates. The DNS-aliases themselves stay in place until the last of valid certificate which include a DNS-alias have been either revoked or expired.
The mistake happened as we missed to check for any existing precerts without the corresponding certificate were still queued at the time of the configuration change. We have not recognized this potential risk in advance.
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.
In the future we will check for any precerts without corresponding certificates before any change to fields of the leaf certificates such as the OID. The work instructions are being updated accordingly.