1443731 - SwissSign: Cert issued with a to long validity period

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Reinhard Dietrich]

we have to inform you that we have issued a ssl-certificate with a to long validity period (https://crt.sh/?id=348592796&opt=zlint,cablint).


We will provide the incident report according to https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report in the near future.

Comment 2

[Reinhard Dietrich]

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

Comment 3

[Wayne Thayer]

Reinhard: Thank you for reporting this problem and posting the incident report here.

Please email the incident report to the mozilla.dev.security.policy forum. We require incident reports to be file both in a bug and on the forum.

If you knew about this code path prior to this incident, why was it not patched so that an employee could not accidentally misissue a certificate?

You detected this incident via post-issuance linting. When will you begin linting all certificates prior to issuance?

Comment 4

[Reinhard Dietrich]

Topic: Please email the incident report to the mozilla.dev.security.policy forum. We require incident reports to be file both in a bug and on the forum.

The incident report we also posted on https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/B9aUg9tlGxY

Comment 5

[Wayne Thayer]

(In reply to Reinhard Dietrich from comment #4)
> Topic: Please email the incident report to the mozilla.dev.security.policy
> forum. We require incident reports to be file both in a bug and on the forum.
> 
> The incident report we also posted on
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/
> B9aUg9tlGxY

Thank you.

Please answer the questions I asked in comment #3.

Comment 6

[Reinhard Dietrich]

Feedback to comment #3:

Question: If you knew about this code path prior to this incident, why was it not patched so that an employee could not accidentally misissue a certificate?

Answer:
Since this feature is rarely used and only available to very few member of the staff, this code path was detected fairly late in the process. To avoid to make an error in a rushed changed we decided to make this change in the next release and to train the staff until then to not use this feature for certificates with a remaining lifetime which exceeds 825 days. In the retrospective, this was a misjudgment.

Question: When will you begin linting all certificates prior to issuance?
Answer:
We will have our internal Pre-Issue linting System in Place by end of June and we plan to start use it in the beginning of July. The goal is to use it for all public trusted SSL Certificates by end of July.

Comment 7

[Reinhard Dietrich]

To whom it may concern

Even if we could not achieved our internal time plan, we are one-step further in implementing our Pre-Issue linting System. We are now in the quality assurance phase and plan to place the Pre-Issue linting System into operation product by product during the next months.

Regards 
Reinhard Dietrich

Comment 8

[Juerg.Eiholzer]

The pre-issuance linting for the SwissSign’s newly produced certificates was established and activated in September 2018. Hence the present item can be resolved.

Although the item has been solved since quite a period of time, there was a lack of notification to Bugzilla. This is especially due to the exchange of responsible persons within the organization (see also Wayne's change of assignee some days ago).