Let's Encrypt for Subdomains: Single-Domain, SAN, and Wildcard Strategies Compared

Overview

Here is the practical takeaway: there is no universally best certificate strategy for subdomains. The right choice depends on how many hostnames you manage, how often they change, who controls DNS, and how much operational simplicity you want.

For most teams, the decision comes down to three patterns:

• Single-domain certificates: one certificate per hostname, or one small certificate for a tightly related pair such as example.com and www.example.com.
• SAN certificates: one certificate covering several specific hostnames, sometimes called multi-domain certificates, because the Subject Alternative Name list includes multiple names.
• Wildcard certificates: one certificate covering all first-level subdomains under a domain, such as *.example.com.

All three can be valid ways to secure subdomains with HTTPS. The difference is not whether they work, but how they behave operationally.

A useful way to think about the choice is this:

• Single-domain favors isolation and clear ownership.
• SAN favors bundling a known set of names.
• Wildcard favors flexibility for fast-changing subdomain inventories.

None of these patterns is automatically more “secure” in every environment. Security depends on private key handling, issuance controls, automation quality, and whether your certificate scope matches the systems that need it. A broad certificate can be convenient, but it can also expand the blast radius if a key is exposed. A narrow certificate can reduce that risk, but it may create more moving parts to renew and monitor.

How to compare options

If you are deciding between SAN certificate vs wildcard, or between a wildcard and several smaller certificates, compare the options against the realities of your environment rather than abstract preference.

1. Count your hostnames and map their growth pattern

Start with the names you use today and the names you are likely to add in the next year. Many teams underestimate this step. Document the apex domain, www, application subdomains, APIs, admin panels, regional sites, and internal-but-publicly-routed services. Then note whether new subdomains appear occasionally or constantly.

If your hostname list is stable and predictable, SAN certificates are easier to justify. If subdomains are created often, wildcard coverage may be easier to maintain. If hostnames map cleanly to separate apps or teams, single-domain certificates often remain the cleanest model.

2. Check which ACME validation methods you can support

This is often the deciding factor in a Let’s Encrypt setup.

• HTTP-01 works well when the web server for each hostname is reachable on the public internet and you can place the challenge response correctly.
• DNS-01 is required for wildcard issuance and is also useful for environments where HTTP validation is awkward.

If your DNS provider supports reliable API-based automation, wildcard issuance becomes much more practical. If DNS automation is limited or tightly controlled, issuing individual certificates with HTTP validation may be simpler. Before choosing a wildcard-heavy approach, make sure your team can actually automate the required DNS challenge workflow. If you also use CAA records, confirm they allow issuance as intended. For that topic, see CAA Records for Let's Encrypt: What They Do and How to Configure Them.

3. Consider key scope and blast radius

Certificate scope affects risk. A wildcard certificate used across many servers can become a high-value secret. If the same private key is copied to every node, a compromise on one host may affect all covered subdomains. That does not mean wildcard certificates are a bad idea; it means they need deliberate key management.

Single-domain certificates reduce shared scope. SAN certificates sit in the middle: broader than a single-name certificate, narrower than a wildcard, but still capable of over-grouping unrelated services if used casually.

4. Review renewal complexity and failure modes

A certificate strategy is only as good as its renewal path. Ask:

• Can we automate issuance and renewal without manual steps?
• Who gets alerted when renewal fails?
• Does one failed renewal affect one hostname or many?
• Will service owners notice a broken DNS challenge or expired token in time?

With single-domain certificates, failures are more isolated but potentially more numerous. With SAN and wildcard patterns, there may be fewer certificates overall, but one failure can affect more traffic. Monitoring matters either way. A good companion resource is Let's Encrypt Expiry Monitoring: Best Tools, Alerts, and Dashboard Options.

5. Match the certificate pattern to your deployment model

Think about where TLS terminates:

• On one reverse proxy for everything
• On separate app servers
• Inside containers or per-environment ingress controllers
• At a CDN or edge platform with origin TLS behind it

If one edge proxy handles all public traffic, a SAN or wildcard certificate may fit naturally. If each service deploys independently, issuing separate certificates may align better with ownership and release workflows.

Feature-by-feature breakdown

This section compares the three strategies directly so you can see where each one helps and where it creates tradeoffs.

Single-domain certificates

What they are: A certificate covers one hostname, or a tightly controlled pair such as example.com plus www.example.com.

Best qualities:

• Strong separation between services
• Smaller blast radius if a private key is exposed
• Clear ownership by app, team, or environment
• Straightforward troubleshooting because each cert maps cleanly to a hostname

Main drawbacks:

• More certificates to issue and track
• More opportunities for missed renewals if automation is inconsistent
• Can feel repetitive in environments with many small subdomains

Where they work well: production applications with different owners, environments where each service has its own deployment pipeline, and organizations that prefer isolation over consolidation.

Operational note: single-domain issuance is often easier when HTTP validation is already available on each host. It can also be simpler during migrations because each hostname can be moved and verified independently. If that is relevant, see How to Migrate a Website to a New Host Without Breaking SSL or DNS.

SAN certificates

What they are: One certificate lists several specific hostnames, such as example.com, www.example.com, app.example.com, and api.example.com.

Best qualities:

• Good fit for a known, finite set of names
• Fewer certificates to manage than a strictly single-domain model
• Works well for related services fronted by the same load balancer or proxy

Main drawbacks:

• Every hostname change may require reissuing the certificate
• One certificate can become a catch-all bundle that grows harder to maintain
• A renewal problem can affect several names at once

Where they work well: small site groups, classic web stacks with one frontend proxy, or organizations that know exactly which hostnames belong together.

