The asterisk in a wildcard certificate looks generous: surely it covers everything beneath the domain? In ordinary TLS hostname matching, it has a more specific job. It replaces one DNS label at the level where it appears.
DigiCert’s wildcard certificate explanation describes that single-level scope. A certificate may contain several names, so always inspect its Subject Alternative Name entries rather than drawing conclusions from a product name.
| Certificate name | Example hostname | Matched by that name? |
|---|---|---|
| *.example.com | shop.example.com | Yes |
| *.example.com | example.com | No |
| *.example.com | help.shop.example.com | No |
The bare domain can be covered by an additional entry on the same certificate. A deeper hostname may likewise need its own entry or an appropriate wildcard at that level. The table describes the wildcard name alone, not every name a particular certificate package might include.
Check names before changing DNS
Suppose you move a help site from help.example.com to help.shop.example.com. The new DNS record may resolve correctly while the existing wildcard no longer matches the hostname. A browser warning in that situation is not proof that DNS failed.
List the hostnames the site actually serves, inspect the certificate presented for each, and compare them with the certificate’s names and validity period. Also confirm that the server is selecting the intended certificate. A valid certificate sitting elsewhere on the server does not help the connection being tested.
Do not ask visitors to bypass the warning. Correct the hostname coverage and server configuration, then test the public address again. The small distinction between one label and an entire domain tree prevents a surprisingly common misunderstanding.