Am Dienstag, 12. Dezember 2017 11:10:00 UTC+1 schrieb [email protected]: > 1)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. > > We became aware of the problem during an internal review of the configuration > change from last week at Monday December 11 2 .30 p.m. UTC. > > 2) 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. > > •2017/12/04 2 p.m. UTC: Test Setup with wrong configuration has been set up. > •2017/12/06 12.10 p.m. UTC – 2017/12/08 3.40 p.m. UTC: 10 Certificates were > issued using the wrong configuration. The configuration should have been > using an internal not public trusted CA. > •2017/12/11 2.30 p.m. UTC: Wrong setup was detected during the internal > setup review process. > •2017/12/11 3.00 p.m. UTC: The affected configuration has been suspended. > •2017/12/11 3.30 p.m. UTC: Affected Certificates were immediately revoked > after a short internal review. > •2017/12/11 3.00 p.m. UTC: The affected configuration has been corrected. > •2017/12/12 10:00 p.m. UTC: Incident report was submitted to Mozilla > > > 3) 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 affected configuration has been corrected. Since then, no such > certificates have been issued. > > 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. > > The subject information in the affected certificates were not validated > correctly due to the misconfiguration. 10 certificates were issued based on > this misconfiguration between 2017/12/06 12.10 p.m. UTC and 2017/12/08 3.40 > p.m. UTC. > > 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. > > https://crt.sh/?id=273776520 > https://crt.sh/?id=273776617 > https://crt.sh/?id=272950014 > https://crt.sh/?id=272950007 > https://crt.sh/?id=272950012 > https://crt.sh/?id=272950010 > https://crt.sh/?id=272166103 > https://crt.sh/?id=272166102 > https://crt.sh/?id=272166107 > https://crt.sh/?id=272166110 > > > > 6) Explanation about how and why the mistakes were made or bugs introduced, > and how they avoided detection until now. > > The employee wanted to set up a test set up for a partner and have made a > mistake in choosing the wrong template for the issuing CA (productive EV CA > instead of a untrusted internally used test CA). > > 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 implemented controls detected the misconfiguration within 24 hours. The > incorrect configuration was nevertheless recorded as a security incident. The > handling of the security incident by the information security management team > is still underway. Further measures will be decided within this process.
Update on the long-term countermeasures: At the first point - sorry for the delay. I missed to post my answer on Fryday. We The occurred error caused by a human error we decided as a long-term protection measure to carry out the setup in the 4 AP and all possible restrictions in case of test accounts. In this way, a repetition of the error is to be prevented. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
