1467110 - OCSP responding good for non-issued certs by Consorci AOC root already solved

Status: RESOLVED DUPLICATE of bug 1398246

(CA Program :: CA Certificate Compliance, task)

Description

[Francesc Ferrer]

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

Steps to reproduce:

OCSP responses good for non-issued certs problem reported by Wayne Thayer https://bugzilla.mozilla.org/show_bug.cgi?id=1398246#c24 


Actual results:

OCSP responses good for non-issued certs problem reported by Wayne Thayer https://bugzilla.mozilla.org/show_bug.cgi?id=1398246#c24 


Expected results:

Responses should have been unknown for such certs all the time

Comment 1

[Francesc Ferrer]

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.

Our monitoring system at 1:30 AM 1st of June.

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.

From our point of view this is a severity 3 issue, since the service is available, giving the right answer except when it is asked about a non existing certificate.
Severity 3 definition: Failure of one or several functions of the service without presenting an immediate significant effect on the quality of service, or affecting a very limited number of users and not having a global significance: absence or presentation of misleading data, problems in the design of the pages , etc.
Severity 3 SLA:
•	Time to answer: 8 hours
•	Time to diagnose: 2 working days
•	Time to solve: 2 working days
Our SysOp started to work on it at 6:00 AM CET, 1st of June
It was solved at 8:00 AM CET

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.

It was not a problem of issuance neither a security issue.
Our service is configured so if the OCSP responses become slow or stop due to DB issues, automatically changes to a less demanding system, reading the Certificate Status from the CRL. Despite this means that in the meantime when we solve the problem, at least all customers have the service available.

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 certificates involved

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 certificates involved

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

It was not a mistake but a problem of syncing between the master and slave DB since we have added a redundant SAN.

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 time-line of when your CA expects to accomplish these things.

The addition of the redundant SAN is a measure to add HA even if the hardware fails, but the syncing was an issue already solved and correctly configured.

Comment 2

[Daniel Bodea [:danibodea]]

Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1398246#c24 
I will set this issue's component the same as the origin issue.
Developers shout decide whether this is a good component or not.
Also, my technical knowledge does not cover confirming this issue.