51

As far as I can tell, an SSL certificate for *.example.com is good for foo.example.com and bar.example.com, but not foo.bar.example.com.

Wildcards certificates cannot have *.*.example.com as their subject. I guess this is due to the fact that certificates like example.* aren't allowed -- allowing characters before the wildcard can lead to a malicious user matching their certificate with the wrong domain.

However, I don't see any problem with allowing certificates of the *.example.com variety to apply to all subdomains, including sub-subdomains to an infinite depth. I don't see any use case where the subdomains of a site are "trusted" but the sub-subdomains are not.

This probably causes many problems. As far as I can tell, there's no way to cleanly get certificates for all sub-subdomains; you either become a CA, or you buy certificates for each subdomain.

What's the reasoning, if any, behind restricting *.example.com to single-depth subdomains only?

Bonus question: Similarly, is there a reason behind the blanket ban on characters before a wildcard? After all, if you allow only dots and asterisks before a wildcard, there's no way that the site from a different domain can be spoofed.

TildalWave
  • 10,801
  • 11
  • 46
  • 85
Manishearth
  • 8,257
  • 5
  • 35
  • 56
  • 11
    I suggest reading [Nick Craver's blog on Stackoverflow.com: the road to SSL](http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/). Not sure if the [SE]'s path to SSL has anything to do with your question, but there's a partial answer to your question there: _"...then some jerk tried to make a certificate for `*.com` which obviously wasn't good, so that was revoked and disallowed. So what happened? Some other jerk went and tried `*.*.com`. Well, that ruined it for everyone. Thanks, jerks."_ ;) – TildalWave Jun 23 '13 at 05:26
  • 2
    http://security.stackexchange.com/questions/10538/what-certificates-are-needed-for-multi-level-subdomains – AbsoluteƵERØ Jun 23 '13 at 05:48
  • 1
    As for your bonus question, I think one of the reasons behind this decision was also what are most commonly named _Double TLDs_ (technically incorrect, as they're really more of restricted use second-level domains), such as `.co.uk` that are common for some country code top-level domains (ccTLDs). Probably nobody wanted to risk another _"jerk"_ registering `*.co.*k` (including all `.co.uk`, `.co.hk`, and others). With IANA making room for more TLDs and internationalized domain names, this could get pretty impossible to control. – TildalWave Jun 23 '13 at 05:48
  • @AbsoluteƵERØ - That thread is kinda obsolete since the inclusion of [section 6.4.3 to RFC 6125](https://tools.ietf.org/html/rfc6125#section-6.4.3). ;) – TildalWave Jun 23 '13 at 05:50
  • 1
    @TildalWave already read that a week ago. However, if you want to make a `*.com` cert, you need to prove your ownership over the `.com` domain/TLD. That's the current process anyway. – Manishearth Jun 23 '13 at 10:38
  • @TildalWave re: bonus: "If you allow only dots and asterisks before a wildcard". No characters, only dots and more wildcards allowed. – Manishearth Jun 23 '13 at 10:39
  • @Manishearth are you saying if you register `*.*.example.com` that you can literally use that domain, but not as wildcards? – AbsoluteƵERØ Jun 24 '13 at 15:04
  • @AbsoluteƵERØ I think CAs don't let you use it, period. – Manishearth Jun 24 '13 at 15:27
  • 2
    But I'm aying that it would be harmless to allow wildcard constructs like that, as long as there are only dots and more wildcards preceding any given wildcard char. – Manishearth Jun 24 '13 at 15:27

2 Answers2

26

Technically, usage of wildcards is defined in RFC 2818, which does allow names like "*.*.example.com" or "foo.*.bar.*.example.com" or even "*.*.*". However, between theory and practice, there can be, let's say, practical differences (theory and practice match perfectly only in theory, not in practice). Web browsers have implemented stricter rules, because:

  • Implementing multi-level wildcard matching takes a good five minutes more than implementing matching of names with a single wildcard.
  • Browser vendors did not trust existing CA for never issuing an "*.*.com" certificate.
  • Developers are human beings, thus very good at not seeing what they cannot imagine, so multi-wildcard names were not implemented by people who did not realize that they were possible.

So Web browsers will apply restrictions, which RFC 6125 tries to at least document. Most RFC are pragmatist: if reality does not match specification, amend the specification, not reality. Note that browsers will also enforce extra rules, like forbidding "*.co.uk" (not all browsers use the same rules, though, and they are not documented either).

Professional CA also enter the dance with their own constraints, such as identity checking tests before issuing certificates, or simply unwillingness to issue too broad wildcard certificates: the core business of a professional CA is to sell many certificates, and wildcard certificates don't help for that. Quite the opposite, in fact. People want to buy wildcard certificates precisely to avoid buying many individual certificates.

Another theory which failed to make it into practice is Name Constraints. With this X.509 extension, it would be possible for a CA to issue a certificate to a sub-CA, restricting that sub-CA so that it may issue server certificates only in a given domain tree. A Name Constraints extension with an "explicit subtree" of value ".example.com" would allow www.example.com and foo.bar.example.com. In that model, the owner of the example.com domain would run his own CA, restricted by its über-CA to only names in the example.com subtree. That would be fine and dandy.

Unfortunately, anything you do with X.509 certificates is completely worthless if deployed implementations (i.e. Web browsers) don't support it, and existing browsers don't support name constraints. They don't, because there is no certificate with name constraints to process (so that would be useless code), and there is no such certificate because Web browsers would not be able to process them anyway. To bootstrap things, someone must start the cycle, but browser vendors wait after professional CA, and professional CA are unwilling to support name constraints, for the same reasons as previously (which all come down to money, in the long run).

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 2
    I still don't see why browsers don't trust CAs for assigning `*.*.com` certs: (a) They trust them to assign `*.com` and a duplicate `*.google.com` (or whatever), and (b) CAs have their own mechanisms to check ownership. If you don't own `*.com`, you can't get a cert, just like the owner of `abcd.cloudfire.com` can't get a cert for `*.cloudfire.com`. Also, `*.com` is easily prevented by disallowing `*.tld`. But the rest of the points make sense. Name constraints seem like a smart move, but I guess it would take a lot of time before that comes into play. – Manishearth Jul 23 '13 at 18:06
  • 3
    That's the idea: _normally_ no sane CA should ever issue an `*.com` certificate, since nobody owns `com`. But browser vendors don't trust CA for never botching up things, and so they _also_ reject `*.com` if that one ever comes up in a certificate. The browsers try defend against CA bugs. In practice, each browser has its own list of exclusions, and not all browsers agree on that matter. – Tom Leek Jul 23 '13 at 20:30
6

As mentioned on comments, RFC6125 explains it pretty well (excerpt from section 7.2)

Specifications for existing application technologies are not clear or consistent about the allowable location of the wildcard character.

...

These ambiguities might introduce exploitable differences in identity checking behavior among client implementations and necessitate overly complex and inefficient identity checking algorithms.

So, basically this behaviour is enforced in order to simplify the checking, thus increasing security.

Community
  • 1
drak
  • 116
  • 2
  • I don't see how infinite depth wildcards can lead to exploitable differences. If there are any, I'd like to know. And the identity checking algorithm would be easier in this case afaict. – Manishearth Jun 28 '13 at 23:13