Josselin: thank you for filing this incident report, and for your answers to the questions being asked in this thread.
Please add the incident report to the related bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1485413 I will also ask you to answer the new questions that have been asked to the best of your ability. It is my hope that we can all use this information to learn from and prevent future incidents from occurring. On Wed, Sep 12, 2018 at 8:46 AM Jakob Bohm via dev-security-policy < [email protected]> wrote: > On 12/09/2018 14:51, RS Tyler Schroder wrote: > > On Tuesday, September 11, 2018 at 3:34:45 AM UTC-4, > [email protected] wrote: > >> The audit of our previous CAA check practices ensured that the CA/B > Forum requirements were met except for a single certificate for which the > CA was not authorized to issue according to the DNS CAA record. > >> > >> This failure is related to our old practices that led to a control of > the DNS CAA records with automatic alerts for the Registration Officers, > but the blocking of the certificate request was not automatic unlike today. > It was found that the request had been approved despite this alert, and in > particular because of the provision of additional supporting documents by > the applicant such as a request for a certificate signed by the legal > representative of the entity accompanied by a photocopy of his identity > document, which attest to the consent to issue. > >> > >> We checked the logs of the controls carried out and re-rolled these > controls on all the SSL certificates issued since September 8th and confirm > that only this certificate was the object of a failure. > >> > >> This certificate, which has not yet been deployed and used by the > customer, has been identified and revoked by the CA and is now included in > the CRL with the following serial number: 476abeb2bc78d588ef4b8f27dbd25f6a > (see http://crl.certigna.fr/servicesca.crl). > >> > >> Note that this incident will not be able to happen again by means of > our new practices that automatically block any certificate request for > which the DNS CAA record controls induce that the CA is not allowed to > issue, without possible bypass by the RA. These practices are described in > the latest updated versions of our CP/CPS. > >> > >> We remain at your disposal if you want further information. > > > > Adding Q24/25 > > > > 24. Your CPS for the Root and Wild CPSs as of 8/31/2018 note in section > 4.2.1 that a certificate issue that did not comply with RFC6844 would be > automatically blocked. Your note in the first post says that "our new > practices that automatically block any certificate request for which the > DNS CAA record controls induce that the CA is not allowed to issue, without > possible bypass by the RA". Was this blocking process not fully automated > as described prior (going off of Q23 from Jakob)? > > > This issue was identified in discussion of Certigna's current root renewal request [1], in which Certigna stated that their system has automatically checked CAA records since September 8, 2017, but rather than blocking issuance, the system alerted RA officers who were responsible for denying the request. Based on the statements made by Certina, I believe that they fundamentally misunderstood the BR requirement for a CA to reject all requests that fail CAA processing, regardless of any other compensating controls the CA has in place. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/z7iDk9CdTFo/hCZGQRm4AQAJ > > The unqualified mention of "September 8" confused me at first, but it > obviously refers to the "CAA Mandatory BR" taking effect on "September > 8, 2017", thus the single misissuance probably happened between > September 8, 2017 and when they changed the policy on August 31, 2018. > > However I cannot tell, because I can't find the serial number on crt.sh. > > > > > 25. What exactly prompted the manual override for CAA Checking? A > request from the origin certificate requestor, the RA on their own... > > > > > > > Relevant section: > >> The following cases do not allow the CA to authorize the issuance of > the certificate: > >> - The CAA DNS field is present, it contains an "issue" or "issuewild" > tag and does not list > >> Certigna as an authorized Certificate Authority; > >> - The CAA DNS field is present, it is designated as "critical" and the > tag used is not supported > >> by the CA (it is not an "issue" or "issuewild" tag); > >> - The zone is validly DNSSEC-signed and our DNS query times out. > >> If any of these cases are encountered, the certificate request is > automatically blocked and the > >> applicant is notified by email of the need to update the associated DNS > records. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
