Certbot Wildcard SSL With Let's Encrypt, Automated

A wildcard certificate simplifies HTTPS for related subdomains, but it also concentrates responsibility. One private key may authenticate several services, and an unattended renewal failure can affect all of them.

You will issue a certificate using DNS validation, restrict the credentials that make renewal possible, and verify that your web server actually presents the renewed certificate. The example uses Ubuntu, Nginx, and Cloudflare DNS; adapt package installation and plugin settings to your environment.

Map certificate names and renewal deadlines

A certificate for ***.example.com** covers app.example.com but not example.com or api.dev.example.com. Request the apex explicitly if it needs HTTPS. For unrelated services with different administrators, separate certificates and private keys may be safer than one shared wildcard.

Build an inventory of certificate names, the server holding each private key, the DNS provider, and the reload procedure. Use the Unix Timestamp Converter below when monitoring exports epoch timestamps: convert an expiry or last-success value into a readable UTC time and compare it with your maintenance window.

The converter does not inspect certificates or schedule renewals. OpenSSL normally prints certificate dates as text, while monitoring systems may emit epoch seconds or milliseconds. Confirm the unit before interpreting a timestamp; a unit mismatch can make an approaching deadline look comfortably distant. Record the source and timezone with every alert.

Choose DNS validation and limit its credentials

Let's Encrypt requires DNS-01 validation for wildcard names. Certbot proves control by publishing a TXT record beneath _acme-challenge.example.com. The certificate authority queries public DNS; it does not need inbound HTTP access to your private application for this challenge.

Read the Let's Encrypt documentation for challenge behavior and issuance limits. DNS propagation can delay validation even when your provider dashboard already shows the record. Check authoritative nameservers, not only a local resolver with a cached answer.

Use a scoped API token rather than a global account key. For the Cloudflare plugin, grant the DNS editing access required for the specific zone and verify the plugin's current requirements. A token that can change DNS can potentially redirect services, so treat it like a production secret.

If the provider cannot offer narrow permissions, consider delegating the challenge namespace to a separate validation zone supported by your tooling. That is an architectural change, not a universal Certbot switch. Document the delegation and ensure automated cleanup works before relying on unattended renewal.

Install Certbot and issue a testable certificate

Use one supported installation method and matching DNS plugin packages. Avoid mixing a snap-managed Certbot with distribution Python plugins. The following commands assume Ubuntu repository packages are suitable for your release and that the domain's authoritative DNS is hosted at Cloudflare.

sudo apt update
sudo apt install certbot python3-certbot-dns-cloudflare
sudo install -d -m 700 /root/.secrets/certbot
sudo install -m 600 /dev/null /root/.secrets/certbot/cloudflare.ini
sudoedit /root/.secrets/certbot/cloudflare.ini

Put the following setting in that protected file using the editor, not a command that records the token in shell history:

dns_cloudflare_api_token = <SCOPED_DNS_API_TOKEN>

Use the installation selector and plugin guidance at Certbot if your packaging differs. Confirm the plugin appears in sudo certbot plugins before continuing. Avoid requesting production certificates repeatedly while debugging a broken DNS configuration.

The example below first rehearses issuance with the staging service through a dry run, then makes the production request. Replace the email address with a monitored mailbox. The propagation wait is an example starting point, not a promise that every zone is ready within that interval.

sudo certbot certonly --dry-run --dns-cloudflare \
--dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
--dns-cloudflare-propagation-seconds 60 \
--agree-tos --email admin@example.com \
-d example.com -d '*.example.com'
sudo certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
--dns-cloudflare-propagation-seconds 60 \
--agree-tos --email admin@example.com \
-d example.com -d '*.example.com'
sudo certbot certificates

Quoting the wildcard prevents shell expansion. Check the reported certificate name and paths rather than assuming the directory name, especially when earlier certificates already exist. Never copy the private key into a repository, build artifact, or public document root.

Connect issuance to a safe web-server reload

Point Nginx's certificate directives at the fullchain.pem and privkey.pem files under the reported /etc/letsencrypt/live/ directory. Use the full chain, not just the leaf certificate. Keep the live symlinks intact so future renewals replace the underlying files without requiring configuration edits.

Before reloading, run sudo nginx -t. A successful issuance does not guarantee the web server is using that certificate: another server block, another machine, or a fronting CDN may terminate TLS. The Nginx documentation describes HTTPS configuration and graceful reload behavior.

Create an executable root-owned deploy hook under /etc/letsencrypt/renewal-hooks/deploy/ that runs nginx -t && systemctl reload nginx, using a shell script with a valid interpreter line. A deploy hook runs after successful renewal, unlike a generic timer that blindly reloads on every invocation. Ensure ordinary users cannot modify that hook or its parent directories.

Use the packaged renewal timer rather than adding a competing cron job. Inspect systemctl list-timers --all and the relevant Certbot timer unit. Installations differ, so verify the actual unit name and schedule on your server instead of assuming one exists.

Test renewal and monitor the served certificate

Run sudo certbot renew --dry-run after initial setup and whenever DNS credentials, permissions, or plugins change. Dry runs do not execute deploy hooks by default; use the supported --run-deploy-hooks option when deliberately testing that path, understanding that it can reload your production service.

Check the live endpoint with openssl s_client -connect example.com:443 -servername example.com, then inspect the returned certificate using openssl x509 -noout -dates -issuer -subject. The SNI name matters when several sites share an address. Repeat for representative subdomains and any separate TLS termination layer.

Monitor served expiry, renewal logs, and the last successful validation. An on-disk certificate may be current while a long-running proxy still serves the old one. Use an independent external check to catch that mismatch, and alert early enough to fix DNS access without emergency changes.

Convert exported deadline values with the timestamp utility, keeping UTC and timestamp units explicit. Combine expiry checks with the server monitoring workflow and restrict administration using the Ubuntu VPS hardening guide.

Keep a renewal runbook with the token owner, DNS zone, certificate names, and service reload command. Test replacement credentials before revoking the old token, then remove the obsolete secret from every renewal host. This avoids turning an otherwise routine credential rotation into a certificate outage several weeks later, when the original change is harder to trace.

Key takeaways

• Request wildcard and apex names separately within the same certificate when both are required.
• Automate DNS-01 with least-privilege credentials, protected files, and a tested provider plugin.
• Validate Nginx before reload and connect reloads to successful renewal through a deploy hook.
• Monitor the certificate clients actually receive, not only files and successful timer executions.