SwissSign: Cert issued with a to long validity period

[bloedsin...@gmail.com]

to whom it may concern

Last week we have reported a Bug on https://bugzilla.mozilla.org/show_bug.cgi?id=1443731 about a certificate we issued with a to long validity period.

We are now asked to publish the same incident report also on this mozilla.dev.security.policy forum:

Topic 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 the evening of 6th March 2018 our CABLint post-issue test system alerted us to this problem. We also received emails from an external source

Topic 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.

2018-03-06 15:49 UTC The certificate was issued
2018-03-07 06:00 UTC We started an investigation
2018-03-07 07:00 UTC We contacted the customer in order to replace the certificate and revoke the mis-issued one
2018-03-07 12:36 UTC The certificate was revoked


Topic 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 identified the source of the problem as incorrect use of a rarely used reissue option available only to SwissSign support employees. We immediately prohibited any use of this functionality until the option is fixed (ETA 17th March 2018).


Topic 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.

https://crt.sh/?id=348592796&opt=zlint,cablint

Topic 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.

See https://crt.sh/?id=348592796&opt=zlint,cablint

Topic 6: Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The support option in question was not in scope during the initial work to implement ballot 193 - it was planned to be implemented by 17th March 2018. During the interim period support staff were trained to use the functionality with caution and in accordance with the requirements.



Topic 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.

Immediate action: We have prohibited any use of the problematic reissue functionality until it is technically constrained to 825 days for SSL certificates 7th March 2018: The fixes for the reissue functionality have been rolled out to our test environment 17th March 2018: The fixes for the reissue functionality will be rolled out in production