Per https://www.ccadb.org/cas/incident-report#incident-reports, this mailing list is not the correct place for the incident report. Incident reports should go: https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&list_id=16291008
On Wednesday, July 19, 2023 at 2:09:24 PM UTC-4 Sándor dr. Szőke wrote: > MICROSEC INCIDENT REPORT - No OCSP status response for 2 Precertificates > ------------------------------ > > I -- 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. > > Microsec received an iformation by phone, that 2 Microsec OCSP problems > reported on the following site: https://sslmate.com/labs/ocsp_watch/ > ------------------------------ > > II -- 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. > > 2023-07-18 19:55 CET > > - receive a notification phone call about the problem > > 2023-07-18 19:57 CET > > - Microsec opened an internal JIRA ticket to record the problem > > 2023-07-18 20:11 CET > > - initiating an investigation to identify the cause(s) of the problem > and to prevent further similar errors > > 2023-07-18 20:49 CET > > - information collected about the problematic precertificates > > 2023-07-18 20:56 CET > > - finding the reason of the problem > > 2023-07-18 21:00 CET > > - adding the two missing precertificates to our OCSP responders > database > - revoking the two precertificates > - error messages disappeard from the > https://sslmate.com/labs/ocsp_watch/ > > ------------------------------ > > III -- 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. > > > - The two problems happened in different time, so they were > independent events. > - The investigation started after office hours, when there is no > certificate issuance. > - The problem was temporarily solved very quickly, so there was no > need to stop the certificate issuance. > > ------------------------------ > > IV -- 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. > > 2022-12-16 > > - One precertificate without issued TLS certificate - > https://crt.sh/?id=8214560966 > > 2023-04-14 > > - One precertificate without issued TLS certificate - > https://crt.sh/?id=9146975721 > > ------------------------------ > > V -- 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. > > > domain > crt.sh link > dtk.kszdr.gov.hu > https://crt.sh/?id=8214560966 > smtp1.mkb.hu > https://crt.sh/?id=9146975721 > ------------------------------ > > VI -- Explanation about how and why the mistakes were made or bugs > introduced, and how they avoided detection until now. > > We performed the initial investigation and we found the following > > - We could find in the CA log entries, that in booth cases an error > happened during the certificate issuance: > > -- the precertificate was created successfully > > -- the precertificate transmitted to at least one log server successfully > > -- the CA software could not reach the necessary number of log servers > > -- the certificate issuance process was terminated with an error status > > -- the TLS certificate was not issued > > -- due to the improper error management flow installed in the CA software, > the precertificate has not been added to the OCSP responders database. > > - After the unsuccessful issuance, the CA created a new precertificate > with the same plublic key and with new serial number, and with that the > certificate issuance was successful. > > Summary of the findings > > The problem was caused by a configuration problem in the CA program > > - the precertificate was not added to the OCSP responders database, > when at least one log server could respond with an SCT > > ------------------------------ > > VII -- 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. > > Immediate actions > > - Microsec added the two missing precertificates to its OCSP > responders database > - Microsec revoked the two problematic precertificates immediately > - A quick initial investigation was made to find out the reason of the > problem. > - Microsec identified the causes of the problem as you see it above. > - Microsec made a quick fix on the CA program, which reduces the > chance to have this type of problem again > - Microsec opened an incident bug in Mozilla's Bugzilla with the > present report. > > ------------------------------ > Further planned actionsDeadline: 2023-08-20 > > - Microsec will make a more detailed investigation on the CA software > and makes further changes if necessary to prevent this problem happening > again. > - Microsec will develop an automatic tool tho check the > https://sslmate.com/labs/ocsp_watch/ daily > > -- You received this message because you are subscribed to the Google Groups "CCADB Public" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/3d64e640-1d97-4a08-af76-5f834602c2f9n%40ccadb.org.
