Closed Bug 1793441 Opened 1 year ago Closed 1 year ago

GlobalSign: CRL contains invalid signature algorithm


(CA Program :: CA Certificate Compliance, task)


(Not tracked)



(Reporter: agwa-bugs, Assigned: christophe.bonjean)


(Whiteboard: [ca-compliance] [crl-failure])


(1 file)

545 bytes, application/x-pkcs7-crl
Attached file gsoveccg4r3.crl

GlobalSign has disclosed the following CRL:

for the following CA certificate:

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

I have attached a copy of the CRL.

Assignee: bwilson → christophe.bonjean
Ever confirmed: true
Whiteboard: [ca-compliance]

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.

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, 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 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.

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.

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

Flags: needinfo?(bwilson)
Closed: 1 year ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [crl-failure]
You need to log in before you can comment on or make changes to this bug.