Use per-host certificates by default, and a wildcard only where many short lived hosts make individual issuance impractical. A wildcard is convenient, but one private key then proves identity for every name under it, so a single leak affects all of them.
What a wildcard actually matches
RFC 9525 sets the matching rules. A presented identifier may contain only one wildcard, and it must be the entire left-most label. A wildcard matches exactly one label. So *.example.com covers api.example.com but not example.com itself and not a.b.example.com. Invalid wildcard forms are ignored by clients. You can list the bare name and the wildcard together on one certificate.
The tradeoffs
- Blast radius if the key leaks: a wildcard exposes every host under the name, a per-host certificate exposes one.
- Issuance effort: a wildcard is one certificate, per-host needs automation for many.
- Validation: Let's Encrypt requires the DNS challenge for wildcards, while per-host can use HTTP, DNS or TLS ALPN.
- Transparency logs: a wildcard hides individual host names, per-host reveals each one.
- Rotation and revocation: a wildcard touches every system holding the key, per-host stays local.
The Let's Encrypt FAQ confirms that wildcard issuance requires the DNS challenge. That means the system that renews it needs DNS write access.
One more practical point: a wildcard and per-host certificates can coexist. Many teams keep one wildcard for disposable preview hosts and individual certificates for anything that holds customer data, which gets most of the convenience with a smaller blast radius.
When a wildcard fits
- Many hosts that appear and disappear quickly, such as per-customer or per-branch preview environments.
- A load balancer in front that terminates TLS for all names with one key held in one place.
- You want to avoid listing internal host names in public transparency logs. Weigh this against the cost of hiding your naming from your own monitoring.
When per-host is better
- Hosts run on different teams, clouds or vendors. Sharing one key across them spreads it far.
- Any host handles sensitive data and deserves its own key.
- You already have ACME automation, so volume is not a barrier.
If you use a wildcard, reduce the risk
- Generate the key where it will live and never email it or put it in chat.
- Keep it on as few systems as possible.
- Use a separate wildcard per environment, so a staging leak does not touch production.
- Restrict DNS credentials to the validation record.
- Add CAA records. See CAA records explained.
- Plan how you would rotate it in an hour.
Quick check
Does a wildcard cover the apex domain?
Not by itself. The wildcard matches one label to the left of the domain. Add the bare domain as a second name on the certificate.
Does a wildcard cover a name two levels down?
No. RFC 9525 says it matches exactly one label.
Sources
Last reviewed: 19 October 2026.
