SSL certificates for dozens of subdomains quickly becomes a headache.
\nRecently, 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.
\nManaging individual certs for every subdomain is a pain - renewals everywhere, multiple cron jobs, config spaghetti.
\nA 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.
\nLet’s Encrypt offers a few ways to prove you own a domain.
\nThe 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.
\nIt’s also handy because:
\nIf 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.
\nFor extra integrity, enable DNSSEC - it helps prevent spoofing of TXT records used in validation.
\nSure, 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.
\nOn Debian/Ubuntu, this is easy:
\nsudo apt update\nsudo apt install certbotIf you want Certbot to handle DNS TXT record updates automatically (Cloudflare example):
\n# replace 'cloudflare' with your DNS provider (ex: python3-certbot-dns-digitalocean)\nsudo apt install python3-certbot-dns-cloudflareManual way:
\nsudo certbot certonly --manual --preferred-challenges dns -d \"*.example.com\"Certbot will spit out a TXT record to add:
\n_acme-challenge.example.com IN TXT \"some_long_token\"Add it, wait a bit, then hit Enter for verification.
\nAutomated way (Cloudflare example):
\nsudo certbot certonly --dns-cloudflare -d \"*.example.com\"This handles the DNS records for you.
\nWildcards don’t cover the root domain (example.com), so request both if you need it.
\nAfter success, your cert will be in:
\n/etc/letsencrypt/live/example.com/fullchain.pem\n/etc/letsencrypt/live/example.com/privkey.pemPlug those into NGINX, Postfix, whatever.
\nLet’s Encrypt certs expire every 90 days. To stay ahead of expiration issues, they recommend renewing every 60 days.
\nIf you’re doing manual DNS, you’ll have to repeat the TXT record dance when they expire.
\nIf automated, just run:
\nsudo certbot renew --quietOr add that to a cron/systemd timer to make it hands-off.
\nAdd something like a deploy hook for post cert renewal actions (which only runs on successful renewals)
\nsudo certbot renew --quiet --deploy-hook \"systemctl reload nginx\" # or the web server you useGood SSL management is a silent backbone of solid infrastructure. Wildcard certs + DNS validation cut down complexity, especially if you:
\nIf you’re in that boat, this setup will save you a bunch of hassle.
\nIf 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.
\nFor 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 (dev@rhuzaifa.com). Always good to swap war stories.
","frontmatter":{"title":"One Wildcard SSL Certificate to Secure All Subdomains via Certbot","date":"July 18, 2024","description":"Wildcard + Certbot + DNS = one cert to rule them all."}}},"pageContext":{"slug":"/blog/one-wildcard-ssl-certificate-to-secure-all-subdomains-via-certbot/","previous":{"fields":{"slug":"/blog/aggregating-rss-feeds-locally-with-a-simple-bash-script/"},"frontmatter":{"title":"Aggregating RSS Feeds Locally with a Simple Bash Script"}},"next":{"fields":{"slug":"/blog/docker-is-great-just-not-for-local-dev/"},"frontmatter":{"title":"Docker Is Great, Just Not for Local Dev"}}}},"staticQueryHashes":["2276319502"]}