Does every subdomain need a separate TLS certificate?
Choose separate, wildcard, or multi-domain certificates, with the SAN matching rules and renewal trade-offs that determine coverage.
No. Several subdomains can share a certificate if its Subject Alternative Name (SAN) entries cover every hostname clients use. A wildcard such as *.example.com covers names like app.example.com and api.example.com; a multi-domain certificate can list specific names across different domains. Separate certificates remain an option even when a shared certificate would work.
Compare the options
| Certificate arrangement | Coverage | Typical use |
|---|---|---|
| One explicitly named host | The name listed in SAN; www is not added automatically |
A single endpoint or separately managed services |
| Wildcard SAN | One label beneath a suffix, such as *.example.com |
Many sibling subdomains, including dynamically created names |
| Multiple SAN entries | The exact names and wildcards listed | Several known domains sharing a certificate lifecycle |
A wildcard is itself a kind of SAN entry; these are practical deployment categories, not mutually exclusive certificate formats.
Understand wildcard limits
*.example.com matches a.example.com, but neither example.com nor a.b.example.com. Include the apex example.com as another SAN when needed. A deeper family of names requires coverage such as *.b.example.com.
For Let's Encrypt, wildcard issuance requires DNS-01 validation. HTTP-01 cannot issue wildcard certificates. A DNS provider API and a compatible ACME client make automated renewal practical; limit the DNS credentials to the permissions required. Other issuers have their own validation policies. See Let's Encrypt challenge types.
Choose a lifecycle you can operate
For three to five stable subdomains, either separate certificates or one SAN certificate is straightforward. Let's Encrypt does not charge for issuance, but renewal automation, deployment, and monitoring still need maintenance.
For a multi-tenant service using {tenant}.example.com, a wildcard avoids reissuance for every new sibling hostname. Automated per-host issuance can also work within the CA's limits and your deployment capacity.
For unrelated names such as example.com, example.net, and app.foo.com, use explicit SAN entries or separate certificates. A single wildcard cannot span unrelated domains.
Sharing one certificate across servers also shares its private key. A compromised key can affect all covered names. Account for the security of key distribution and for the coupling between renewal schedules.
After renewal, verify the certificate served by each entry point. Guance SSL tests can check a hostname and port and evaluate remaining certificate lifetime. Include the actual service endpoints; a renewed file on disk does not prove every server loaded it.
Common questions
Does a wildcard cover the root domain?
No. Add example.com explicitly alongside *.example.com, or use a separate certificate for it.
Can Let's Encrypt issue wildcards automatically?
Yes, with DNS-01. Certbot DNS plugins or another compatible ACME client can automate the TXT-record updates when your provider supports the required API.
How many names can one certificate contain?
The issuing CA's policy sets the limit. Check its current limits before designing around a large SAN list. Adding or removing names changes the certificate and requires reissuance; a wildcard is often easier when sibling names change frequently.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan