A wildcard such as *.example.com covers a single leftmost label, such as shop.example.com. Check the actual certificate's subject alternative names before assuming that the base domain or deeper subdomains are included.
IN THIS ARTICLE
01 Map the required names
| Requested name | Covered by *.example.com alone? |
|---|---|
| www.example.com | Yes |
| shop.example.com | Yes |
| example.com | No, add or verify separate coverage |
| login.shop.example.com | No, a deeper name |
| example.net | No, a different domain |
02 Choose and verify coverage
- List the hostnames used by visitors, mail clients, integrations and redirects. Include names that will remain active after migration.
- Compare the list with the proposed certificate's exact names and wildcard levels. Confirm any base-domain inclusion in the order instead of treating it as automatic.
- Choose a supported validation method for the wildcard, commonly DNS validation. Check who can maintain the required challenge or renewal automation.
- Install on authorised endpoints and test each representative name. A valid wildcard does not create DNS records or configure a website for a new subdomain.
- Document where its private key is held. Consider separate keys or certificates where different teams or systems have different security boundaries.
Common questions
Can I use two asterisks for every depth?
Do not assume arbitrary wildcard patterns are valid. Public TLS identity matching restricts wildcard placement. Use explicit names or the appropriate separate wildcard level.
What happens if one copied key is exposed?
Every certificate and endpoint relying on that key requires assessment. A convenient shared wildcard can increase the work needed during replacement.
Does wildcard HTTPS secure all other protocols?
Each service must support and present the certificate correctly. DNS coverage alone does not install it in mail or other server software.