1793441 - GlobalSign: CRL contains invalid signature algorithm

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

Attachment: gsoveccg4r3.crl

GlobalSign has disclosed the following CRL:

http://crl.globalsign.com/ca/gsoveccg4r3.crl

for the following CA certificate:

https://crt.sh/?sha256=65EEC0CC6C970CC1CD73659115DC8D904E6F12E6DC8FD4DDA39D54CB30224780

This CA uses an elliptic curve key. However, the signature algorithm of the CRL is sha256WithRSAEncryption.

I have attached a copy of the CRL.

Comment 1

[Christophe Bonjean]

Thank you for reporting this, GlobalSign acknowledges this issue. We will review the signature algorithm configuration of the affected CRL, start investigation and provide an incident report latest by October 7th 2022.

Comment 2

[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 became aware following the creation of the bug ticket, which was filed at 03/10/2022 13:32 UTC (All times in this report are in UTC) . The ticket created a corresponding ticket in our internal SOC, which escalated to the Compliance team, who started the investigation at 14:05.

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
03/10/2022 - 13:32	Bugzilla ticket and certificate problem reports created. Corresponding GlobalSign internal SOC tickets created. SOC operators escalate to the compliance team.
03/10/2022 - 14:05	Start of investigation by compliance team.
03/10/2022 - 15:12	Acknowledged / confirmed issue.
03/10/2022 - 15:15	Started review of all active CRLs on both platforms.
03/10/2022 - 15:50	Solution specification completed.
03/10/2022 - 16:08	Completed review of all active CRLs.
04/10/2022 - 14:06	Solution design completed by engineering team.
06/10/2022 - 08:54	Change development 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.

There are currently no active non-expired certificates issued from the CA of the affected CRL. We also confirmed that no other active CRLs are affected by this issue.

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.

No certificates were involved.

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.

The logic for determining the CRL signing algorithm OID was based on the signing algorithm of the certificate of the CA signing the CRL. The affected CRL was issued by an ECC Issuing CA, issued from an RSA Root CA. The Issuing CA certificate was signed with SHA256withRSA and as a result the wrong signing algorithm OID was included in the CRL.

The Issuing CA "GlobalSign Organization Validated ECC CA - SHA256 - G4" is an exception, where the typical approach is to issue ECC CAs from ECC Roots and RSA CAs from RSA Roots. This exceptional combination of ECC and RSA keys was not included as part of testing the CRL generation functionality and therefore did not highlight the issue with the logic.

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 CRL signing algorithm logic has been updated to select the signing algorithm OID based on the key of the issuer. Additional tests cases have also been added to cover both ECC and RSA-based hierarchies.

The updated code is expected to be deployed in production latest by 14/10/2022.

For the OCSP responders on the same platform, we confirmed that the signing algorithm logic was not affected. The same analysis has been performed for the CRL and OCSP components on the legacy platform and we concluded the algorithm selection is also in line with the requirements.

Comment 3

[Christophe Bonjean]

The updated CRL logic has been deployed and we confirmed the CRL is generated with the appropriate signing algorithm. This concludes the identified remedial activities, unless there are any further questions we believe this issue can be closed.

Comment 4

[Ben Wilson]

I intend to close this on or about 19-Oct-2022.