Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
6  
I suggest reading Nick Craver's blog on Stackoverflow.com: the road to SSL. Not sure if the Stack Exchange'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 5:26
2  
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 5:48
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
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 Answers 2

up vote 9 down vote accepted

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).

share|improve this answer
1  
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
2  
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

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.

share|improve this answer
    
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.