1760311 - GlobalSign: OCSP responder certificates with more than 64 characters in CN

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Comment 1

[Christophe Bonjean]

GlobalSign issued 6 OCSP responder certificates with more than 64 characters in the CommonName field. We are currently investigating and will post a full incident report by March 23 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.

During gap assessment of certificates profiles against proposed upcoming changes to the baseline requirements in sleevi/cabforum-docs on 30/11/2021, it was noted that some OCSP Responder certificates had a CN which was longer than allowed length (64 characters).

The infrastructure team discussed and updated the profiles to use the CA shortname instead of the long version of the CA CN and used the new profile to create OCSP responders on 22/02/2022-23/02/2022.

On 17/03/2022 15:04 UTC (All times in this report are in UTC) two OCSP responder certificates with CN longer than 64 characters were brought to our attention via a certificate problem report.

The report was escalated to the Compliance team, who started the investigation on 17/03/2022 16:11. We confirmed that the reported certificates that were misissued required revocation on 18/03/2022 09:03 and responded to the reporter on 18/03/2022 09:04.

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/11/2021	Noticed OCSP certificates with CN longer than 64 characters during gap assessment
09/12/2021	After discussion on available fields concluded to rename with CA shortname rather than CN for new OCSP Responder certificates
22/02/2022-23/02/2022	Renamed and replaced all OCSP certificates with "{CA shortname} OCSP Responder" rather than "{CA CN} - OCSP Responder"
17/03/2022 - 15:04	Certificate problem report received
17/03/2022 - 16:11	Investigation started
17/03/2022 - 21:00	Started review historically issued certificates
18/03/2022 - 09:03	Evidences reviewed, confirmed certificates in report were no longer in production and required revocation.
18/03/2022 - 09:04	Responded to reporter.
18/03/2022 - 09:14	Completed review of historically issued certificates. 4 additional certificates identified. Started revocation process.
18/03/2022 - 09:59	All affected certificates revoked.
23/03/2022 - 07:40	Added linting to OCSP Responder certificate profiles
23/03/2022 - 14:11	Reviewed linting configuration of all OCSP Responder certificate profiles

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.

We stopped issuing certificates with this problem with the profile change on 23/02/2022.

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.

Certificates:

• https://crt.sh/?id=6371766441
• https://crt.sh/?id=6371832911
• https://crt.sh/?id=6371812116
• https://crt.sh/?id=5904921628
• https://crt.sh/?id=5904078280
• https://crt.sh/?id=5904078290

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.

RFC compliance checks are performed in GCC for regular leaf certificates. The creation of OCSP certificates is however scripted using pre-approved profile, where DN attributes are extracted from the CA which will be signing each Responder certificate and sent to CA for issuance, without being sent through GCC. Due to their specific nature, linting was not enabled on these particular profiles.

The reviewer in this case had not linked the sleevi/cabforum-docs proposal back to RFC 5280 certificate contents constraints and had assumed it only a potential future compliance issue. Therefore it was not raised as an incident until the report highlighted the RFC reference.

As mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1759854 we are working to increase capacity to have a compliance RFC analysis, this will include a review of all historical profiles.

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.

We have changed the configuration of certificate naming for OCSP Responder certificates from using "{CA CN} - OCSP Responder" to "{CA shortname} OCSP Responder" to mitigate the CN length issues.

We also enabled linting for the profiles and reviewed all OCSP profiles to ensure comprehensive linting for all profiles that issue OCSP responder certificates.

On a daily basis, as part of an existing process, automated configuration review is performed. This review will be further extended to highlight any deviations in terms of linting for OCSP profiles by 25/03/2022.

Comment 3

[Christophe Bonjean]

We have concluded the identified remedial activities - unless there are any further questions we believe this issue can be closed.

Comment 4

[Ryan Sleevi]

You can use the “Needs Info” flag (via Request Information From) to indicate you desire feedback. Historically, the assignee remains the CA representative responsible for ensuring the overall Incident Report process is followed.

Comment 5

[Ryan Sleevi]

Similar to the other issue, having a timeline for this gap analysis seems a reasonable part of this remediation effort. The symptom is fixed, but sounds like other systemic risks exist.

For example, it would sound like intermediates and roots may not be longed and reviewed?

Comment 6

[Christophe Bonjean]

Root and intermediate certificates are reviewed and passed through a linter by the compliance team as part of the key ceremony review activities and approval process documented in https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c14.

To ensure systematic linting of WebPKI subscriber and OCSP certificates, we also reviewed the current linter configuration and confirmed coverage of these profiles.

Comment 7

[Christophe Bonjean]

If there are no further questions, we believe this issue can be closed.

Comment 8

[Ben Wilson]

I'll close this on Friday, 6-May-2022, unless there are additional items or questions to discuss.