1554259 - GlobalSign: SPKI lacks explicit NULL parameter,

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[douglas.beattie]

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

Comment 1

[douglas.beattie]

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 https://tools.ietf.org/html/rfc3279#section-2.3.1.

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

Comment 2

[douglas.beattie]

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.

Comment 3

[Ryan Sleevi]

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

Comment 4

[douglas.beattie]

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.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

PrimeKey

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.

Comment 6

[douglas.beattie]

Here's the ticket: https://jira.primekey.se/browse/ECA-8254

It's been fixed and is in EJBCA 7.2.0

Comment 7

[Wayne Thayer]

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?

Comment 8

[Ryan Sleevi]

Doug: Any updates?

Comment 9

[douglas.beattie]

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

Comment 10

[douglas.beattie]

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 mozilla.dev.security.policy, 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:
https://groups.google.com/d/msg/mozilla.dev.security.policy/NFAG2_o3dhY/gQ2UW_ohAwAJ

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.

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.

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

4. 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: https://crt.sh/?id=1257385456&opt=zlint

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

https://crt.sh/?c=ad567be233e98ac621e8b760005f37f1d7e916d73c602391771ab5f23f7af38b
https://crt.sh/?c=b719593d1e625e45f42ab3d1537e0a9c7a33c0a87244e7000db61571bc0fd98b
https://crt.sh/?c=541e29ce0aee8244a43b31e031208e6808a7e412d6c9cda6cd032d528ea0c690
https://crt.sh/?c=6101a94793441c3b85ac653703d62d5c65ca6457662b36ad7abd3ee43d5eec11
https://crt.sh/?c=ca304b895d0d652da1c352dbda577f7c70c5f6741758e17a919a97d063ad56c7
https://crt.sh/?c=91d876790b645196389d3c92a6b480969557192ecdd2bfeaaced6c07948d9d5c
https://crt.sh/?c=96185e2fadc17a5b896338a3fcce3647b3b2f9221c61c9624814c4d37b884dbb
https://crt.sh/?c=9a9ec285f834b421416e5e5ba45727deaf92adf37e76a82cdf6d45d0fba0728c

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

Comment 11

[Wayne Thayer]

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

Comment 12

[douglas.beattie]

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

Comment 13

[Wayne Thayer]

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