Are the rules used to validate certificates in the major browsers documented anywhere?

Question

I'm trying to get a certificate that's good for two subdomains. Essentially, the TLS equivalent of the human-level logical cert "*.*.example.com".

I've tried:

• Name constraints: these work in the standard, but don't work in practice, mostly because OS X doesn't support them.

• Wildcard certs. A single * doesn't cut it:

  If the wildcard character is the only character of the left-most label in the presented identifier, the client SHOULD NOT compare against anything but the left-most label of the reference identifier (e.g., *.example.com would match foo.example.com but not bar.foo.example.com or example.com)

  a *.* doesn't work either,

  The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label

FF rejects the double-wildcard; Safari accepts in incorrectly. Chrome rejects it (but due to using OS X to implement the certificate information dialog, upon interrogation, claims to accept it!).

Instead of feeling out these rules one at a time, is there any documentation of the algorithm(s) used by major browsers to validate certificates? (Especially since thus far, Firefox seems to be the only browser implementing the standard…)

_{¹Section 6.4.3 in the RFC heavily implies that *.*.example.com should validate,}

Answer 1

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 bar.com.

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:

1. "Security reasons"
2. Laziness

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

Answer 2

Section 6.4.3 in the RFC heavily implies that *.*.example.com should validate,

I read this section differently. In my opinion it clearly says that matches SHOULD only be done against the left-most label (6.4.3.1) and that if a wildcard is the only character in the label like in your case then it SHOULD only be matched against the left-most part of the identifier (6.4.3.2).

Based on these rules it SHOULD only match the left-most part of the identifier against the left most part of the wildcard name, i.e. only the part marked with >>..<<: >>*<<.*.example.com If course it only says SHOULD so these are recommendations only but in my experience browsers adhere to these.

is there any documentation of the algorithm(s) used by major browsers to validate certificates?

I'm not aware of any official documentation by the various vendors. But from my experience they all handle the basics the same but differ in more uncommon cases:

• No current browser supports multiple wildcards (it was new to me that Safari does according to your question), but all support left-most wildcard. Command line tools and validations in programming language slowly catch up to this behavior.
• Some check only the Subject Alternative Names (SAN) section if it contains DNS names and ignore the CN in this case. Others check CN additionally to SAN. Some stop checking the CN simply if there are any records in the SAN section, even if all of these are IP address records only.
• When validating an IP address most need the IP address as an IP entry in the SAN section. Some check the IP address also against CN. MSIE instead requires the IP address to be inside a DNS record in the SAN or as CN and does not check SAN entries of type IP address.
• Behavior regarding public suffixes is different. Some of these suffixes like co.uk have a special meaning, i.e. it should not be possible for some company to get a certificate for *.co.uk but only for *.example.co.uk. Some browsers check this behavior for some suffixes but not for all. Other browsers don't check at all.

The browser which is the strictest in most cases is Safari in my opinion, so if it works there it usually works for other browser too. But when validating IP addresses you have to address the broken handling of MSIE too by including the IP address not only as IP SAN record but also as DNS SAN record.

And of course that is only the part of validating the name in the URL against the names in the certificate. Then there is the issue of revocation, how they handle missing intermediate certificates, where they get the root certificates from etc. Lots of different behaviors between the browsers too and sometimes even between the same browser on different platforms :(