32

Something like *.com or *.net? How about *.edu.au?

The RFC 2818 does not say anything about this topic.

curiousguy
  • 5,028
  • 3
  • 25
  • 27
Nam Nguyen
  • 1,450
  • 12
  • 14

3 Answers3

32

Yes, it can be issued.

Luckily the common browsers do not accept wildcard certificates for TLDs.

Chromium Source Code:

// Do not allow wildcards for public/ICANN registry controlled domains -
// that is, prevent *.com or *.co.uk as valid presented names, but do not
// prevent *.appspot.com (a private registry controlled domain).
// In addition, unknown top-level domains (such as 'intranet' domains or
// new TLDs/gTLDs not yet added to the registry controlled domain dataset)
// are also implicitly prevented.
// Because |reference_domain| must contain at least one name component that
// is not registry controlled, this ensures that all reference domains
// contain at least three domain components when using wildcards.
size_t registry_length =
    registry_controlled_domains::GetCanonicalHostRegistryLength(
        reference_name,
        registry_controlled_domains::INCLUDE_UNKNOWN_REGISTRIES,
        registry_controlled_domains::EXCLUDE_PRIVATE_REGISTRIES);

// ... [SNIP]

// Account for the leading dot in |reference_domain|.
bool is_registry_controlled =
    registry_length != 0 &&
    registry_length == (reference_domain.size() - 1);

// Additionally, do not attempt wildcard matching for purely numeric
// hostnames.
allow_wildcards =
    !is_registry_controlled &&
    reference_name.find_first_not_of("0123456789.") != std::string::npos;
}

The complete list of domains that Google disallows is in net/base/registry_controlled_domains/effective_tld_names.dat

Other browsers also do this, including IE and Firefox.

In the list of fake certificates issued by DigiNotar, there is "*.*.com". This is obviously an attempt to get around the restriction.

Moshe Katz
  • 1,331
  • 1
  • 11
  • 17
Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
  • *Do not allow wildcards for public/ICANN registry controlled domains* – does this mean `*.localhost` is actually supposed to work then? It's not public and is also not included in the [*effective_tld_names.dat*](https://chromium.googlesource.com/chromium/src/+/master/net/base/registry_controlled_domains/effective_tld_names.dat) file – mehov Oct 02 '21 at 17:04
12

For the issuing part, everything can be put in a certificate. That a name is "wildcard" has no special significance for the CA. The CA puts a string as dNSName in a Subject Alt Name extension, and that's it. Whether this string contains "*" characters or not will not impact the CA behaviour.

What matters is what SSL clients will accept as a "valid certificate", i.e. a certificate including a name which "matches" the intended server name (the one included in the URL). This is nominally specified in RFC 2818, section 3.1, and it allows many kinds of wildcard names, including things like "www.*.*c*", matching (theoretically) any server name containing three components, the first being "www" and the third containing at least one "c". Web browser vendors soon considered that this specification:

  • allowed for really broad wildcard names;
  • was relatively complex to implement properly;
  • was unlikely to be implemented properly by both other browser vendors, and by CA (though the CA is not impacted by the name contents, it is still responsible for the contents of the certificate, and browser vendors correctly guessed that there would be CA who would unwillingly issue overly broad wildcard certificates);
  • was an "informational" RFC anyway, not a "proposed standard", so lawyer-inclined minds could argue that it could be ignored.

So browser vendors made their own schemes and restrictions. Much later, a new RFC (6125, from March 2011) was published, with section 6.4.3 dedicated to the processing of wildcard names in certificates. What RFC 6125 describes is more in tune with the reality, and is a "proposed standard", so there is at least some will, at some level, to make it happen. However, nothing in RFC 6125 mandates rejection of *.com; yet browsers do reject it.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 4
    Thanks for that very informative answer. I had set up a local DNS for Windows and Linux servers with `.staging` as the TLD. To save on creating and signing certificates for each virtual host and avoid having to configure new IP addresses (non-SNI web servers), I created a key and cert for `*.staging` but all the clients I tried (including curl) only reported that `certificate subject name '*.staging' does not match target host name`. I had read the relevant Wikipedia article and RFCs but was none the wiser -- until now. – Anthony Geoghegan Jan 21 '15 at 09:15
  • @ThomasPornin : Even if several part of a subdomain [can lead to an existing name](http://security.stackexchange.com/q/122211/36301) ? – user2284570 May 03 '16 at 16:09
3

I have tested this on common browsers, the three big ones (on windows anyways) don't accept this. What I haven't done is try it on the mobile platforms which imo are the real target of this attack. Since iOS doesn't have a way to revoke certificates there are millions of i-devices out there that are vulnerable until apple releases a patch, and they apply it.

Obvious places to try this with high impact: Activesync to exchange, ssl vpn clients, safari on idevices, stock browser on androids.

Ori
  • 2,757
  • 1
  • 15
  • 29