Hi Quirin.
I agree that Comodo should not have issued certificates 1, 3, 4 and 5.
When issuing a "single domain" certificate to (for example)
www.example.com or *.example.com, it's fairly common practice for CAs to
also include in the certificate a SAN.dNSName for the "base domain"
(e.g., example.com). (Similarly, if the certificate request is for
example.com, some CAs will add a SAN.dNSName for www.example.com).
Due to a bug in our CAA checking implementation, we were failing to
perform CAA checks for these extra dNSNames that weren't explicitly
requested by customers. I believe that this is why we did not block
issuance of the 4 certificates you identified.
We spotted this bug a few weeks ago (sorry, I don't have a note of
precisely when), during internal testing against Andrew Ayer's excellent
CAA test suite [1]. We prepared a fix.
As promised in our earlier CAA incident report [2], we engaged "the
services of an external security consultant to independently assess our
new CAA checking implementation and to work with us to ensure that it
behaves correctly". The consultant also identified this bug.
The fix was deployed to our production systems on Friday 17th November.
[1] https://caatestsuite.com/
See the "Special Tests" section.
[2]
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08054.html
On 17/11/17 14:41, Quirin Scheitle via dev-security-policy wrote:
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
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
