AlphaSSL/Globalsign: CAA Mis-Issuance on mix of wildcard and non-wildcard DNS names in SAN

RESOLVED INVALID

Status

task
RESOLVED INVALID
a year ago
a year ago

People

(Reporter: quirin, Assigned: linus.hallberg, Mentored)

Tracking

trunk

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ca-compliance])

Attachments

(1 obsolete attachment)

(Reporter)

Description

a year ago
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 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+
Assigning to Globalsign rep.

Gerv
Assignee: kwilson → linus.hallberg

Comment 3

a year 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]

Comment 4

a year 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

a year 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
Thanks, Quirin. Resolving as INVALID.

Gerv
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.