Dear Corey, Dear Jeremy, thank you for your responses! I had seen a certificate with this pattern, and confirmed by your answers have done a more complete scan.
I found 5 certificates with that pattern that had CAA records set at issuance time (approximated by “not valid before” and SCT) that would not have allowed issuance per our discussion. I am aware that CAA records are only for consumption by CAs, and that my 3rd-party lookups do not prove anything — CAs may either have received different replies, or the records may have undergone a brief global change so my 24-hour-interval does not capture the change. Yet the historic consistency of DNS data for these domains, coupled with a certain ambiguity around this case, may provide anecdotal evidence to look into these 5 issuances? Details below: (Please note that the DNS replies are generally stable for more days than displayed). ======== Certificate 1 ======== https://crt.sh/?id=215028491 X509v3 Subject Alternative Name: DNS:*.netservicesgroup.com DNS:netservicesgroup.com Issuer COMODO CA Limited DNS history (Certificate issued on Sep 20): 2017-09-18:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com" 2017-09-18:netservicesgroup.com. 86400 IN CAA 0 issue ";" 2017-09-19:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com" 2017-09-19:netservicesgroup.com. 86400 IN CAA 0 issue ";" 2017-09-20:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com" 2017-09-20:netservicesgroup.com. 86400 IN CAA 0 issue “;" 2017-09-21:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com" 2017-09-21:netservicesgroup.com. 86400 IN CAA 0 issue ";" 2017-09-23:netservicesgroup.com. 86400 IN CAA 0 issuewild “comodoca.com" 2017-09-23:netservicesgroup.com. 86400 IN CAA 0 issue “;" ======== Certificate 2 ======= https://crt.sh/?id=211113116 X509v3 Subject Alternative Name: DNS:*.trnava-vuc.sk DNS:trnava-vuc.sk Issuer: thawte, Inc. DNS history (Certificate issued on Sep 13) 2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issuewild "symantec.com" 2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com" 2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com" 2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issuewild "thawte.com" 2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issue ";" 2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com" 2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com" 2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com" 2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issue ";" ======== Certificate 3 ======== https://crt.sh/?id=226175601 X509v3 Subject Alternative Name: DNS:*.drillisch-online.de DNS:drillisch-online.de Issuer: COMODO CA Limited DNS history (Certificate issued on Sep 29): 2017-09-28:drillisch-online.de. 3600 IN CAA 0 issuewild "globalsign.com" 2017-09-28:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com" 2017-09-28:drillisch-online.de. 3600 IN CAA 0 issue ";" 2017-09-29:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com" 2017-09-29:drillisch-online.de. 3600 IN CAA 0 issue ";" 2017-09-30:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com" 2017-09-30:drillisch-online.de. 3600 IN CAA 0 issue ";" ======= Certificate 4 ======= https://crt.sh/?id=221763552 X509v3 Subject Alternative Name: DNS:*.uhlhosting.ch DNS:uhlhosting.ch Issuer: Comodo DNS history (Certificate issued on Sep 29): 2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com" 2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issue “;” 2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com” 2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issue “;” 2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com” 2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issue “;” 2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com" 2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issue “;” ======== Certificate 5 ======== https://crt.sh/?id=211729608 X509v3 Subject Alternative Name: DNS:*.provida.net DNS:provida.net Issuer: COMODO CA Limited DNS history (Certificate issued on Sep 15): 2017-09-13:provida.net. 600 IN CAA 0 issuewild "comodo.com" 2017-09-13:provida.net. 600 IN CAA 0 issuewild "symantec.com" 2017-09-13:provida.net. 600 IN CAA 0 issue ";" 2017-09-14:provida.net. 600 IN CAA 0 issuewild "comodo.com" 2017-09-14:provida.net. 600 IN CAA 0 issuewild “symantec.com" 2017-09-14:provida.net. 600 IN CAA 0 issue “;" 2017-09-15:provida.net. 600 IN CAA 0 issuewild "comodo.com" 2017-09-15:provida.net. 600 IN CAA 0 issuewild "symantec.com" 2017-09-15:provida.net. 600 IN CAA 0 issue ";" 2017-09-16:provida.net. 600 IN CAA 0 issuewild "comodo.com" 2017-09-16:provida.net. 600 IN CAA 0 issuewild “symantec.com" 2017-09-16:provida.net. 600 IN CAA 0 issue “;" 2017-09-17:provida.net. 600 IN CAA 0 issuewild "comodo.com" 2017-09-17:provida.net. 600 IN CAA 0 issuewild "symantec.com" 2017-09-17:provida.net. 600 IN CAA 0 issue ";" Kind regards Quirin > On 16. Nov 2017, at 04:37, Jeremy Rowley via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > IMO - This is the correct interpretation. Yourca could disuse the wildcard > cert for *.example.com but could not issue a cert with multiple SANs > containing both *.example.com and example.com. > On 15. Nov 2017, at 16:37, cbonnell--- via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Wednesday, November 15, 2017 at 8:11:18 AM UTC-5, Quirin Scheitle wrote: >> Hi all, >> >> I have a question regarding processing of CAA records for “wildcard >> certificates”. >> >> Let’s assume the following CSR: >> >> X509v3 Subject Alternative Name: >> DNS: *.example.com >> DNS: example.com >> >> Per BR, every SAN DNS name must be checked separately. >> Now, my interpretation would be that for *.example.com, you would query >> example.com for an “issuewild" entry, >> and for example.com, you would query example.com for an "issue" entry. >> >> What if the zone file looks like this: >> example.com 0 CAA 0 issue “;” >> example.com 0 CAA 0 issuewild “yourca” >> >> My interpretation would be that “yourca” (as any other CA) would not be >> permitted to issue this certificate, >> as it is not allowed to issue for the non-wildcard part example.com. >> >> A plunge through the related documents [see appendix] seems to point in that >> direction, but I still have doubts. >> >> What is the community interpretation? >> >> Kind regards >> Quirin >> >> --------- >> >> Appendix: >> >> BR defines a wildcard certificate as "Wildcard Certificate: A Certificate >> containing an asterisk (*) in the left‐most position of any of the Subject >> Fully‐Qualified Domain Names contained in the Certificate.” —> This means >> that the whole certificate is a wildcard certificate. >> >> — >> >> RFC2818: >> >>> Names may contain the wildcard character * which is considered to match any >>> single domain name component or component fragment. E.g., *.a.com matches >>> foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. >> >> —> example.com is not part of *.example.com >> >> RFC6844: >> >>> " issuewild <Issuer Domain Name> [; <name>=<value> ]* : The issuewild >>> property entry authorizes […] to issue wildcard certificates for the >>> domain in which the property is published." >> >> >>> "Given a request for a specific domain X, or a request for a wildcard >>> domain *.X, the relevant record set R(X) is determined as follows:” >> >> —> The 'relevant record set' is specified per domain >> >>> "issuewild properties MUST be ignored when processing a request for a >>> domain that is not a wildcard domain." >> >> —> Especially this last paragraph seems to indicate that the CSR above would >> not be permitted to be issued. Also, it specifically uses “domain” and not >> “certificate”. > > Hi Quirin, > You are correct that the certificate will not issue. Here's a breakdown of > the steps taken by the "yourca" CA to check CAA: > > 1) Retrieval of CAA records at "example.com" for SAN "*.example.com". > 2) Both an "issue" and "issuewild" record exist, and the SAN "*.example.com" > is a wildcard SAN, so the "issuewild" record has precedence over the "issue" > record (RFC 6844, section 5.3 states: "issuewild properties take precedence > over issue properties when specified"). > 3) The identifying domain name in the "issuewild" record is compared with the > set of yourca's identifying domain names. A matching identifying domain name > is found, so the "yourca" CA is permitted to issue for "*.example.com". > 4) Retrieval of CAA records at "example.com" for SAN "example.com". > 5) As stated in step 2, both "issue" and "issuewild" records exist, but the > SAN "example.com" is not a wildcard SAN, so the "issuewild" record is ignored > (RFC 6844, section 5.3 states: "issuewild properties MUST be ignored when > processing a request for a domain that is not a wildcard domain"). > 5) The identifying domain name in the "issue" record is the empty string, so > "yourca" can't issue for "example.com". > 6) The issuance attempt fails. > > Hope that helps. > > Thanks, > Corey Bonnell > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
