Certbot wildcard certificates with DNS challenge

Certbot wildcards require DNS-01 with API credentials—HTTP-01 cannot validate *.example.com.

When this happens

You added -d '*.example.com' and certbot insists on DNS manual steps. Platform teams request *.internal.example while public CAs cannot issue that pattern for split-horizon zones. Sandbox credentials copied into production plugin env vars fail only when wildcards renew, not during smaller apex HTTP tests.

Wildcard renew fails while apex HTTP cert still renews. API sandboxes issuing real certs against production DNS need separate IAM scopes. Infosec rotations of DNS API keys without updating plugin ini files break only scheduled wildcard renew.

First response

Issue certbot wildcard certificates with DNS-01 plugins, TXT tokens, and apex coverage—not HTTP-01.

Searches for certbot wildcard certificate usually mean automated renewal failed, succeeded locally but never reached the TLS listener, or hit Let's Encrypt rate limits. The fix is almost always permissions, challenge reachability, or a missing reload—not buying a longer-lived commercial cert as the first move.

For Certbot wildcard certificates with DNS challenge, read the ACME or panel error verbatim, run a dry-run renewal if your stack supports it, then confirm what certificate strangers receive on port 443 after you deploy. Certificate files on disk lie; only live handshakes matter for users.

Wildcard issuance with certbot requires DNS-01 and usually manual API plugin setup unless you automate credentials. HTTP-01 cannot prove *.example.com. Expect TXT record churn and tighter IAM on DNS tokens because they unlock universal impersonation on that zone. Triage should capture timestamps, account URLs, and the last Boulder error type before infrastructure changes widen blast radius. Pause destructive retries until you can cite the last Boulder error type and the challenge mechanism in use; random package reinstalls rarely fix presentation gaps.

See also ACME DNS-01 challenge propagation delays and ACME HTTP-01 challenge failed 403.

Why renewal failed

Wildcards validate the parent zone label with TXT at _acme-challenge.example.com. Least-privilege DNS tokens should allow TXT on _acme-challenge only via vendor-specific roles, not full zone admin, because compromise equals universal impersonation. Wildcard DNS-01 credentials deserve vault storage and rotation equal to CA keys.

Plugins exist for major DNS providers; manual mode is brittle in cron. After wildcard issuance, spot-check random subdomains in openssl—they must present the same lineage or dedicated certs according to your routing design. Application teams need clarity on which names wildcard covers to avoid security gaps.

Wildcard covers one level—deeper names need their own certs or SANs. Document which applications assume wildcard coverage versus dedicated host certs. Escalate with timestamps, hostnames, and serial comparisons attached so the next engineer does not repeat already-failed renew attempts.

Certbot --manual --preferred-challenges dns or provider plugins create _acme-challenge TXT entries. Wildcards cover one label depth only: *.example.com does not cover a.b.example.com. Pair wildcards with an apex -d example.com entry. Clarify in tickets whether failure is validation, issuance, deploy, or listener presentment—teams too often mix these phases when reading logs. Wildcard automation is DNS automation; whoever owns TXT API keys owns issuance power for the entire public namespace under that zone.

Wildcard cert does not remove need to reload servers. It does not validate hostnames you add later unless they fit the wildcard pattern. Wildcard convenience does not excuse weak DNS API controls; compromise of DNS automation credentials often equals ability to obtain certificates for every host under the zone.

Common causes

These patterns drive most certbot wildcard certificate tickets. They explain why automation logs look green while browsers or APIs still break.

Plugin credentials scoped to wrong Cloud DNS project. Geo-restricted DNS operators break TXT updates from CI regions that differ from operator laptop locations used for manual tests.

Operator scripted TXT updates on registrar UI incompatible with API rate limits.

Forgot apex along with wildcard. Geo-fenced API keys cannot publish TXT on global anycast DNS views used for validation.

Diagnose

Confirm TXT visibility with dig before finalize. Validate DNS automation credentials with a dummy TXT before touching production wildcard orders; permission errors look like propagation delays in novice triage.

certbot certonly --dry-run --dns-cloudflare -d example.com -d '*.example.com'
dig +short TXT _acme-challenge.example.com @1.1.1.1

dig TXT at _acme-challenge.example.com during dry-run; ensure propagation before Boulder polls. Log which DNS provider account ID plugin selected when organizations own multiple vendor accounts. Compare plugin-listed zone identifier with the WHOIS registrar—wrong account IDs produce TXT in a empty sandbox zone that looks successful in API 200 responses.

Fix step-by-step

Follow this sequence for certbot wildcard certificates with dns challenge. Capture command output after each step so the next responder can pick up without rerunning destructive changes.

1. Store DNS API credentials with least privilege on the zone.
2. Choose supported --dns-* plugin or scripted hook.
3. Include apex -d example.com with wildcard.
4. Lower TTL during first issuance if needed.
5. Verify TXT from multiple resolvers.
6. Install fullchain on all terminators serving matching hosts.
7. Schedule renew with same DNS automation.
8. Document which hosts rely on wildcard coverage.
9. Archive redacted ACME logs and openssl transcripts in the ticket before closing.
10. Schedule a follow-up dry-run before the next natural renewal window.
11. Confirm apex and wildcard both appear in openssl SAN output after issuance.

Verify the live certificate

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Replace HOST with the public hostname on the certificate. Run the same command after any reload or deploy change; acceptance means notAfter moved forward and serial changed versus the incident-opening capture.

How to read the output

openssl SAN shows *.example.com DNS name type when issued correctly. Spot-check a random subdomain covered by the wildcard with openssl; wildcard renewal success on paper does not help if per-host routing serves a different lineage.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Replace HOST with the public hostname users request.

Roll out and verify

Choose supported DNS plugin; store API keys in root-owned 600 files.

Run certbot certonly --dns-<provider> -d '*.example.com' -d example.com. Automate TXT deletion post-issuance to reduce zone clutter and accidental reuse of old tokens. Log which API principal published TXT for audit; SOC reviews often ask after suspicious certificate transparency entries.

Automate TXT cleanup after success; monitor wildcard renewals separately from HTTP certs. Publish a short post-incident note listing which hop served stale TLS and which command proved the fix so the next renewal inherits a checklist.

What to automate

DNS TXT drift alerts before wildcard renew window. Monitor wildcard lineage renewals separately from apex HTTP lineages.

ssldays monitors leaf names users type, not only wildcard patterns. ssldays probes representative subdomains, not only apex. ssldays spot-checks representative subdomains covered by wildcard lineages after DNS renew completes.