This bug has been separated out from Bug #1389172 to request an incident report specific to this subCA. InfoCert a) Insufficient Serial Number Entropy - See Bug #1389172: Comment #0, Comment #4, Comment #6 - Remediation - 2017-08-01 - CA Certificate was Revoked For the problem listed above, please provide an incident report as described here: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
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. - Reported via certificate problem report on August 10th. 2. A timeline of the actions your CA took in response. - Immediately (within 24 hours) 3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem. - The Sub CA was revoked back in June 2017. However, we forgot to upload the sub CA to OneCRL until right after we received the certificate problem report. 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. - Three certs: 179801356 47922359 72065818 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. 179801356 47922359 72065818 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. - The Sub CA was previously revoked by CRL but not added to OneCRL. 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. - The SubCA is revoked. The InfoCert issues can't happen again.
As for process remediation, what changes, if any, have been made to the process DigiCert uses to manage these relationships to ensure a timely upload to OneCRL? That seems to be a root cause on DigiCert's side, and so it's useful to understand how that is being improved.
Correction on Item 3. This sub CA was revoked on August 1. I added this revocation to the CCADB on August 4. On August 7 Kathleen "Changed OneCRL Status to Ready to Add." We first found out about this problem on August 10 at 9:21 a.m. when we received an email to the Mozilla Dev Security Policy list from Jonathan Rudenberg. As for process remediation / changes to our processes to manage these relationships with external sub CAs, we are implementing closer monitoring for mis-issuances, among other things.
The process change we are making is to add sub CAs to OneCRL before revoking. We will also create a revocation checklist for intermediates. This happens infrequently enough we need a checklist process to ensure all steps are properly followed.
Is this ready to close? Any more info needed?
Jeremy: One thing that is unclear is why the difference in dates between Comment #1 and Comment #3. That is, was it revoked in June or August? The CRL suggests August, but in that case, why report June?
Because 8/1/2017 and 6/1/2017 look awfully identical when you are tired and pulling information from the CCADB. Sorry about that.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.