1676367 - NetLock: Issuance of >398-day precertificates after 2020-09-01

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Rob Stradling]

These 2 precertificates both have a notBefore date of 28th September 2020 and are valid for 2yrs:
https://crt.sh/?id=3439519295
https://crt.sh/?id=3439519332

In both cases, a Precertificate Signing Certificate was used (https://crt.sh/?id=494950116), which acts on behalf of the issuing CA https://crt.sh/?caid=677.

No CT logs have observed the corresponding certificates yet; and since these precertificates have so far only been logged to 2 Sectigo logs it's very possible that the corresponding certificates have not actually been issued (because, for CT compliance, both Google and Apple require SCTs from more than 1 log operator).

Nevertheless, https://tools.ietf.org/html/rfc6962#section-3.1 says that "misissuance of the Precertificate is considered equal to misissuance of the final certificate", and so we should act as if corresponding certificates have been misissued by https://crt.sh/?caid=677, for which there is a server authentication trust chain to a Mozilla built-in root.

Comment 1

[Varga Viktor]

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 Nov 26th Mr. Ben Wilson – working on our EV validation – sent a big list of possible problems for validation. After Mr. Wilsons question were answered remained 2 problems, which should be reported as incident. These were reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1676440

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.

2020-08-31 – In our DV system the 2 years (730 days) certificates configuration was set to 365 days. Unfortunately there was one certificate request in progress, ( quintessenz.hu )
which kept the 2 year configuration value for the CT certificate in this state.
2020-09-01 – the new rule no more than 398 days validation was lifted.
2020-09-28 16:13-14 - The customer continued its order and tried 2 times to hit the Next button. Each time only the CT certificate was issued.
2020-09-29 - more than 398 days SSL certificates disabled from code in PROD environment.

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.

We are not issuing certificates with these problems anymore.

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.

2 CT certificates

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.

https://crt.sh/?id=3439519295
https://crt.sh/?id=3439519332

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

The test of this combination was missed from the test cases. Because this, it was not identified until its occurrence.

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.

New test cases and also technical controls make impossible the repeat this error:
2020-09-29 - more than 398 days SSL certificates disabled from code in PROD environment.

Comment 2

[Ryan Sleevi]

Can you be more specific about what your test cases are?

It seems like this risk exists such that any pending changes may not be applied if requests are "in progress", and it's important to understand, systemically, what NetLock is doing to prevent this.

Comment 3

[Varga Viktor]

The original test scenario models a new order, so it lacked validation for an ongoing order. The lifetime is set at the beginning of the order, and this may still contain a value greater than 398 when requesting a certificate that was initiated before the rule took effect. As this has not been tested, the prevention of the issuance of a certificate with a lifespan of more than 398 days has not been investigated for CT.

For the sake of future avoidance, it has been re-clarified that a CT certificate is to be considered an SSL certificate, so without question the same blocking code implementation applies to it, and all tests must be performed on it as for a normal certificate. (x509lint, lifespan, etc.)
The system upgrade on 29-09-2020 wired the same checks into the system for a CT certificate as for a standard SSL certificate.

Comment 4

[Ben Wilson]

I believe that this matter can be closed, so I'm going to schedule it for Wed. 7-Apr-2021.