This same information has also been posted to https://bugzilla.mozilla.org/show_bug.cgi?id=1461391
Andrew Ayer reported this problem report to mailto:sslab...@comodoca.com: <<< I was able to obtain a certificate from Comodo that was not properly validated under the Baseline Requirements, as follows: 1. Visit https://www.positivessl.com/ and click "Try Now" under "Free SSL Certificate". 2. Provide a CSR for the FQDN dcv.party. 3. On the next page, select "CNAME CSR Hash 2" as the method of Domain Control Validation. 4. Publish the following DNS record: ae104fe977c36b235260d331c949b8ca.dcv.party. CNAME 7b4c2cd1009045dc12d3e8b0c3d02912.406b5877e3a9f1eda4b7d8253ac1eb18.comodoca.com. 5. Complete the form and submit the order. 6. Receive a valid certificate for dcv.party and www.dcv.party (attached). Section 3.2.2.4.7 ("DNS Change") of the BRs says: "Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a label that begins with an underscore character." Since ae104fe977c36b235260d331c949b8ca.dcv.party is not an Authorization Domain Name for (www.)dcv.party, nor is it an Authorization Domain Name that is prefixed with a label that begins with an underscore character, this certificate was not properly validated. >>> Incident report: 1) How Comodo CA first became aware of the problem We were informed by an email from Andrew Ayer to our abuse email address mailto:sslab...@comodoca.com at 18:50 BST (UTC + 1) on Monday 14th May. 2) A timeline of the actions Comodo CA took in response. 2017 July 11 - We introduced our new implementations of DCV methods designed to meet the requirements of the CA/B Forums BR's version 1.4.1 section 3.2.2.4, as required by Mozilla. https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a05o000003WrzBC (See Action #1 in that link) 2017 July 13 - We reviewed version 1.4.1 of the BRs along with the then in-process ballots in the CA/B Forum. We determined that the underscore at the start of the CNAME LValue in 3.2.2.4.7 was optional. This now appears to have been a mistake. 2017 July 20 - We withdrew our old DCV methods that consciously relied on the 'Any Other Method'. 2017 July 20 - In response to complaints from some EU operators who found that their DNS web portals would not let them specify a leading underscore in a CNAME LValue, we introduced a new DCV variant that permitted the underscore to be omitted. 2018 May 14 - Initial problem report received from Andrew Ayer. 2018 May 15 - Code changes prepared to remove the option for the leading underscore to be omitted from the CNAME LValue in 3.2.2.4.7 domain validation. QA begins. 2018 May 18 17:20 (UTC+1) - QA completed. Code released to live. No further domains will be validated using the flawed method. 3) A summary of the problematic certificates. A total of 11099 TLS/SSL certificates were issued that used the variant of 3.2.2.4.7 that omitted the leading underscore. The earliest such certificate was issued on 2017 July 20. 10993 of those TLS/SSL certificates remain unexpired and unrevoked. 4) The complete certificate data for the problematic certificates. This is a list of all of the unexpired certificates: https://docs.google.com/spreadsheets/d/1ZW-YdrjeoUsMpTY0CW3f2D59Bl188K398oda7qTUM1Q/edit?usp=sharing 5) How and why we came to issue these certificates When implemented code to remove our reliance on the old 'Any other method' domain validation section 3.2.2.4.11 in May, June, and July 2017, the then-current version of the BRs did not actually contain any of the new DCV methods. Mozilla had requested compliance with 3.2.2.4 from version 1.4.1 which was issued in September 2016. That version including the 'blessed' methods - albeit somewhat out of date. In 2017 July we misinterpreted the words "for an Authorization Domain Name or an Authorization Domain Name that is prefixed with a label that begins with an underscore character" to mean "for an Authorization Domain Name prefixed with a label or an Authorization Domain Name that is prefixed with a label that begins with an underscore character". With hindsight we agree that this interpretation of the BRs was incorrect. We added the variant of 3.2.2.4.7 without the underscore in response to customer requests and mistakenly believed it to be a permitted variation when we implemented it. Our implementation of 3.2.2.4.7 (with or without underscore) has always required that a request-specific label is prefixed to the Authorization Domain Name as part of the Request Token. Our syntax for constructing the CNAME to pass validation is documented in https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf, but in brief is this: "When using DNS CNAME based DCV, the Request Token should appear as successive labels in the CNAME RDATA (i.e. the right hand side of the DNS CNAME definition). The format is always of the form: '_' <MD5 hash>.<Authorization Domain Name> CNAME <SHA-256 hash>.[<uniqueValue>.]comodoca.com." The 'hashes' there, both MD5 and SHA-256, are of the PKCS#10 certificate request. The variant without the underscore differed only in the omission of the initial underscore. While this was not strictly compliant with the BRs, certificates issued using this method do not pose an urgent security concern as the DCV method used provides as high a degree of certainty that the applicant controlled the certified domain as it would have done had the underscore been included. 6) Why we didn't spot it until now. One of the individuals involved in originally misinterpreting this portion of the BRs in Q2 and Q3 2017 was also responsible for our 2018 BR compliance review and repeated the original interpretation. 7) Resolution steps 2018 May 18 17:20 (UTC+1) - Code released to live. We have removed the implementation variant of the DCV check under 3.2.2.4.7 that permitted the underscore to be omitted. Some of our websites and documentation still present the "CNAME CSR Hash 2" validation method - but this cannot now lead to validation of the domain unless the underscore is present. We will remove all mentions of "CNAME CSR Hash 2" from our public facing systems over the next few days. Within the next 30 days we will have different Comodo CA staff perform a fresh BR compliance review to help ensure that no other misunderstandings of the BRs persist. We are grateful to Andrew Ayer for the problem report. Regards Robin Alden CTO for SSL Email: robin.al...@comodoca.com ComodoCA.com _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
