Closed Bug 1398258 Opened 7 years ago Closed 7 years ago

Izenpe: Non-BR-Compliant OCSP Responders

Categories

(CA Program :: CA Certificate Compliance, task)

task
Not set
normal

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.
o-garcia: please can you provide the incident report for this incident? Thanks, Gerv
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.
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
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ocsp-failure]
You need to log in before you can comment on or make changes to this bug.