1691704 - SwissSign: Certificate with key length 4098 bit

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Mike Guenther]

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

Steps to reproduce:

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.

We were informed by a third-party that we issued a pre-cert/cert with key length 4098 bits on 20190805.
This key length violates the Mozilla root store policy v.2.6.1 effective July 1, 2018 (https://github.com/mozilla/pkipolicy/blob/2.6/rootstore/policy.md).
As the "SC31: Browser alignment" became effective with BR 1.7.1 on 20200820 the baseline regulation was not violated.

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.

20200205, 02:04 CET SwissSign received a mail by a third party on a general mailbox [e-mail]. Our contact mail for certificates is [e-mail]
20210205 12:00 CET The ticket was handled as a standard request as it was not send to the correct email address
20210208 16:00 CET The ticket was processed and then brought to the attention to the Manager on Call
20210208 16:45 CET We acknowledged the report and the misissuance process is triggered
20210209 08:00 CET First and second analysis confirmed the misissuance
20210209 14:00 CET Submitting this report

3. Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

A similar mis-issuance is not possible anymore as we implemented and tested corresponding technical controls in January 2020.

4. In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.

Only two certificates (Pre/Leaf) are affected by this issue. We did look for other certificates with unexpected key lengths and came up empty.

5. In a case involving certificates, 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

Two certificates (Pre/leaf) are affected by this
Pre: https://crt.sh/?id=1742570391
Leaf: https://crt.sh/?id=1742572121

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

The CSR by the customer had a key length of 4098 bits. The mistake on our side was that we did not detect it when issuing the certificate. As written above this could not happen nowadays as the technical control has been implemented and tested.

7. List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.

The following tasks are executed:

• Revocation of the certificate until Saturday, 13 February 2021; 16:45 CET (within 5 days since of acknowledging the misissuance)

We have no further steps planned as all the necessary technical controls are in place since the beginning of last year.

Comment 1

[Julien Cristau [:jcristau] (back April 22)]

When adding the controls don't you scan your database for existing certs with the issue? If not, why not?

Comment 2

[Mike Guenther]

Hi Julien, usually we do. It just makes sense. I have no explanation why we didn't after implementation of the above technical control.

Comment 3

[Mike Guenther]

The certificates are revoked as of 2021-02-12, 13:25:32 UTC.

Comment 4

[Ben Wilson]

Mike,
Can you briefly explain how the technical control that you implemented in January 2020 prevents future problems? Is it pre-issuance certificate linting? What does it cover?
Thanks, Ben

Comment 5

[Mike Guenther]

Hi Ben
a key with invalid length gets denied in the request handler, analog to other checks of a request. This takes place before linting or issuing of the pre-certificate. This control is true for all certificates of our public roots. The control itself ensures the requirements posted in my initial post under 1.
Let me know if this answers your question.
Cheers Mike

Comment 6

[Ben Wilson]

I'll schedule to close this on Wed. 10-Mar-2021.