Closed Bug 1554259 Opened 3 years ago Closed 2 years ago

GlobalSign: SPKI lacks explicit NULL parameter,


(NSS :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: douglas.beattie, Assigned: douglas.beattie)


(Whiteboard: [ca-compliance])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36

We were informed via mdsp list that there were 8 GlobalSign unrevoked SSL certificates (of the 415 reported certificates) that do not contain the required null a parameter and thus violate the requirements of

We immediately revoked these certificates and are investigating the cause of this problem and how best to resolve it.

Flags: needinfo?(douglas.beattie)
Ever confirmed: true
Assignee: wthayer → douglas.beattie
Type: defect → task
Whiteboard: [ca-compliance]

As discussed on the mail lists, the missing null parameter requirement an obscure requirement buried deep in a few RFCs, and as such, we didn't know to check for this specific value. We had assumed our backend CA platform, PrimeKey, would take care of this type of issue, but it seems that the parameters are copied from the CSR and included as-is into the certificates. Our other backend platform CA always included the proper null parameter so no changes are needed.

Currently we're monitoring issuance and will be including the zlint check being developed into our preissuance checks once available. This will prevent further issuance of certificates without the null parameter.

We'll update this ticket once this is complete.

Will GlobalSign be contributing to develop the linting check? If the PR goes nowhere, what steps will GlobalSign be taking?

Yes, tadukurow is one of us and he will post a working lint today or early next week. In the event that working out the details of a publicly approved lint is too difficult or time consuming, we'll be making a private one for the short term.


Could you share the URL of the PrimeKey issue for this in its issue tracker? It's nice to have the lint, bit ensuring it is fixed in PrimeKey's software is also important since many users of that software probably won't use such a linter.

Here's the ticket:

It's been fixed and is in EJBCA 7.2.0

Flags: needinfo?(douglas.beattie)

Doug: it appears that this issue has largely been taken care of, but no proper incident report has been filed. Can you please provide one?

Flags: needinfo?(douglas.beattie)

Doug: Any updates?

I'm working on the details now, sorry for the delay.

Here is the incident report:

  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 were alerted about this issue via the MSDP mail list on May 21:

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

2019-05-21 15:30 Received notification of the problematic certificates
Reviewed request and verified the issue in these certificates.
2019-05-22 10:30:00 EST Revoked the certificates
2019-06-16: Released updated zlint with the new null parameter check to block any future attempts

We discussed the issue on the list and with PrimeKey and took a 2 pronged approach to resolving this:

a) Open a ticket with PrimeKey to have the CA updated. Currently it takes the parameters from the CSR and if those were not encoded properly (Encoded public key algorithm identifier MUST have NULL parameters), then the issued certificate will have issues

b) As a second independent check, we will use zlint once updated with the fix.

  1. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

Yes, we have not issued any additional certificates without the NULL since this incident was opened.

  1. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

We issued certificates with this issue between October 8th, 2018 and May 12, 2019. RSA encoded public key algorithm identifier MUST have NULL parameters, and these 8 certificates did not. See this as an example:

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

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

This was a detailed encoding error within the certificates and we had assumed EJBCA addressed low level encoding issues like this.

7)List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

a) We updated our zlint preissuance check on June 16th to block any future requests.

b) The PrimeKey patch was released on June 20th and we're in the process of testing this update and we're planning to do the upgrade next week.

Thanks for the incident report Doug. Please update this bug when the patch is successfully running in production.

The system was patched with the updated version of EJBCA on July 18th.

Flags: needinfo?(douglas.beattie)

It appears that all questions have been answered and remediation is complete.

Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.