Operational note: SAN certificates are often attractive early on because they reduce certificate count without introducing wildcard DNS validation. The catch is that they age poorly if your hostname inventory changes often. A SAN list that starts clean can become messy as new apps and temporary subdomains are added.

Wildcard certificates

What they are: A certificate covers all first-level subdomains of a domain, such as *.example.com. Note that this does not automatically cover the apex domain example.com, so many deployments include both names if needed.

Best qualities:

• Excellent for dynamic or fast-growing subdomain use
• Convenient when new subdomains appear regularly
• Reduces the need to reissue certificates every time another first-level subdomain is created

Main drawbacks:

• Requires DNS-01 validation for Let’s Encrypt wildcard issuance
• Broader key scope can increase risk if distributed too widely
• May encourage over-sharing one certificate across unrelated systems
• Does not cover deeper levels like x.y.example.com unless separately planned

Where they work well: multi-tenant apps, preview deployments, platforms that create many customer subdomains, and environments with strong DNS automation.

Operational note: wildcard certificates are usually strongest when paired with disciplined secret distribution. If many machines use one wildcard certificate, treat that private key as a critical secret and review where it is stored, copied, and renewed.

Comparison summary

• Need maximum isolation? Choose single-domain certificates.
• Need one cert for a small known set of hostnames? Choose SAN.
• Need flexible SSL for multiple subdomains that change often? Choose wildcard.

The best certificate strategy is often not one pattern everywhere. Many mature environments use a mix: a wildcard for ephemeral subdomains, single-domain certificates for high-value applications, and a small SAN certificate for the apex plus www.

Best fit by scenario

If you want a direct recommendation, start here. These scenarios reflect common real-world patterns rather than idealized diagrams.

Scenario 1: Small business site with example.com, www, and one app subdomain

A small SAN certificate can be reasonable if the hostnames are stable and managed together. If the app is operationally distinct or has different deployment timing, separate certificates may be cleaner.

Good default: one cert for apex plus www, and a separate cert for the app if it behaves like its own service.

Scenario 2: SaaS platform with many customer subdomains

This is where wildcard certificates often make sense. If new customer subdomains are created frequently, a wildcard reduces issuance churn. The key requirement is mature DNS automation and careful certificate secret handling.

Good default: wildcard for customer-facing subdomains, plus separate certificates for especially sensitive admin or internal-facing services if you want narrower trust boundaries.

Scenario 3: Multiple independent services owned by different teams

Single-domain certificates usually age better here. Team boundaries, deployment pipelines, and rollback procedures stay clearer when each service owns its own certificate lifecycle.

Good default: separate certs per service, even if a shared proxy could technically combine them.

Scenario 4: One reverse proxy serving several fixed hostnames

If the hostname set is stable, a SAN certificate can be efficient and easy to reason about. This is common for a modest stack with a marketing site, API, and dashboard behind one ingress point.

Good default: SAN certificate, reviewed periodically to avoid uncontrolled sprawl.

Scenario 5: Staging, previews, and temporary environments

Wildcard certificates are often the easiest option for fast-changing environments. Temporary hostnames can be brought up without editing the SAN list every time. Still, if staging has weaker access controls, be careful about reusing production secrets indiscriminately.

Good default: wildcard for non-production dynamic environments, but keep production certificate handling separate where possible.

Scenario 6: Migration or platform transition

During a migration, simpler can be safer. Many teams benefit from using smaller, more explicit certificates while moving DNS, web server config, or hosting. Once the new environment stabilizes, then consolidate if needed.

Good default: prefer explicit single-domain or small SAN certificates during the move; optimize later.

After issuance, do not forget the browser-facing pieces of HTTPS. You may still need redirect rules, content fixes, and web server tuning. Helpful follow-up guides include How to Force HTTPS Safely: Redirect Rules for Nginx, Apache, and Cloud Platforms and Mixed Content Errors After Installing Let's Encrypt: Causes and Fixes.

When to revisit

Your certificate strategy should be reviewed whenever the shape of your hostname inventory changes. This is not a one-time architecture decision. Revisit it when the assumptions behind your current setup are no longer true.

Review the plan when:

• You add many new subdomains or stop using old ones
• You switch DNS providers or gain API-based DNS automation
• You move from shared hosting to a VPS, container platform, or managed ingress layer
• You centralize traffic behind a proxy or split one stack into multiple services
• You change ownership boundaries between teams
• You experience a renewal failure that reveals weak monitoring or unclear responsibilities
• You introduce stricter secret management controls and want to reduce shared private keys

Use this practical review checklist:

1. List every public hostname in use today.
2. Mark which names are stable, temporary, customer-generated, or team-owned.
3. Note whether each hostname can use HTTP validation, DNS validation, or either.
4. Map where TLS terminates and where private keys are stored.
5. Check whether any certificate currently groups unrelated systems together.
6. Verify renewal automation and test that it actually works.
7. Confirm alerts go to people who can act on them.
8. Reissue and simplify where the current pattern no longer matches reality.

If renewals are part of your pain point, review How to Renew Let's Encrypt Certificates Automatically and Verify It Actually Works. If your tooling choices are part of the problem, Certbot Alternatives for 2026: When to Use acme.sh, Dehydrated, Win-ACME, or Caddy can help you evaluate different ACME clients.

Final recommendation: choose the smallest certificate scope that still fits your operational reality. Use single-domain certificates when isolation matters, SAN certificates when the hostname set is known and stable, and wildcard certificates when subdomains are dynamic and DNS automation is solid. For many teams, the best answer is a hybrid model rather than a single rule for everything.

That is what makes this a planning decision, not just a certificate request. The pattern you choose should reduce failure points, match how your infrastructure is actually run, and leave room to adapt as your site structure changes.