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