Closed Bug 1398255 Opened 2 years ago Closed 2 years ago
Trust: Non-BR-Compliant OCSP Responders
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-08-31, so the purpose of this bug is to record the CA's incident report.
There was a separate discussion about IdenTrust OCSP responders with https URLS, and the incident report for that was provided here: https://groups.google.com/d/msg/mozilla.dev.security.policy/jSHuE-Oc7rY/EnxRbMP7AQAJ
Vishvas: please can you provide the incident report for this incident? Gerv
Gerv: Here is the report for this incident. 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. IdenTrust Response>> IdenTrust was notified via discussion in mozilla.dev.security.policy on August 29, 2017. 2. A timeline of the actions your CA took in response. IdenTrust Response>> The timeline of actions is provided below (All times are U.S. MT timezone). Aug 29, 9:09am – IdenTrust reviewed the reported violation of BR 4.9.10 for DST ACES CA X6. Aug 29, 09:30am – IdenTrust verified that the reported behavior of the OCSP responses for DST ACES CA X6. Aug 29, 10:00am – IdenTrust formulated a plan to remediate the configuration of DST ACES CA X6 and corresponding OCSP Responder software to comply with BR 4.9.10. We started executing the plan immediately. Aug 30, 3:30pm – IdenTrust completed the remediation Aug 30, 4:04pm – IdenTrust notified the completion of remediation. 3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem. IdenTrust Response>> As of August 30, 2017, IdenTrust has stopped sending OCSP responses in violation of BR 4.9.10. 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. IdenTrust Response>> There was a single CA (DST ACES CA X6) whose OCSP responder was not responding in compliance with BR 4.9.10. 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. IdenTrust Response>> The problematic CA certificate: https://crt.sh/?id=136954 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. IdenTrust Response>> The non-compliant AIA OCSP URL was ONLY present in the subordinate CA(IdenTrust ACES CA 1) certificate and only utilized for OCSP validations of said subordinate CA. The OCSP software for validating this CA / URL was based on legacy design that predate BR 4.9.10. This OCSP /URL was inadvertently missed during the OCPS update activity of 2013. OCSP software and relevant URLs for end entity certificate validation (for certificates issued by IdenTrust ACES CA 1) was updated to meet BR 4.9.10 requirements prior to the effective date of BR 4.9.10. 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. IdenTrust Response>> The OCSP software accessible at the AIA OCSP URL in the CA certificate was permanently deprecated. The implemented IdenTrust OCSP software utilizes BR 4.9.10 compliant OCSP responses. Vishvas
Vishvas: thank you for your report. > This OCSP /URL was inadvertently missed during the OCPS update activity of 2013. Have you investigated how that happened? If it is true that this was the only CA served by this legacy and non-compliant OCSP platform for the past four years, have you considered how it is that no-one in that time ever questioned the fact that you still had a production implementation of this legacy software, and asked what it was there for? Gerv
Vishvas: this bug has been waiting for an update from you for 2 months; please provide one. Gerv
Gerv: This PKI experienced a roll over event during that period and the OCSP responder URL that was in violation was only present in the subordinate CA AIA. On the old/legacy PKI, end-entity certificate OCSP validations were serviced on a different OCSP URL, BR compliant URL. The entire PKI which identified this non-compliant BR has since expired with DST Root CA X6 expiration on November 20th. As it was flagged for rollover there was very little activity(as existing users were rolling over to another PKI) and as such the use of non-compliant OCSP platform at the subordinate CA level was not discovered. Vishvas
I'm still not particularly impressed that you don't have good records of what servers and software you are running, but as this PKI is now obsolete there's nothing left to do in this bug. Gerv
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.