1620727 - Microsoft DSRE PKI: OCSP responders found to respond signed by the default CA when passed an invalid issuer in request

Status: RESOLVED DUPLICATE of bug 1605372

(CA Program :: CA Certificate Compliance, task)

Description

[Julio Montano]

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

Steps to reproduce:

Oscar Karlsson (security researcher), informed Microsoft of issue. Microsoft informed GlobalSign (as service provider) of the issue

Actual results:

Our OCSP responder will provide a response signed by the default OCSP responder certificate when an invalid serial number in the request is passed

Expected results:

The system should respond with Unauthorized (unsigned) response.

Comment 1

[Julio Montano]

This bug filing is for encompasses Microsoft PKI services and DSRE PKI at Microsoft.

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.

On December 18th at 9:23 AM PST, the CA team were notified by email forwarded by another internal Microsoft team (initial email was sent by Oscar Karlsson) that the OCSP responder will provide a response signed by the default OCSP responder certificate when an invalid serial number in the request is passed.

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.

• 18 December 2019 at 9:23 AM PST – The CA team were notified by email sent to our team by another internal team (initial email was sent by Oscar Karlsson) that our OCSP responder will provide a response signed by the default EJBCA responder certificate when an invalid serial number in the request is passed. Note that Oscar Karlsson originally reported this via direct email to [e-mail], but it was undeliverable. More information about that email issue can be found in the following BugZilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1604124.

• 18 December 2019 at 9:39 AM PST - The CA began initial investigation.

• 18 December 2019 at 9:56 AM PST - Notified GlobalSign, the OCSP service provider, to check if they were aware of this issues and ask them to investigate this issue to confirm the reported behavior.

• 18 December 2019 at 2:47 PM PST - Based on the initial investigation between Microsoft and GlobalSign, it was determined that when OCSP receives a request for an invalid serial number, it returns an unknown status signed with a default OCSP responder certificate since there is no issuer a status was asked from.

• 19 December 2019 at 10:21 AM PST - Notified BDO (WebTrust auditor)

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1605372 for additional timeline details from GlobalSign.

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.

There were no non-compliant certificates issued. The OCSP fix was implemented for all GlobalSign production OCSP instances on December 20th, 2019. The following Bugzilla was created by DigiCert to track: https://bugzilla.mozilla.org/show_bug.cgi?id=1605372.

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.

There were no non-compliant certificates issued.

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.

There were no non-compliant certificates issued.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1605372.

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.

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1605372.

            Note: Out of an abundance of caution we have decided to file this bug report although our OCSP provider has already filed and closed a bug for this issue, https://bugzilla.mozilla.org/show_bug.cgi?id=1605372.

Comment 2

[Wayne Thayer]

Julio: thank you for filing this and referencing the GlobalSign bug. Normally I would ask that you not resolve CA compliance bugs yourself, but in this case I agree with your reason for doing so.