Wildcard SSL certificates cover one level only, and why

A wildcard SSL certificate for *.example.com covers shop.example.com and api.example.com. It does not cover eu.shop.example.com, which sits one level deeper, and it does not cover example.com itself unless that name is listed separately in the same certificate.

The belief that a wildcard covers everything below a domain is the most common misunderstanding in this subject, and it produces a specific, avoidable outage. The reason it is wrong is mechanical rather than a matter of policy.

The mechanism behind the limit

Name matching compares labels, not strings.

A hostname is a sequence of labels separated by dots. The wildcard character stands for exactly one label in exactly one position, the leftmost, and matching proceeds label by label.

certificate:  *  . example . com
                 │
candidate:   shop . example . com     ✅ one label in the wildcard position
candidate: eu.shop . example . com    ❌ two labels where one is allowed
candidate:        example . com       ❌ nothing in the wildcard position

So *.example.com matches names with exactly one additional label. A name with two extra labels has no way to be matched by a single wildcard, and a name with none does not either, because the wildcard position must be filled by something.

That is the whole rule. It is defined in the specification governing how clients verify names in certificates, and every browser implements it the same way, which is why there is no client-side setting or server configuration that changes the outcome.

What this means in practice

The one-level rule has three practical consequences.

• The bare domain needs listing separately

  A certificate for *.example.com does not secure example.com. A certificate authority routinely includes both when asked, and if it was not asked for, the shorter name fails while every subdomain works. Both names belong in the list when you generate the CSR, since adding one after issuance means a new certificate.

• Deeper names need their own coverage

  If you use two-level subdomains, each level needs a wildcard of its own, or the names need listing explicitly. A wildcard at the level that needs it, such as *.shop.example.com, covers that level and no further.

• Multiple wildcards do not nest

  Holding *.example.com does not extend to anything below the names it matches. Coverage is per level, always.

The symptom of getting this wrong is a name mismatch error (ERR_CERT_COMMON_NAME_INVALID in Chrome) appearing on precisely the names you assumed were covered.

SSL for a subdomain

A subdomain needs a certificate covering that exact name, and there are three ways to get one.

Issue a certificate for the single name, which is the simplest option for one or two subdomains. Include the name in a certificate covering several names explicitly, described on SAN certificates. Or use a wildcard, which covers every name at that one level without listing them.

Which is right depends on how many names there are and how often the set changes, discussed below. Nothing about a subdomain requires special treatment beyond making sure the name is covered.

Issuing a wildcard

One practical constraint distinguishes wildcards from ordinary certificates: proving control of a wildcard requires the DNS-based validation method (the ACME DNS-01 challenge, when issuance is automated) rather than the file-based one (HTTP-01).

You cannot place a verification file at every possible name a wildcard would cover, because the set is unbounded. Publishing a DNS record for the domain demonstrates control of the whole level at once, which is what the wildcard claims.

The practical implication is that automated issuance of wildcards requires your DNS to be updatable by the issuing process, which is a different integration from ordinary automated issuance. Once issued, a wildcard is installed like any other certificate, intermediates included: a server that omits them breaks the HTTPS certificate chain for fresh visitors.

Wildcard versus listing names

The comparison that decides the choice, and it is about change rather than count.

• A wildcard suits an environment where subdomains are created regularly and unpredictably: per-customer names, per-environment names, anything generated. Coverage exists before the name does, which removes issuance from the path of creating a subdomain.

• An explicit list suits a stable set of names, particularly when they span different levels or different domains, which a wildcard cannot do at all. It also limits exposure, discussed next.

• The cost of a wildcard is concentration. One private key covers every name at that level, so a compromise of that key affects all of them, and replacing it means replacing coverage for everything at once. A list of names issued separately can be replaced piecemeal.

For most organisations the convenience wins, because subdomain proliferation is a real operational problem while key compromise is a rare one.

Where the myth comes from

The belief is reasonable rather than careless.

The wildcard character means "anything" in most contexts a technical person meets: file matching, search patterns, and configuration syntax generally treat it as matching any amount of anything. Certificates are the unusual case, where it matches exactly one component of a structured name.

The DNS side reinforces the confusion, because a wildcard record behaves differently from a wildcard certificate, and the two are frequently configured in the same afternoon. Their rules are not the same, and assuming that what holds for one holds for the other is where most of this starts. The record side belongs to the DNS layer.

And the failure is quiet at first. A wildcard does cover the names people test with, so the setup appears correct until someone reaches a deeper name, which may be weeks later and in a part of the system nobody associated with certificates.

The defence is a habit rather than knowledge: list the names that actually resolve, and check each one against what the certificate covers. Reasoning about what the wildcard ought to include is where the mistake lives; the list does not have opinions.

FAQ