Closed
Bug 1420766
Opened 7 years ago
Closed 7 years ago
AlphaSSL/Globalsign: CAA Mis-Issuance on mix of wildcard and non-wildcard DNS names in SAN
Categories
(CA Program :: CA Certificate Compliance, task)
CA Program
CA Certificate Compliance
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: quirin, Assigned: linus.hallberg, Mentored)
Details
(Whiteboard: [ca-compliance])
Attachments
(1 obsolete file)
As per Gerv's request, I am filing individual bugs for [1] -- please confer to [1] for a full background. In this case, GlobalSign likely mis-issued on a mixed wildcard/non-wildcard SAN, as discussed in [2] and listed in [3]. What likely happened is that GlobalSign validated CAA for the wildcard SAN *.invinsec.com and then added the base domain invinsec.com without a further CAA check. As GlobalSign is not listed in the issue set, it was not permitted to add the base domain SAN. To proceed with this as a community, I guess answers to the the following questions from the affected CAs [1] would be of interest: a) Was CAA checking bypassed for this issuance? If so, why? b) If CAA lookups were conducted, what response did you receive? Why did it permit issuance? The certificate in question is this: ======= Certificate 8 - Group 1 ====== https://crt.sh/?id=254174871 X509v3 Subject Alternative Name: DNS:*.invinsec.com DNS:invinsec.com Issuer: GlobalSign (AlphaSSL) DNS history (Issued Nov 12 00:57): 2017-11-10:invinsec.com. 300 IN CAA 0 issue "digicert.com" 2017-11-10:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org" 2017-11-10:invinsec.com. 300 IN CAA 0 issuewild ";" 2017-11-11:invinsec.com. 300 IN CAA 0 issue "digicert.com" 2017-11-11:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org" 2017-11-11:invinsec.com. 300 IN CAA 0 issuewild "globalsign.com" 2017-11-12:invinsec.com. 300 IN CAA 0 issue "digicert.com" 2017-11-12:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org" 2017-11-12:invinsec.com. 300 IN CAA 0 issuewild "globalsign.com" 2017-11-13:invinsec.com. 300 IN CAA 0 issue "digicert.com" 2017-11-13:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org" 2017-11-13:invinsec.com. 300 IN CAA 0 issuewild "globalsign.com" 2017-11-14:invinsec.com. 300 IN CAA 0 issue "digicert.com" 2017-11-14:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org" 2017-11-14:invinsec.com. 300 IN CAA 0 issuewild “globalsign.com" [1] https://groups.google.com/d/topic/mozilla.dev.security.policy/QpSVjzrj7T4/discussion [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/O9HZPMvHMY8/HtXR8S-1AAAJ [3] https://misissued.com/batch/32/
Comment 1•7 years ago
|
||
Comment on attachment 8931987 [details] Bug 1420776 - Various coverity issues on TLS 1.3 branch, r?franziskus Eric Rescorla (:ekr) has approved the revision. https://phabricator.services.mozilla.com/D286#6916
Attachment #8931987 -
Flags: review+
Comment 3•7 years ago
|
||
By the way, I think that Comment #1 and the attachment were added by mistake... Checking with a developer. Linus, please reply in regards to the bug description: GlobalSign likely mis-issued on a mixed wildcard/non-wildcard SAN, as discussed in [2] and listed in [3].
Whiteboard: [ca-compliance]
Updated•7 years ago
|
Attachment #8931987 -
Attachment is obsolete: true
Comment 4•7 years ago
|
||
Our CAA logs indicate that at the time of issuance there were no issuewild entries and that "digicert.com", "globalsign.com", "letsencrypt.org" and "rapidssl.com" were all listed as issue entries. We're curious about how the DNS History was complied as it does not seem to match what we logged. Can you please explain how this history was created? Here is a snip from our log: Nov 12 09:57:33 gscaa01 caa-server: time="2017-11-12T09:57:33+09:00" level=debug msg=" ninvinsec.com.\t3600\tIN\tCAA\t0 iodef "mailto:soc@invinsec.com"\ ninvinsec.com.\t3600\tIN\tCAA\t0 issue "digicert.com"\ ninvinsec.com.\t3600\tIN\tCAA\t0 issue "globalsign.com"\ ninvinsec.com.\t3600\tIN\tCAA\t0 issue "letsencrypt.org"\ ninvinsec.com.\t3600\tIN\tCAA\t0 issue "rapidssl.com"\ ninvinsec.com.\t3600\tIN\tRRSIG\tCAA 8 2 300 20171130082947 20171108082947 32545 invinsec.com. NYHy72kkQCmHSTSw+FgE5ViFTFDgDgIkyzcqZYTw7fnesdHrtPNyVGoijrzTUXg35lxG8U9cclVXOtW7/lGJVxfEbEdld27P7GHbnT+8FmhYyGbKkM0/FG7c86cPdIBPAvYG/Z47oDtBd7QzMkeW+xD87+7114zJBvtKN/D/ZO0=\n\n;; Nov 12 09:57:33 gscaa01 caa-server: time="2017-11-12T09:57:33+09:00" level=info msg="check complete" issuer=globalsign.com domain_count=2 domains="[*.invinsec.com invinsec.com]"
Reporter | ||
Comment 5•7 years ago
|
||
Hi, thank you for your reply! Our history is compiled from 4 different scans using different tools. 1 of the scans queries all name servers every 8 hours, which all responded uniformly. If I am not mistaken in conversion, we happened to measure 6 hours before and 2 hours past your measurement. Here are more precise timestamps from the scan that queries all name servers. 2017-11-11 10:51 UTC issue: Let'Encrypt, DigiCert issuewild: ; 2017-11-11 18:51 UTC issue: Let'Encrypt, DigiCert issuewild: ; <-- Your measurement (00:57 UTC) 2017-11-12T09:57:33+09:00 : issue Let'Encrypt, DigiCert, Globalsign, RapidSSL; no issuewild tag 2017-11-12 02:52 UTC Let'Encrypt, DigiCert issuewild: Globalsign 2017-11-12 10:52 UTC Let'Encrypt, DigiCert issuewild: Globalsign 2017-11-12 18:52 UTC Let'Encrypt, DigiCert issuewild: Globalsign 2017-11-13 02:52 UTC Let'Encrypt, DigiCert issuewild: Globalsign 2017-11-13 10:52 UTC Let'Encrypt, DigiCert issuewild: Globalsign The last records we observed are also still active [http://dnsviz.net/d/invinsec.com/Wh7ETQ/dnssec/, drill -t CAA invinsec.com @9.9.9.9 right now]. I believe what has happened is this: The domain had a set of CAs that did not permit issuance of the certificate requested. Shortly before issuance, they changed that set into the set that you have seen. Shortly after issuance, they changed if further into yet a different configuration. Given the evidence provided by Globalsign, I would consider this a false positive -- our measurement simply did not see that specific configuration which apparently only existed for a brief time period. Kind regards Quirin
Comment 6•7 years ago
|
||
Thanks, Quirin. Resolving as INVALID. Gerv
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Updated•1 year ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•