Open Bug 1569651 Opened 3 months ago Updated 2 months ago

SwissSign: Misissuance of Leaf Certificates because of incorrect postcode

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: timo.schmitt, Assigned: timo.schmitt)

Details

(Whiteboard: [ca-compliance])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Issue description:
Misissuing of two leaf certificates because of incorrect postcode.
For the certificates listed below, the postalCode= contained '1260 Nyon' instead of ‘1260’ only.

This is an incident report for the issue above according to https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_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 25 July 2019 during an internal review as a preparation for a new product we became aware of the issue described above.

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.

Timeline of incident handling
a. July 25, 2019 (09:05 AM): A SwissSign employee detected as part of an internal review a possible issue. He discussed the finding with his colleagues and contacted the internal Information Security group (InfSec)

b. July 25, 2019 (11:30 AM) SwissSign InfSec started the internal incident management process

c. July 25, 2019 (11:35 AM) SwissSign starts the root cause analysis to gather data for this incident report

d. July 04, 2019 (11:50 AM) First certificate (https://crt.sh/?id=1638896764) revocation by customers operator

e. July 26, 2019 (02:35 PM): Second certificate detected in internal review. Request initiated that MPI operator revokes second certificate (https://crt.sh/?id=1639098392)

f. July 29, 2019 (06:15 PM): SwissSign publishes this incident report on Bugzilla and mozilla.dev.security.policy

g. July 30, 2019 (EOD): Second certificate (https://crt.sh/?id=1639098392) revocation

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.

These erroneous certificates were issued on July 04, 2019. We have stopped issuing certificates with the problem by July 25, 2019. No certificates were issued expect these two in the period of the error.
Certificate https://crt.sh/?id=1638896764 has been revoked and https://crt.sh/?id=1639098392 will be revoked until 30.07.2019.

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.

Only 2 certificate are affected. The certificates were issued on July 04, 2019.

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.

Under the SwissSign EV Gold CA 2014 - G22 Issuing CA the following leaf certificates
https://crt.sh/?id=1638896764
https://crt.sh/?id=1639098392

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

The mask in the operator template for this specific managed PKI for one specific operator was set up wrongly and concatenated the fields for postal code and location into the postalcode field of the certificate.
The wrong configuration was based on human error. The mask has been configured by an exception process which we discontinued as of July 25, 2019.

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.

Exception process has been discontinued.

This bug is also linked at mozilla.dev.security.policy.

Type: defect → task
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Timo: thank you for submitting this incident report and for sending it to the mozilla.dev.security.policy list.

The mask in the operator template for this specific managed PKI for one specific operator was set up wrongly and concatenated the fields for postal code and location into the postalcode field of the certificate.
The wrong configuration was based on human error. The mask has been configured by an exception process which we discontinued as of July 25, 2019.

Will you please provide more information on the exception process that led to this issue? How does it differ from the normal configuration process? And what does it mean to discontinue the exception process? How will changes be made in the future?

Assignee: wthayer → timo.schmitt
Flags: needinfo?(timo.schmitt)
Whiteboard: [ca-compliance]

Additionally, can you describe a little bit more about what is meant by "mask in the operator template"? Based on the description, I'm assuming it's something like Postal Code of issued certificate = {some field from request} {some other field from request or the like, but a more thorough description would help.

The reason I ask is to better understand what other configurations or profiles may exist with masks, and what steps have been taken to review all of the other template masks that may exist.

All our managed PKI operators receive a default interface to the respective configured product. The interface template is configured under 4-eyes only and the respective interface deployed automatically for all new instances.

In this case, a dormant interface was reactivated manually; respectively a template was used which is now meant to be used for test instances and not for the productive ones. The check on correctness of the template failed and we deployed a faulty instance into production. The managed PKI operator had at no time within the setup process the chance to detect the error in the interface, because the postal code field was shown as number only.

In order to correct and avoid the same mistake, we have and are planning the following actions:

• Already completed -> our CISO abolished this exception process
• Ongoing -> we are running queries in order to review if any other instances deployed are affected / so far no findings
• As a mid-term measure, we are looking into linting options

Flags: needinfo?(timo.schmitt)

Timo: in order to better understand the underlying cause of this problem, can you explain why the "dormant interface was reactivated manually"?

Please update this bug at least weekly until the final results of the ongoing review are available.

Please update this bug when a decision has been made on linting.

The dormant interface was reactivated manually due to a human error. As the employee has left the company in Q4 2018 our analysis based on computer logs only. As committed in comment 3 we are improving our processes and will provide the updates as requested.

• We completed our review and confirm that no other certificate is affected
• as already mentioned - it was a one-time human error and the exception process has been abolished already since July 26, 2019
• Please close this incident

Timo: Did you make a decision on linting options as your proposed mid-term measure?

Flags: needinfo?(timo.schmitt)

Yes, we decided not to implement an additional linting, since we have taken the relevant measures and do not see a risk anymore.

Flags: needinfo?(timo.schmitt)
You need to log in before you can comment on or make changes to this bug.