Learning Hub

Wildcard Certificates With Certbot: DNS-01 Checklist for Hosting Admins

A precise checklist for issuing Let’s Encrypt wildcard certificates with Certbot, DNS-01 validation, restricted DNS API tokens, renewal tests, and safe deploy hooks.

June 9, 2026 5 Min Read
66

A wildcard certificate is useful when a hosting admin needs one certificate to cover many first-level subdomains, but the validation method matters. Let’s Encrypt says DNS-01 proves control by publishing a TXT record under _acme-challenge.<YOUR_DOMAIN>, and it specifically notes that DNS-01 can issue wildcard certificates. Let’s Encrypt also says DNS-01 is harder to configure than HTTP-01 and only makes sense for automation when the DNS provider has an API.

Table Of Content

Use DNS automation, not manual renewal

Certbot’s manual plugin can obtain a certificate by asking you to perform validation yourself, but Certbot’s own table says manually created certificates do not support autorenewal unless you provide an authentication hook to automate the validation steps. For hosting work, that makes a provider-specific DNS plugin the safer default.

DigitalOcean’s tutorial is a useful topic seed for wildcard issuance, but the operational rule should come from the ACME client and CA documentation: pick the DNS plugin that matches your provider, test it on a non-critical host first, and make renewal boring. The DigitalOcean guide covers wildcard issuance with Certbot and DNS-01 workflow examples.

Protect the DNS token like a production secret

With the Cloudflare Certbot plugin, the credentials file is passed with --dns-cloudflare-credentials. The plugin documentation recommends restricted Cloudflare API tokens over a global API key and says the token needs Zone:DNS:Edit permissions only for the zones that need certificates.

The same documentation warns that users who can read the credentials file can use those credentials to issue API calls on your behalf, and says Certbot will warn about unsafe permissions until access is restricted, for example with chmod 600. That means the credential file belongs outside the web root and should be readable only by the account that runs Certbot.

Example Cloudflare command

After the matching Certbot DNS plugin is installed, a typical Cloudflare command for the apex plus first-level wildcard looks like this:

sudo certbot certonly 
  --dns-cloudflare 
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini 
  --dns-cloudflare-propagation-seconds 60 
  -d example.com 
  -d '*.example.com'

The exact plugin flag changes by DNS provider, but the pattern does not: request the apex and wildcard names together, use DNS-01, and wait long enough for TXT-record propagation before validation. The Cloudflare plugin documents the --dns-cloudflare, credentials-file, and propagation-seconds options.

Pre-flight checklist

Wildcard certificates are powerful because they reduce certificate sprawl, but they also centralize risk. Treat the DNS API token, renewal timer, and deploy hook as production infrastructure, not as a one-time command copied from a tutorial.

Featured image credit: “Wildcard SSL certificate Explaination” by PeggyPesiri, licensed under CC BY-SA 3.0, via Wikimedia Commons.

DNS-01 production runbook: prove DNS before renewal day

This section applies to an Ubuntu/Debian ACME host running Certbot with a provider-specific DNS plugin. It does not apply to a shared cPanel account where you only control files under your home directory. On cPanel/WHM servers, avoid unmanaged Certbot changes to web-server certificate paths unless you also own the WHM integration and renewal process; WHM’s AutoSSL and SSL-install interfaces are designed to manage certificates inside that stack. cPanel Manage AutoSSL

Before issuing a wildcard certificate, confirm four prerequisites: the domain’s authoritative DNS provider, a DNS API token scoped to the relevant zone, root or sudo access on the ACME host, and the exact names required. A request for *.example.com does not cover example.com itself, so most hosting setups request both names in the same lineage. Let’s Encrypt documents DNS-01 as the challenge type that can issue wildcard certificates by publishing a TXT record under _acme-challenge. Let’s Encrypt DNS-01 challenge docs

Target system: DNS admin workstation with dig installed

dig +short NS example.com
dig TXT _acme-challenge.example.com @AUTHORITATIVE_NAMESERVER

The first command identifies where Let’s Encrypt will expect the TXT record to exist. The second command should be run during validation or after a failed attempt, replacing AUTHORITATIVE_NAMESERVER with one of the actual nameservers. If the TXT record appears in a convenience DNS panel but not at the authoritative nameserver, Certbot will fail even though the local panel looks correct.

Target system: Ubuntu/Debian Certbot host storing a Cloudflare token

sudo install -d -m 700 /etc/letsencrypt/secrets
sudo install -m 600 -o root -g root cloudflare.ini /etc/letsencrypt/secrets/cloudflare.ini

The Cloudflare DNS plugin documentation warns that anyone who can read the credentials file can use those credentials. Use a restricted API token with DNS edit permission only for the needed zone, store it outside the web root, and keep file permissions tight. Certbot Cloudflare plugin docs

Target system: Ubuntu/Debian Certbot host issuing apex plus wildcard

sudo certbot certonly 
  --dns-cloudflare 
  --dns-cloudflare-credentials /etc/letsencrypt/secrets/cloudflare.ini 
  --dns-cloudflare-propagation-seconds 120 
  -d example.com 
  -d '*.example.com'

The propagation delay is not cosmetic. If the DNS provider updates slowly, Certbot may ask Let’s Encrypt to validate before the TXT record is visible from public resolvers. Raise the propagation seconds when failures mention missing or incorrect TXT records. If you delegate _acme-challenge with a CNAME to a separate validation zone, document that delegation because future DNS migrations often break renewals silently.

Target system: Ubuntu/Debian Certbot host after issuance

sudo certbot certificates
sudo certbot renew --dry-run
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -subject -issuer -dates -ext subjectAltName

certbot certificates confirms the lineage and configured names. renew --dry-run proves that the renewal path can authenticate without a human adding TXT records. Certbot’s documentation explains automated renewals and why manual DNS creation is not enough unless hooks automate validation. Certbot automated renewal docs The OpenSSL check confirms the served certificate includes the apex and wildcard names you intended. Common failure modes are wrong DNS provider, an API token scoped to the wrong zone, unsafe credential-file permissions, too-short propagation delay, and a deploy hook that renews the certificate but never reloads the service that uses it.

cPanel/WHM decision point

For cPanel/WHM, decide who owns the final installation. If WHM AutoSSL owns the domain, manage renewal there. If an external Certbot host issues the wildcard, install it through a supported WHM/cPanel SSL path and document the replacement schedule; otherwise the certificate can renew correctly on disk while Apache, Nginx, mail, or the control panel continues serving the old certificate. cPanel SSL installation docs

Tags:

CertbotDNS-01Hosting SecurityLet’s EncryptTLS

Share

No Comment! Be the first one.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts