Multiple Subdomains with Let's Encrypt: Better Solution Than Individual Certificates (Certbot Wildcard Support Since v0.22.0)
In today’s digital landscape, securing web traffic with SSL/TLS is non-negotiable. Whether you run a blog, an e-commerce site, or a complex web application, encrypting data in transit is critical for user trust, SEO, and compliance (e.g., GDPR). Let’s Encrypt, a free, automated, and open certificate authority (CA), has revolutionized SSL adoption by offering free certificates. However, managing certificates for multiple subdomains (e.g., blog.example.com, api.example.com, app.example.com) can quickly become a headache if handled with individual certificates.
Enter wildcard certificates—a single certificate that secures all subdomains of a base domain (e.g., *.example.com). Let’s Encrypt added support for wildcard certificates in March 2018 via the ACME v2 protocol, and Certbot (Let’s Encrypt’s official client) made this accessible with its v0.22.0 release. In this blog, we’ll explore why wildcard certificates are a superior solution to individual certificates for managing multiple subdomains, how Certbot simplifies their deployment, and walk through a step-by-step guide to implement them.
Table of Contents#
- The Problem with Individual Certificates
- What Are Wildcard Certificates?
- Let’s Encrypt Wildcard Support: A Game-Changer
- How Certbot Wildcard Support Works (v0.22.0+)
- Step-by-Step Guide: Setting Up Wildcard Certificates with Certbot
- Advanced Scenarios: Managing Multiple Wildcards & Renewals
- Best Practices for Wildcard Certificate Management
- Conclusion
- References
The Problem with Individual Certificates#
Before wildcard certificates, the standard approach to securing multiple subdomains was to issue individual SSL certificates for each subdomain (e.g., blog.example.com, api.example.com). While this works, it introduces significant challenges as the number of subdomains grows:
1. Scalability Overhead#
- Managing 5, 10, or 50 subdomains means tracking 5, 10, or 50 separate certificates. Each has its own issuance, renewal, and revocation process.
- For large organizations, this can lead to "certificate sprawl," where expired or misconfigured certificates cause unexpected downtime.
2. Renewal Complexity#
Let’s Encrypt certificates expire every 90 days. With individual certificates, you must renew each one separately—either manually or via scripts. This increases the risk of human error or missed renewals, leading to "your connection is not secure" warnings for users.
3. Configuration Fragmentation#
Web servers (e.g., Nginx, Apache) require separate SSL configurations for each certificate. This complicates server setup and makes troubleshooting harder (e.g., tracking which certificate is assigned to which subdomain).
4. Redundancy#
Individual certificates for subdomains of the same base domain often duplicate effort (e.g., repeated validation steps for the same domain).
What Are Wildcard Certificates?#
A wildcard SSL certificate is a single certificate that secures a base domain and all its immediate subdomains. It uses an asterisk (*) as a wildcard character to represent "any subdomain." For example:
*.example.comsecuresblog.example.com,api.example.com,shop.example.com, and any other subdomain at the first level (e.g.,x.example.com,y.example.com).
Key Notes About Wildcards:#
- Scope: Wildcards only cover immediate subdomains (level 1). They do not cover nested subdomains (e.g.,
*.example.comdoes not securea.b.example.com—you would need*.b.example.comfor that). - Base Domain Inclusion: A wildcard certificate for
*.example.comdoes not automatically secure the base domain (example.com). To include the base domain, explicitly add it to the certificate (e.g.,*.example.com+example.com). - Validation: Wildcard certificates require DNS validation (via the ACME DNS-01 challenge) to prove ownership of the domain, as they cannot be validated via HTTP/HTTPS (HTTP-01 challenge) alone.
Let’s Encrypt Wildcard Support: A Game-Changer#
Let’s Encrypt, launched in 2015, disrupted the SSL landscape by offering free, automated certificates. However, it initially lacked support for wildcards. That changed in March 2018 when Let’s Encrypt introduced wildcard certificates via the ACME v2 protocol (Automated Certificate Management Environment, version 2).
Why This Matters:#
- Single Certificate for All Subdomains: Instead of managing dozens of individual certificates, you can secure all first-level subdomains with one wildcard certificate.
- Simplified Renewals: One certificate means one renewal process every 90 days, drastically reducing management overhead.
- Cost Savings: While Let’s Encrypt certificates are free, even paid wildcard certificates are often cheaper than multiple individual certificates.
To leverage Let’s Encrypt wildcards, users need:
- The ACME v2 protocol (endpoint:
https://acme-v02.api.letsencrypt.org/directory). - A client that supports ACME v2, such as Certbot v0.22.0+ (Let’s Encrypt’s official client).
How Certbot Wildcard Support Works (v0.22.0+)#
Certbot, developed by the Electronic Frontier Foundation (EFF), is the most popular client for Let’s Encrypt. With the release of v0.22.0 in March 2018, Certbot added native support for wildcard certificates via ACME v2. Here’s how it works:
1. ACME v2 Protocol Requirement#
Wildcard certificates require the ACME v2 protocol, which introduced the DNS-01 challenge (more on this below). Certbot v0.22.0+ includes support for ACME v2, allowing users to request wildcard certificates directly.
2. The DNS-01 Challenge#
To issue a wildcard certificate, Let’s Encrypt needs to verify that you control the domain. Unlike individual certificates (which can use the HTTP-01 challenge, where you place a file on your web server), wildcards require the DNS-01 challenge.
The DNS-01 challenge works as follows:
- Let’s Encrypt provides a unique validation token.
- You create a TXT DNS record for your domain with the token (e.g.,
_acme-challenge.example.comwith valueabc123...). - Let’s Encrypt queries your domain’s DNS records to confirm the TXT record exists, proving you control the domain.
This is necessary because wildcards secure all subdomains, and HTTP-01 validation (which only checks a specific subdomain) can’t verify ownership of the entire domain.
3. Certbot Automation#
Certbot simplifies the DNS-01 challenge process. It can either:
- Manual Mode: Guide you to add the TXT record manually (ideal for testing or domains without DNS automation).
- Automated Mode: Use DNS plugins (e.g., for Cloudflare, AWS Route 53, Google Cloud DNS) to automatically add/remove TXT records, eliminating manual steps.
Step-by-Step Guide: Setting Up Wildcard Certificates with Certbot#
Let’s walk through issuing a wildcard certificate for *.example.com (and the base domain example.com) using Certbot.
Prerequisites#
- A registered domain (e.g.,
example.com). - Access to manage the domain’s DNS records (via your registrar or DNS provider).
- Certbot v0.22.0 or later installed on your server.
- To check your Certbot version:
certbot --version. - To update Certbot:
- Ubuntu/Debian:
sudo apt update && sudo apt upgrade certbot. - CentOS/RHEL:
sudo yum update certbot.
- Ubuntu/Debian:
- To check your Certbot version:
Step 1: Run Certbot for Wildcard Certificate#
Use the certonly command to request a certificate (we’ll handle web server configuration later). Replace example.com with your domain.
sudo certbot certonly \
--manual \ # Use manual DNS validation (skip if using a DNS plugin)
--server https://acme-v02.api.letsencrypt.org/directory \ # ACME v2 endpoint
-d "*.example.com" \ # Wildcard for all subdomains
-d "example.com" \ # Include the base domain
--agree-tos \ # Agree to Let's Encrypt terms
--no-eff-email \ # Optional: Skip EFF newsletter
--email [email protected] # Contact email for renewal alertsStep 2: Complete the DNS-01 Challenge#
Certbot will prompt you to add a TXT DNS record for _acme-challenge.example.com. For example:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:
_acme-challenge.example.com
with the following value:
abc123dEfGhIjKlMnOpQrStUvWxYz4567890 # Your unique token
Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
How to Add the TXT Record:#
- Log into your DNS provider’s dashboard (e.g., GoDaddy, Cloudflare, Namecheap).
- Add a new TXT record with:
- Host/Name:
_acme-challenge(some providers require the full_acme-challenge.example.com). - Value: The token provided by Certbot (e.g.,
abc123dEfGhIjKlMnOpQrStUvWxYz4567890). - TTL: 300 seconds (5 minutes) for quick propagation.
- Host/Name:
Verify the TXT Record:#
Use dig or nslookup to confirm the record exists (DNS propagation may take 5–10 minutes):
dig TXT _acme-challenge.example.com +shortYou should see your token in the output. Once verified, press Enter in Certbot to proceed.
Step 3: Verify Certificate Issuance#
Certbot will confirm the certificate is issued and saved to /etc/letsencrypt/live/example.com/. The files include:
cert.pem: Server certificate.privkey.pem: Private key (keep this secure!).fullchain.pem: Certificate chain (server cert + intermediate certs).
Step 4: Configure Your Web Server#
Update your web server (Nginx, Apache, etc.) to use the wildcard certificate.
Example: Nginx Configuration#
Edit your Nginx server block (e.g., /etc/nginx/sites-available/example.com):
server {
listen 80;
server_name example.com *.example.com; # Match base domain and all subdomains
return 301 https://$host$request_uri; # Redirect HTTP to HTTPS
}
server {
listen 443 ssl;
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;
# SSL best practices (optional but recommended)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
}Test the configuration and reload Nginx:
sudo nginx -t && sudo systemctl reload nginxStep 5: Test Renewal#
Let’s Encrypt certificates expire in 90 days. Certbot auto-renews certificates by default (via a systemd timer or cron job). Test renewal with:
sudo certbot renew --dry-runIf using manual DNS validation, the dry run will fail (since you can’t automate manual steps). To fix this, use a DNS plugin (see below).
Optional: Use DNS Plugins for Automated Renewals#
Manual DNS validation requires you to update TXT records every 90 days—error-prone for production. Instead, use Certbot’s DNS plugins to automate this.
Example: Cloudflare DNS Plugin#
- Install the Cloudflare plugin:
sudo apt install python3-certbot-dns-cloudflare # Ubuntu/Debian - Create a Cloudflare API token file (e.g.,
~/.secrets/certbot/cloudflare.ini):dns_cloudflare_api_token = your_cloudflare_api_token_here - Secure the file:
chmod 600 ~/.secrets/certbot/cloudflare.ini - Request the certificate with the plugin:
sudo certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \ --server https://acme-v02.api.letsencrypt.org/directory \ -d "*.example.com" \ -d "example.com"
Certbot will now auto-renew the certificate by updating Cloudflare DNS records automatically.
Advanced Scenarios: Managing Multiple Wildcards & Renewals#
Securing Multiple Domains#
To secure wildcards for multiple domains (e.g., *.example.com and *.example.org), add additional -d flags:
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \
-d "*.example.com" -d "example.com" \
-d "*.example.org" -d "example.org"Handling Nested Subdomains#
Wildcards only cover first-level subdomains. To secure a.b.example.com, issue a separate wildcard for *.b.example.com:
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \
-d "*.b.example.com"Renewal Hooks#
Add custom scripts to run before/after renewal (e.g., reload Nginx or notify a monitoring tool). Edit the renewal config file at /etc/letsencrypt/renewal/example.com.conf:
renew_hook = systemctl reload nginx && curl -X POST https://monitoring.example.com/cert-renewedBest Practices for Wildcard Certificate Management#
1. Secure Private Keys#
Wildcard certificates are high-value targets (they secure all subdomains). Store private keys (privkey.pem) in secure, read-only locations (e.g., /etc/letsencrypt/live/) and restrict access with file permissions (chmod 400).
2. Automate Renewals#
Always use DNS plugins (e.g., Cloudflare, Route 53) to automate DNS-01 challenges. Manual renewal is error-prone and risks downtime.
3. Monitor Expiry#
Set up alerts for certificate expiry (e.g., via Prometheus + Grafana, or tools like Cert Spotter). Let’s Encrypt also sends expiry emails to the contact address provided during issuance.
4. Limit Wildcard Scope#
Avoid overusing wildcards. Only issue them for domains where you need to secure many subdomains. For a small number of subdomains, individual certificates may be simpler.
5. Backup Certificates#
Regularly back up /etc/letsencrypt/ (certificates, keys, and renewal configs) to avoid data loss during server migrations.
Conclusion#
Wildcard certificates from Let’s Encrypt, combined with Certbot’s v0.22.0+ support, offer a far superior solution to managing individual certificates for multiple subdomains. They reduce complexity, minimize renewal overhead, and scale effortlessly as your number of subdomains grows. By following the steps in this guide—using DNS automation for renewals and adhering to best practices—you can secure all your subdomains with a single, robust certificate.