On Tuesday, September 11, 2018 at 3:34:45 AM UTC-4, josselin....@gmail.com 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)? 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
