Wildcard SSL with Certbot for All Subdomains

A regular Let's Encrypt certificate is issued for a specific domain. A wildcard certificate (*.yourdomain.com) covers any number of subdomains — convenient for multi-site projects.

Installing Certbot

sudo apt update && sudo apt install -y certbot python3-certbot-dns-cloudflare

Certbot + Cloudflare DNS (recommended)

# Create a Cloudflare API token:
# Dashboard → Profile → API Tokens → Create Token
# Permissions: Zone.DNS → Edit

# Save the token
sudo mkdir -p /etc/letsencrypt
sudo nano /etc/letsencrypt/cloudflare.ini

dns_cloudflare_api_token = YOUR_CLOUDFLARE_TOKEN

sudo chmod 600 /etc/letsencrypt/cloudflare.ini

# Obtain the wildcard certificate
sudo certbot certonly   --dns-cloudflare   --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini   -d "yourdomain.com"   -d "*.yourdomain.com"   --agree-tos --non-interactive

Without Cloudflare: Manual DNS Challenge

sudo certbot certonly --manual   --preferred-challenges dns   -d "*.yourdomain.com" -d "yourdomain.com"

# Certbot will output a TXT record for DNS:
# Add: _acme-challenge.yourdomain.com TXT "xxx..."
# Wait 60 sec and press Enter

Connecting to Nginx

ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

Auto-Renewal

sudo certbot renew --dry-run
# Add to cron:
0 3 * * * certbot renew --quiet --post-hook "systemctl reload nginx"

Diagnosing common errors

The error DNS problem: NXDOMAIN looking up TXT record during a manual DNS challenge means the _acme-challenge TXT record is not yet visible to public DNS servers — either it was added with a typo, or not enough time has passed for propagation.

Domain: yourdomain.com
Type:   dns
Detail: DNS problem: NXDOMAIN looking up TXT record for _acme-challenge.yourdomain.com

Check the record independently of certbot before pressing Enter: dig TXT _acme-challenge.yourdomain.com +short from another server or through a public resolver like 8.8.8.8. If the record is still invisible from outside after a few minutes, the problem is the DNS panel itself, not timing.

The error Error creating new order :: too many failed authorizations from Let's Encrypt appears after several failed attempts in a row for one domain and blocks new attempts for an hour. To debug DNS validation without burning the limit, use the --staging flag, which issues test certificates without production rate limits.

Comparing Certbot DNS plugins

Without an API plugin, wildcard certificate auto-renewal will not work: certbot cannot insert a new TXT record itself with --manual, so every 90 days the process must be repeated by hand unless the DNS provider is supported directly.

When a wildcard certificate is not needed

• You have one or two subdomains, not dozens — it is simpler and more reliable to issue a regular certificate for specific names through Certbot with HTTP validation, without dealing with a DNS API.
• DNS is managed through a panel with no API, or through a registrar unsupported by certbot — every renewal then needs manual intervention, and a regular certificate with HTTP auto-renewal is more reliable.
• Subdomains are created dynamically per customer (a SaaS with arbitrary names) — DNS-01 for a wildcard does not fit third-level domains created on the fly; that case needs a separate automation that issues certificates through the ACME API on customer signup.

Verifying the result

1. Confirm the certificate is actually a wildcard: openssl x509 -in /etc/letsencrypt/live/yourdomain.com/cert.pem -noout -text | grep DNS must show both yourdomain.com and *.yourdomain.com.
2. Open any random subdomain in a browser that was never explicitly defined in the Nginx config — the padlock must be closed with no warnings.
3. Test auto-renewal with a dry run: certbot renew --dry-run must finish without DNS plugin errors.
4. If using --manual, mark the next renewal date on a calendar a week before expiry — automation will not handle this on its own.

Regular (non-wildcard) issuance and auto-renewal through the Nginx plugin is covered in the article on Certbot and Nginx. If the site sits behind Cloudflare, check the article on Cloudflare SSL/TLS modes first — it affects which validation method to choose.

Method 1: Manual DNS Challenge

sudo certbot certonly   --manual   --preferred-challenges dns   -d "*.example.com"   -d "example.com"

# Certbot will ask you to add a TXT record:
# _acme-challenge.example.com → the given value
# 
# Add the record to DNS and wait for propagation (1–5 min)
# Then press Enter

Method 2: Automatic via the Cloudflare API

# Create a file with the Cloudflare token
sudo nano /etc/letsencrypt/cloudflare.ini
# Contents:
dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN

sudo chmod 600 /etc/letsencrypt/cloudflare.ini

# Obtain the certificate
sudo certbot certonly   --dns-cloudflare   --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini   -d "*.example.com"   -d "example.com"   --email admin@example.com   --agree-tos   --non-interactive

Configuring Nginx with Wildcard SSL

server {
    listen 443 ssl http2;
    server_name *.example.com example.com;
    
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

Checking and Renewing

# Check the certificate
sudo certbot certificates

# Test auto-renewal
sudo certbot renew --dry-run

# Force renewal
sudo certbot renew --force-renewal

Frequently asked questions

Can a wildcard certificate be obtained through regular HTTP validation instead of DNS?

No, ACME requires DNS validation for wildcard certificates — an HTTP-01 challenge proves ownership of one name through a file on the web server, and there's no way to place a file in advance for a subdomain created on the fly. Certbot asks for a DNS TXT record when issuing a wildcard certificate, whether through an API or by hand.

Does a *.domain.com certificate also cover the bare domain.com without a subdomain?

No, a wildcard entry only covers first-level subdomains and doesn't automatically include the bare domain — it has to be listed as a separate name when the certificate is issued, as shown in the certbot examples with two -d flags. Forgetting to add the bare domain separately means the browser shows a warning when visiting the site without any subdomain.

What happens if a certificate expires and auto-renewal was never set up?

Visitors' browsers will start showing an invalid certificate warning across every subdomain at once, not just one site, since a single wildcard certificate serves all of them together. Setting up auto-renewal through a DNS API prevents this, and with the manual method the next renewal date needs to be marked ahead of time rather than left until the last moment.

Can the same wildcard certificate be used on several servers at once?

Yes, the same certificate file and private key can be copied onto multiple servers at once — there's no limit on how many machines one certificate can run on. The one thing to keep synchronized is renewal: when the certificate renews on one server, the updated files need pushing to the rest, or some servers keep serving an outdated certificate.