What browsers do is subject to change at the whims of whoever maintains them, and they do so without any proper documentation.
The treatment of wildcards in
dNSName entries in certificates is formally defined in RFC 2818, which would imply that, e.g.,
*.*.example.com would match a subdomain name that's two levels down
example.com; it also says that
f*.com shall actually match
foo.com but not
It turned out that browsers don't follow these rules, for a variety of reasons which have never been fully documented, but which mainly fall into two categories:
- "Security reasons"
"Security" here means "we ran into some abuse and changing the rules on the fly looked like a good idea at the time". For instance, once somebody produced an
*.com certificate, somebody figured out that it was not a very good idea, and found it expedient to simply forbid it in the browser code. An important point to consider here is that browser vendors and commercial CA are not the same people; from the point of view of a browser maintainer, if something must be done quickly (e.g. within 24 hours, not 24 months), it must be done in the browser itself. Security issues related to browsers tend to be highly publicized and quite damaging to the browser's image, so this call for prompt reaction, which usually (and unfortunately) precludes good documentation.
Laziness is probably at fault for the lack of support of "double wildcards" like
*.*.example.com. In all generality, if you want to implement support for expressions with several wildcards, you have to do it with nested loops (to explore all possible matching combinations). Restricting wildcards to a single "
*", moreover at the very start of the name, makes the implementation much simpler.
An additional fact to take into account is the paralyzing property of "security". When something has been done, or seems to have been done, in the name of "security" then many developers lose all initiative and are extremely reluctant to modify it -- because they know that any mishap related to security entails full blame.
RFC 6125 tried to document existing practice, although it varies quite a lot depending on browser (and OS, since some browsers delegate certificate validation and processing to the OS). Note that RFC 6125 does not really forbids more than one
* in a name; in fact, an errata has been submitted about that, and the editor put it under the status "held for document update", which really means "good point, we'll fix it in a later RFC".
While RFC 6125 lists requirements on the browser side (consumer of certificates), the CA/browser forum also considers the CA side (producer of certificates). The Baseline Requirements seem to imply that only a single
* may occur, and only at the left of a name (but this is not very clearly stated).
While there is a lot more to certificate validation than wildcard name processing, all the business around the
* character illustrates quite well that nothing is firmly documented, and browser vendors have already taken the habit to do things first, and document things only much later (if at all).