SSL certificates for dozens of subdomains quickly becomes a headache.

Recently, I needed to secure all the usual suspects - stuff like api., mail., vault. - and I decided to just get one wildcard SSL certificate that covers them all.

Spoiler: It made life way easier.

Why bother with a wildcard cert?

Managing individual certs for every subdomain is a pain - renewals everywhere, multiple cron jobs, config spaghetti.

A wildcard cert (*.example.com) just covers all subdomains in one go.

This is a solid shortcut to less headache and fewer surprises in a multi service, self hosted infra setup on different subdomains.

Why DNS validation?

Let’s Encrypt offers a few ways to prove you own a domain.

The DNS-01 challenge is basically the only way to get wildcard certs. It means you prove ownership by adding a TXT record to your DNS.

It’s also handy because:

• You don’t have to expose a webserver or open firewall ports
• You can pre-create certs before your service is even live
• It’s less error-prone than messing with HTTP challenges

If your DNS provider has an API and Certbot supports it, you can automate the whole thing. Otherwise, manual TXT records work fine too - just a little more hands-on.

For extra integrity, enable DNSSEC - it helps prevent spoofing of TXT records used in validation.

Certbot? Isn’t there something else?

Sure, there are other ACME clients like acme.sh and lego.

Those are great if you want minimal dependencies or full scripting control. But for my use case, Certbot’s DNS plugins and docs made things straightforward and reliable.

Here’s the quick rundown:

1. Install Certbot

On Debian/Ubuntu, this is easy:

sudo apt update
sudo apt install certbot

2. Grab the DNS plugin (optional)

If you want Certbot to handle DNS TXT record updates automatically (Cloudflare example):

# replace 'cloudflare' with your DNS provider (ex: python3-certbot-dns-digitalocean)
sudo apt install python3-certbot-dns-cloudflare

3. Request the wildcard cert

Manual way:

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

Certbot will spit out a TXT record to add:

_acme-challenge.example.com IN TXT "some_long_token"

Add it, wait a bit, then hit Enter for verification.

Automated way (Cloudflare example):

sudo certbot certonly --dns-cloudflare -d "*.example.com"

This handles the DNS records for you.

Wildcards don’t cover the root domain (example.com), so request both if you need it.

4. Use the cert

After success, your cert will be in:

/etc/letsencrypt/live/example.com/fullchain.pem
/etc/letsencrypt/live/example.com/privkey.pem

Plug those into NGINX, Postfix, whatever.

Don’t forget renewal

Let’s Encrypt certs expire every 90 days. To stay ahead of expiration issues, they recommend renewing every 60 days.

If you’re doing manual DNS, you’ll have to repeat the TXT record dance when they expire.

If automated, just run:

sudo certbot renew --quiet

Or add that to a cron/systemd timer to make it hands-off.

Add something like a deploy hook for post cert renewal actions (which only runs on successful renewals)

sudo certbot renew --quiet --deploy-hook "systemctl reload nginx" # or the web server you use

Why this matters in DevOps

Good SSL management is a silent backbone of solid infrastructure. Wildcard certs + DNS validation cut down complexity, especially if you:

• Run multiple self-hosted tools on subdomains
• Automate deployments in CI/CD
• Want to avoid firefighting expired certs

If you’re in that boat, this setup will save you a bunch of hassle.

Be careful, tho

If someone gains access to your wildcard cert and private key, they can impersonate any subdomain. That’s a much bigger blast radius than a cert for just one subdomain.

For sensitive setups, consider managing certs and keys with something like HashiCorp Vault or Kubernetes Secrets. Don’t just leave .pem files lying around.

If you’ve done this differently or have tips, drop them my way ([email protected]). Always good to swap war stories.