1836443 - GlobalSign: Issuance of test certificate (pre-certificate) for EV SSL/QWAC with no EKU extension

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Christophe Bonjean]

Steps to reproduce:

In preparation of the setup of a new service and issuance of a test certificate, GlobalSign has issued a test EV SSL/QWAC pre-certificate with no EKU extension. We will provide the full incident report latest by Tuesday June 6 2023.

Comment 1

[Christophe Bonjean]

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 received a notification from our post linter on 01/06/2023 at 10:03 UTC via email to our compliance team (all times are in UTC). This email was acknowledged at 10:04 on the same day, and the investigation started on 10:05, confirming that the pre-certificate was mis-issued.

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.

DD/MM/YYYY - Time in UTC	Description
30/05/2023	Begin setup of profile for issuance for new service.
01/06/2023 09:21	Begin procedure for first test issuance from private demo CA.
01/06/2023 09:53	Test certificate issuance occurred from public CA.
01/06/2023 10:03	Post linter reported mis issuance.
01/06/2023 10:05	Investigation started by compliance team.
01/06/2023 10:06	Mis issuance of pre-certificate confirmed.
01/06/2023 10:11	Revocation requested for pre-certificate.
01/06/2023 11:27	Pre-certificate revoked.
01/06/2023 12:03	Setup of public CA finalized (linting and OCSP).
05/06/2023 08:06	Investigation fully completed.

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.

Issuance was immediately stopped for the affected CA upon noticing the error. Certificate issuance to certificate consumers had not been started for the affected public CA.

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.

https://crt.sh/?id=9541940990

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.

See #4.

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

During the setup of a new service, a new profile was added for issuance and a test certificate was planned to be issued from a private demo CA with the objective to review and approve the output of the profile and expected certificate contents, prior to enabling the profile on the public CA.

Due to human error of the operator, the test certificate request was not sent to the private demo CA but to the public CA for which the set up was still in progress.

The test certificate issuance request was reviewed and approved and included the applicable specifications for issuance of a test certificate as requested by the compliance engineer. However, through inquiry with the infrastructure operator processing the request, we understood that ambiguity in the formulation of the request and naming of the profiles lead to a different interpretation from the infrastructure operator and resulted in issuing the certificate from the public CA instead of the private one.

The request was performed with the two pair of eyes principle. In this instance, the second infrastructure operator had the same interpretation of the request as the primary operator and therefore did not flag this as an issue.

Since the public CA configuration was at that point still in progress, zlint was only configured at the profile level but not yet enabled at the CA level, which resulted in the certificate not being blocked during the pre-issuance phase. The post linter was already enabled and reported the issue to the compliance team, who identified the issue and stopped further issuance from the public CA.

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 change request specifications for documenting a test certificate issuance have been reviewed and updated based on feedback from the infrastructure operators to prevent ambiguity for future requests and providing an increased level of detail related to the context of the certificate request, in order to further clarify the expectations of the request to the infrastructure operators. The setup of the public CA has also been completed and linting for the CA is operational.

Comment 2

[Ben Wilson]

Are there any questions or comments from those following this bug? If not, I will close it on Friday, 15-Sept-2023.