Let's Encrypt Wildcard Certificates: DNS-01 Setup, Limits, and Renewal Tips

Overview

If you need one certificate to cover many subdomains under the same base domain, a wildcard certificate is often the cleanest option. A certificate for *.example.com can secure hosts such as app.example.com, api.example.com, and www.example.com. It does not cover the apex domain itself, so in practice many deployments request both example.com and *.example.com in the same certificate.

With Let's Encrypt, wildcard issuance relies on the DNS-01 challenge. That means you prove control of the domain by placing a TXT record under _acme-challenge in DNS. You cannot use the HTTP challenge for a wildcard. That single requirement changes the entire workflow: instead of only configuring your web server, you also need reliable control over your DNS provider, propagation timing, and renewal automation.

For small teams, the main decision is not whether wildcard certificates work. They do. The real question is whether a wildcard is the right fit for your environment. It is usually a good fit when you manage many subdomains, regularly add new subdomains, or want to avoid issuing separate certificates for every host. It is often a poor fit when DNS automation is unavailable, the DNS provider is unreliable, or you want tighter isolation between services.

Before you proceed, keep three ground rules in mind:

• Wildcard covers one label only. *.example.com covers blog.example.com but not deep.blog.example.com.
• The apex is separate. If you need HTTPS on example.com, include it explicitly in the certificate request.
• Renewal matters more than issuance. A manual DNS process may be acceptable for testing, but it becomes risky in production if nobody owns the recurring renewal task.

If you are still choosing tooling, it helps to compare ACME clients before standardizing on one. See Best Let's Encrypt Clients Compared: Certbot, acme.sh, Lego, Caddy, and More for a practical client overview.

Checklist by scenario

Use the scenario below that matches your setup. The goal is not to memorize commands but to make sure the operational pieces are in place before you request a production certificate.

Scenario 1: Single server, manual DNS update

This is the simplest starting point and the least scalable long term. It works best for one-off issuance, lab systems, or low-change environments where you can tolerate a hands-on renewal process.

• Confirm you control the DNS zone for the domain.
• Choose an ACME client that supports manual DNS-01 prompts.
• Request a certificate for both example.com and *.example.com if you need both.
• When prompted, add the TXT record at _acme-challenge.example.com.
• Wait for DNS propagation before continuing. If your provider is slow, give it more time than you think you need.
• Verify the TXT record from an external resolver before finalizing the challenge.
• Install the certificate in Nginx, Apache, a reverse proxy, or your application platform.
• Test HTTPS and, if appropriate, configure an HTTP-to-HTTPS redirect.
• Document the exact renewal steps, not just the issuance steps.

This approach is fine for learning the process, but it creates an avoidable renewal dependency on a person being available at the right time.

Scenario 2: VPS or dedicated server with DNS API automation

This is usually the best long-term setup for developers and admins running their own infrastructure. DNS API automation removes most of the friction from renewals and reduces the chance of missed certificates.

• Check whether your DNS provider offers an API suitable for ACME DNS-01 automation.
• Create a narrowly scoped API token if your provider supports permission limits.
• Store the token securely with file permissions or a secret management method appropriate to your stack.
• Select an ACME client or plugin that supports your DNS provider.
• Run a staging or test issuance first to confirm the DNS update flow.
• Request the production certificate only after staging succeeds.
• Configure automatic renewal on a timer or scheduled job.
• Reload the web server or proxy after successful renewal.
• Add monitoring so certificate age or expiry does not go unnoticed.

Automation is not just convenient. It is the most practical way to make wildcard certificates sustainable on a VPS. If you are deploying this for several services, also think about whether one wildcard private key should be shared across systems or whether service-level separation is safer for your risk model.

Scenario 3: Shared hosting or managed panel environment

Some hosting panels simplify Let's Encrypt issuance, but wildcard support varies. The key issue is whether the platform can perform the DNS-01 challenge, either through panel integration or through your external DNS provider.

• Check if your control panel supports wildcard certificates specifically, not just standard single-host certificates.
• Verify whether DNS is managed in the same panel or through a separate provider.
• If external DNS is involved, confirm the panel can update TXT records automatically or guide you through manual validation.
• Request a combined certificate for apex and wildcard if your site uses both.
• Test certificate deployment on all relevant hostnames after issuance.
• Confirm that renewal notifications are enabled and visible to the right administrator.

On shared hosting, the main risk is assuming the platform handles everything. Some panels do, some do not, and some support automation only when DNS is hosted inside the same ecosystem.

Scenario 4: Multiple apps behind one reverse proxy

This is one of the strongest use cases for a wildcard certificate. A reverse proxy can terminate TLS for many subdomains while using a single certificate bundle.

• Inventory every hostname the proxy will serve.
• Decide whether the proxy will use a wildcard certificate or whether certain services deserve dedicated certificates.
• Request example.com plus *.example.com if the root domain is also proxied.
• Keep certificate and key files in a consistent path managed by automation.
• Test SNI behavior if you serve a mix of wildcard and non-wildcard certificates.
• Plan how renewed certificates are reloaded without dropping active connections.

Where teams get into trouble here is not issuance. It is unclear ownership. Someone needs to own the ACME client, the DNS credentials, the reload action, and the expiry alerts.

Scenario 5: Container or ephemeral deployment

Wildcard certificates can work well in container environments, but the certificate lifecycle should not depend on short-lived application containers.

