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.

Best practices
Secure network connections and certificate management

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.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting