SSL Wildcard Certification that covers more than one layer of subdomains?

Question

I'm working on a site that provides bespoke websites to franchisees of a large organization. Each franchisee is managed as a separate sub-domain and everything is handled by one set of servers, which parse off the sub-domain name, and then based on that, serve up the properly composed pages so that the overall site has standard branding, but portions of the page are customized for each franchisee. So if the root domain is "delivery.com" for example, then a certain franchisee might have "newyork.delivery.com" as their unique domain, and another might be "chicago.delivery.com". All of the sites are served by a single server (maybe load-balanced multiple servers) that uses the "newyork" or "chicago" subdomain to serve similar but different sites depending on which url you ask for. To avoid having to come up with separate DNS entries for everything, we are using a wildcard DNS entry for "*.delivery.com" pointing to the single server (or loadbalancer). Slick!

In order to provide SSL for this system, we went and asked for a wildcard SSL Certificate for "*.delivery.com" and that seems to have been wonderful except for one thing... if somebody accidentally types in "www.newyork.delivery.com" they get told that there's no SSL certificate and rather alarmingly that someone may be spoofing them for nefarious purposes! Certainly not the type of messaging that's desired. So the DNS lookup for "www.newyork.delivery.com" correctly resolves to our server, but before my code even gets executed on the server, the browser determines that the wildcard SSL certificate we have doesn't cover a 2nd level subdomain, and displays an error to the user. So, as it turns out, for DNS entries "*.delivery.com" means "anything under the delivery.com domain, including multiple layers of subdomains". But when asking for an SSL certificate, "*.delivery.com" means "one-level of subdomain only". How do I ask for an SSL certificate that provides protection for an entire domain, including all of the subdomains (multiple levels deep) beneath that domain? Barring that, it seems like my only solution would be to create CNAME entries for each of the fully-qualified subdomains I want to support, and then at least the error to the browser would be the less alarming "site not found" error. Any other solutions would be appreciated!

Answer 1

Multi-level wildcard certificates are not allowed by the standards

This was described more directly in the obsolete RFC 2818, 3.1:

Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

In the current Internet Standard this still exists, but it is inherited from another (proposed) standard.

The HTTP Semantics RFC 9110 defines the rules for https Certificate Verification in section 4.3.4:

In general, a client MUST verify the service identity using the verification process defined in Section 6 of [RFC6125]. The client MUST construct a reference identity from the service's host: if the host is a literal IP address (Section 4.3.5), the reference identity is an IP-ID, otherwise the host is a name and the reference identity is a DNS-ID.

The same limitation now comes from the RFC 6125, 6.4.3 (Checking of Wildcard Certificates):

If a client matches the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character *, the following rules apply:

1. The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label (e.g., do not match bar.*.example.net).

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

The second rule prevents you from using multi-level wildcard certificates, and the first rule tells that you could not have www.*.example.com certificates, either. (For completeness, there is a third rule, too, but I did not cite it because it does not relate to this question.)

Wildcards in DNS matches multiple levels

As you have noticed, wildcards in DNS, as defined in RFC 1034, 4.3.3, matches multiple levels.

-- Another way to look at this is that the * label always matches at least one whole label and sometimes more, but always whole labels.

Wildcard RRs do not apply:

• When the query is in another zone. That is, delegation cancels the wildcard defaults.

• When the query name or a name between the wildcard domain and the query name is know to exist. For example, if a wildcard RR has an owner name of *.X, and the zone also contains RRs attached to B.X, the wildcards would apply to queries for name Z.X (presuming there is no explicit information for Z.X), but not to B.X, A.B.X, or X.

(As this specification was not that clear and, thus, were implemented in multiple ways, RFC 4592 updates it with clarifications and examples that are not meaningful to cite in this context.)

There is not really a way around this other than not using wildcards at all. This indeed means that you would have to either

1. accept the fact that those TLS errors for hostnames with additional labels will be shown when using wildcards in DNS or

2. stop using the wildcards and register every subdomain individually in the DNS.