• Run ACME issuance in a persistent control container, host process, or external certificate manager.
• Avoid storing the only copy of certificates inside ephemeral application containers.
• Persist keys and certificates in a mounted volume or external secret store.
• Use DNS API automation rather than any process that depends on a live web container.
• Test replacement and reload behavior during routine deployments.

If your infrastructure is dynamic, the certificate workflow must be more stable than the workloads it secures.

What to double-check

Most wildcard certificate issues come from a small set of operational details. Before issuing or renewing, verify the following items.

1. The record name is exactly right

The TXT record normally belongs at _acme-challenge.example.com. In many DNS panels, the interface automatically appends the zone name. In others, you must enter the full name. A surprising number of failures come from entering _acme-challenge.example.com.example.com or placing the record in the wrong zone.

2. You are validating the correct domain set

If the certificate request includes both example.com and *.example.com, make sure your ACME client handles the challenge sequence correctly. Depending on the client, you may see one or more TXT values during validation. Follow the client output carefully.

3. DNS propagation is truly complete

Seeing the TXT record in your own dashboard is not enough. Query it from outside your local network, ideally against public resolvers, before concluding that validation should pass. If you routinely troubleshoot DNS, a propagation workflow is worth standardizing across the team. A simple dns propagation checker guide mindset helps here: confirm authoritative visibility first, then public resolver visibility, then proceed.

4. Your API token can only do what it needs to do

When using automated DNS-01, avoid broad account credentials where a limited DNS-edit token is available. Even in a small environment, wildcard automation usually means storing credentials on a server. Narrow permissions reduce risk if that server is compromised.

5. The private key location and permissions are sane

A wildcard certificate often becomes a shared dependency across several services. Treat the private key accordingly. Restrict read access, decide whether one key will be reused across hosts, and avoid ad hoc copying between servers without a clear inventory.

6. Your web server reload step actually happens

A renewed certificate on disk is not the same as a renewed certificate in memory. Make sure your scheduled renewal process includes a safe reload or restart step for Nginx, Apache, HAProxy, Traefik, Caddy, or whichever component terminates TLS. If you still need deployment guidance after issuance, the related topics of nginx ssl configuration and apache ssl configuration are worth documenting in your runbook.

7. You are aware of issuance limits before scaling up

Let's Encrypt rate limits are part of normal operational planning. If you are testing repeatedly, changing clients, or issuing many related certificates, understand the limits before you hit them in production. For a deeper operational view, see Let's Encrypt Rate Limits Explained: Current Limits, Common Errors, and Safe Workarounds.

Common mistakes

This section is the short list to review before every change window.

• Assuming a wildcard covers the apex domain. It does not. If you need example.com, request it explicitly.
• Using wildcard where separate certificates are safer. A single wildcard key can become a larger blast radius if copied widely across systems.
• Choosing manual DNS for production without a renewal owner. Manual validation is easy to start and easy to forget.
• Ignoring split DNS or delegated zones. Internal and external DNS differences can confuse validation if the wrong zone is updated.
• Leaving stale TXT records behind. Old challenge records may not always break issuance, but they create clutter and confusion during future troubleshooting.
• Skipping staging tests. When changing clients, DNS providers, or automation code, test with a non-production workflow first.
• Not monitoring expiry. Even fully automated renewals deserve alerts. Automation failures are often silent until they are urgent.
• Forgetting service reloads after renewal. This is one of the most common reasons teams believe renewal succeeded when browsers still show the old certificate.
• Overlooking CNAME-based challenge delegation. In some setups, delegating _acme-challenge to another zone can simplify automation, but only if it is documented clearly and maintained carefully.

A final mistake is treating certificate issuance as an isolated task. Wildcard SSL setup is part DNS workflow, part secret management, part server configuration, and part operational monitoring. If any one of those pieces is weak, the whole system becomes fragile.

When to revisit

The best time to revisit your wildcard certificate setup is before it becomes urgent. Use the checklist below as a recurring maintenance habit.

• Before seasonal planning cycles: review certificate inventory, expiry windows, API tokens, and DNS ownership.
• When workflows or tools change: if you switch DNS providers, control panels, reverse proxies, or ACME clients, retest issuance and renewal end to end.
• When new subdomains are added rapidly: confirm the wildcard still fits the environment and that sensitive services are not inheriting trust boundaries you no longer want.
• After migrations: if you move hosting, adopt a CDN, or change edge termination, verify which system now owns the certificate lifecycle.
• When team ownership changes: update runbooks, alerts, and access controls so renewals do not depend on one person.

A practical recurring review looks like this:

1. List every certificate in use, including wildcard and non-wildcard certificates.
2. Confirm which DNS provider and zone each certificate depends on.
3. Check whether renewal is manual, scheduled, or delegated to a platform.
4. Test one full non-production issuance or renewal path after major DNS or hosting changes.
5. Verify expiry monitoring and web server reload hooks.
6. Remove unused tokens, stale TXT guidance, and outdated runbook steps.

If you are still deciding which ACME tooling best fits your environment, revisit Best Let's Encrypt Clients Compared: Certbot, acme.sh, Lego, Caddy, and More. The right client can make the difference between a reliable renew wildcard certificate workflow and one that only works when a specific admin is available.

The simplest rule is this: issue once, automate early, monitor always, and review the setup whenever DNS, hosting, or team ownership changes. That is what keeps a Let's Encrypt wildcard certificate routine instead of risky.