Certificates & Site Ops
Wildcard vs Single-Domain Certificates
Compare wildcard and single-domain TLS certificates by hostname coverage, DNS validation, renewal method, key exposure, and operational blast radius risk.
In brief
What it is: Wildcard and single-domain certificates solve different scope and operational problems even when they both seem to “cover the site.”
Why it matters: The right choice depends on renewal method, DNS control, blast radius, and how many hosts you actually operate.
Worth knowing: Match certificate scope to the hostnames you operate and the issuance and rotation process you can maintain.
Wildcard certificates and single-domain certificates solve different operational problems. One is convenient when many subdomains follow the same trust boundary. The other is simpler and tighter when you only need to secure a specific hostname or a short list of names.
The best choice depends on how many subdomains you actually run, how you validate ownership, and how comfortable you are managing the blast radius if one private key needs to be rotated.
How the choices differ
- Single-domain and SAN certificates are often simpler to reason about when only a few names are involved.
- Wildcard certificates can reduce certificate sprawl, but they require DNS-based validation with Let’s Encrypt.
- Broader certificate coverage can increase operational convenience and key-management risk at the same time.
| Question | Single-domain / SAN | Wildcard |
|---|---|---|
| Validation options with Let’s Encrypt | Often HTTP-01 or DNS-01 | DNS-01 required |
| Best for | One site or a small fixed hostname set | Many subdomains under one domain |
| Operational blast radius | Smaller | Potentially broader if one key is reused widely |
Where people misclassify the problem
- Choosing wildcard for convenience when only one or two hostnames exist.
- Forgetting that wildcard issuance requires DNS-01 validation with Let’s Encrypt.
- Using the same private key too broadly without clear inventory and rotation procedures.
What readers still ask
Does a wildcard cover the root domain automatically?
Verify the exact names in the certificate request and issued SAN list, because wildcard coverage follows specific label rules.
Is wildcard always more professional?
It is simply a different operational tradeoff.
Change one thing, then verify
- Inspect the current artifact or endpoint output before making changes.
- Change one variable at a time so a failed verification has a narrow cause.
- Keep the rollback value, expiry, and verification command in the same runbook entry.
1. current deployed artifact
2. single config or key change
3. verify endpoint/client behavior
4. record rollback and expiry details
