Closed
Bug 1398258
Opened 7 years ago
Closed 7 years ago
Izenpe: Non-BR-Compliant OCSP Responders
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: kathleen.a.wilson, Assigned: o-garcia)
References
Details
(Whiteboard: [ca-compliance] [ocsp-failure])
Problems have been found with OCSP responders for this CA, and reported in the mozilla.dev.security.policy forum here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/o1MX07iWDco/RuM1NK_0AQAJ
As per section 4.9.10 of the BRs, OCSP responders MUST NOT respond with a “good” status for unissued certificates. The effective date for this requirement was 2013-08-01.
Please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
Note that the problem has been fixed as of 2017-09-05, so the purpose of this bug is to record the CA's incident report.
Comment 1•7 years ago
|
||
o-garcia: please can you provide the incident report for this incident?
Thanks,
Gerv
Assignee | ||
Comment 2•7 years ago
|
||
1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
We were aware of this problem in August 29th when it was published in the "mozilla.dev.security.policy" group (https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/o1MX07iWDco/RuM1NK_0AQAJ)
The following day we asked for clarification.
2.- A timeline of the actions your CA took in response.
Next day we checked the OCSP response for every different certificate we issue and found out that problem was only related to the answers for the certificates issued by the ROOT CA.
The reason for this was the way our ocsp works only in this situation. In case of the root CA, OCSP responses were built over the ARL. So if a certificate was not present in the ARL file, it was assumed that it was "good".
The day after the problem was disclosed, we fixed this in our development environment, and after doing some tests, by the end of the day, the problem was fixed in our production environment.
3.- 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.
We have a test suite with some different requests, including alive, revoked and expired certificates. We are going to include some cases for testing the requests to our root CA.
Comment 3•7 years ago
|
||
Given that this was only a problem for the root certificate, which requires manual responder configuration, I think we can resolve this.
Gerv
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•2 years ago
|
Product: NSS → CA Program
Updated•2 years ago
|
Whiteboard: [ca-compliance] → [ca-compliance] [ocsp-failure]
You need to log in
before you can comment on or make changes to this bug.
Description
•