On 12/09/2018 14:51, RS Tyler Schroder wrote:
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)?
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
