How do wildcard certificates and DNS-01 validation work?
A wildcard certificate can cover names directly beneath a domain, such as app.example.com for *.example.com. It does not automatically cover the bare example.com name or multiple subdomain levels. Let’s Encrypt wildcard issuance uses DNS-01 validation, which proves control through a specific DNS TXT record.
Before you start
- Control of the authoritative DNS zone.
- An approved DNS plugin or validation workflow for the actual DNS provider.
Instructions
1. Define the required certificate names
List the exact hostnames before requesting a certificate. Include the bare domain separately if it is needed. Avoid spreading one wildcard private key across unrelated servers when separate certificates fit the access design better.
2. Inspect the validation record
The ACME client provides the required token. The following query only reads the record; it does not create the token or establish that you have completed validation.
dig TXT _acme-challenge.example.com +shortReads the TXT record normally used to validate example.com and its wildcard.
3. Design automatic renewal
Use the official DNS plugin for the provider and narrowly scoped credentials stored outside the webroot with restricted permissions. An interactive manual TXT update is not an unattended renewal mechanism. Where supported, delegation of the challenge name can separate validation permissions from the main zone.
Check the result
- The issued certificate contains the intended wildcard and any additional required names.
- A targeted renewal test proves that DNS updates and cleanup can run through the approved automation.
Troubleshooting
- The TXT value appears locally but validation fails
- Query the authoritative nameservers and check delegation and cache lifetimes. Confirm the current challenge token rather than reusing an old value.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.