How to Create Let’s Encrypt Wildcard Certificates with Certbot
Let’s Encrypt wildcard certificates are a game-changer for managing SSL/TLS encryption across multiple subdomains without the hassle of generating individual certificates for each one. These certificates use DNS validation instead of HTTP validation, allowing you to secure *.yourdomain.com with a single cert that automatically covers all subdomains. In this guide, you’ll learn how to generate and manage Let’s Encrypt wildcard certificates using Certbot, understand DNS validation requirements, troubleshoot common issues, and implement best practices for automated renewal on your production servers.
How Let’s Encrypt Wildcard Certificates Work
Wildcard certificates differ from standard Let’s Encrypt certificates in their validation method. While regular certificates use HTTP-01 challenge (placing a file on your web server), wildcard certificates require DNS-01 challenge validation. This means Certbot needs to create a specific TXT record in your domain’s DNS zone to prove domain ownership.
The DNS-01 challenge works by having Certbot generate a unique token that gets added as a TXT record at _acme-challenge.yourdomain.com. Let’s Encrypt’s servers then query this DNS record to verify you control the domain. Once validated, the certificate authority issues a wildcard certificate valid for both the root domain and all subdomains.
Here’s what makes wildcard certificates particularly valuable:
- Single certificate covers unlimited subdomains
- Reduces certificate management overhead
- Works with dynamic subdomain applications
- Eliminates rate limit concerns for multiple subdomains
Prerequisites and DNS Provider Setup
Before diving into certificate generation, you’ll need DNS API access for automated validation. Certbot supports numerous DNS providers through plugins, but manual DNS updates are also possible for smaller setups.
Popular DNS providers with Certbot plugins include:
| DNS Provider | Plugin Package | API Requirements | Automation Level |
|---|---|---|---|
| Cloudflare | certbot-dns-cloudflare | API Token | Full automation |
| Route53 (AWS) | certbot-dns-route53 | IAM credentials | Full automation |
| Google Cloud DNS | certbot-dns-google | Service account key | Full automation |
| DigitalOcean | certbot-dns-digitalocean | API Token | Full automation |
Install Certbot and your DNS provider plugin. For Ubuntu/Debian systems:
sudo apt update
sudo apt install certbot
sudo apt install python3-certbot-dns-cloudflare # Replace with your providerFor CentOS/RHEL systems:
sudo yum install epel-release
sudo yum install certbot
sudo yum install python3-certbot-dns-cloudflareStep-by-Step Wildcard Certificate Generation
Method 1: Using DNS Provider Plugin (Recommended)
This example uses Cloudflare, but the process is similar for other providers. First, create a credentials file:
sudo mkdir -p /etc/letsencrypt/credentials
sudo nano /etc/letsencrypt/credentials/cloudflare.iniAdd your Cloudflare API credentials:
# Cloudflare API token (recommended)
dns_cloudflare_api_token = your_api_token_here
# Or use email + global API key (less secure)
# dns_cloudflare_email = your-email@example.com
# dns_cloudflare_api_key = your_global_api_keySecure the credentials file:
sudo chmod 600 /etc/letsencrypt/credentials/cloudflare.iniGenerate the wildcard certificate:
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/credentials/cloudflare.ini \
--dns-cloudflare-propagation-seconds 60 \
-d example.com \
-d *.example.comThe propagation seconds parameter ensures DNS changes have time to propagate before validation attempts. Different providers may require different wait times.
Method 2: Manual DNS Validation
For providers without Certbot plugins or one-time certificate generation:
sudo certbot certonly \
--manual \
--preferred-challenges dns \
--server https://acme-v02.api.letsencrypt.org/directory \
-d example.com \
-d *.example.comCertbot will prompt you to create DNS TXT records manually. You’ll see output like:
Please deploy a DNS TXT record under the name
_acme-challenge.example.com with the following value:
XxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXx
Before continuing, verify the record is deployed.Add the TXT record to your DNS zone and wait for propagation before pressing Enter to continue.
Real-World Use Cases and Examples
Wildcard certificates excel in several scenarios where traditional certificates become unwieldy:
Multi-tenant SaaS Applications: If you’re running a SaaS platform where customers get subdomains like customer1.yourapp.com, customer2.yourapp.com, a wildcard certificate eliminates the need to generate certificates for each new customer.
Microservices Architecture: When deploying microservices with subdomain routing (api.example.com, auth.example.com, admin.example.com), a single wildcard certificate simplifies SSL termination at load balancers.
Development and Staging Environments: Wildcard certificates work perfectly for dev.example.com, staging.example.com, test.example.com without managing separate certificates.
Here’s a practical Nginx configuration example for a wildcard certificate:
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;
# Modern SSL configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512;
ssl_prefer_server_ciphers off;
# Handle subdomain routing
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Automated Renewal Setup
Wildcard certificate renewal requires the same DNS validation process as initial generation. Set up automated renewal with a cron job or systemd timer.
Test renewal first:
sudo certbot renew --dry-runCreate a renewal script for better logging and error handling:
#!/bin/bash
# /usr/local/bin/renew-wildcard-certs.sh
LOG_FILE="/var/log/letsencrypt/renewal.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')
echo "[$DATE] Starting certificate renewal check" >> $LOG_FILE
# Renew certificates
if /usr/bin/certbot renew --quiet --no-self-upgrade; then
echo "[$DATE] Certificate renewal successful" >> $LOG_FILE
# Reload services that use the certificates
systemctl reload nginx
systemctl reload apache2
else
echo "[$DATE] Certificate renewal failed" >> $LOG_FILE
# Send alert email or notification
echo "Wildcard certificate renewal failed on $(hostname)" | mail -s "SSL Certificate Alert" admin@example.com
fiMake the script executable and add to crontab:
sudo chmod +x /usr/local/bin/renew-wildcard-certs.sh
sudo crontab -eAdd this line to run renewal checks twice daily:
0 2,14 * * * /usr/local/bin/renew-wildcard-certs.shTroubleshooting Common Issues
DNS Propagation Delays: The most common issue is insufficient DNS propagation time. Different DNS providers have varying propagation speeds:
- Cloudflare: Usually 1-2 minutes
- Route53: Typically 60-120 seconds
- Traditional DNS providers: Can take 5-15 minutes
Increase the propagation seconds parameter if you encounter validation failures:
--dns-cloudflare-propagation-seconds 120API Rate Limits: Some DNS providers have API rate limits. Space out certificate requests and avoid running multiple Certbot instances simultaneously.
Credential Issues: Verify API credentials have sufficient permissions. For Cloudflare, ensure the API token includes Zone:Read and Zone:DNS:Edit permissions.
Debug DNS propagation manually:
# Check if DNS record exists
dig TXT _acme-challenge.example.com
# Use different DNS servers to verify propagation
dig @8.8.8.8 TXT _acme-challenge.example.com
dig @1.1.1.1 TXT _acme-challenge.example.comCertificate Installation Issues: After generation, certificates are stored in /etc/letsencrypt/live/yourdomain.com/. Ensure your web server configuration points to the correct paths and has proper permissions.
Wildcard vs Regular Certificates Comparison
| Feature | Wildcard Certificates | Regular Certificates |
|---|---|---|
| Subdomain Coverage | Unlimited subdomains | Specific domains only |
| Validation Method | DNS-01 challenge only | HTTP-01 or DNS-01 |
| Setup Complexity | Requires DNS API access | Simple HTTP validation |
| Rate Limits | 20 per week per domain | 50 per week per domain |
| Renewal Automation | Needs DNS automation | Standard HTTP validation |
| Security Risk | Higher (compromised cert affects all subdomains) | Lower (isolated to specific domains) |
Best Practices and Security Considerations
Certificate Storage Security: Let’s Encrypt certificates are stored with appropriate permissions by default, but verify access controls on production systems:
sudo ls -la /etc/letsencrypt/live/example.com/
# Should show root:root ownership with 644/600 permissionsDNS API Security: Use least-privilege API tokens when possible. For Cloudflare, create tokens with Zone:Read and Zone:DNS:Edit permissions only for specific zones rather than global API keys.
Monitoring and Alerting: Set up monitoring for certificate expiration. Here’s a simple script to check certificate validity:
#!/bin/bash
# Check certificate expiration
DOMAIN="example.com"
CERT_FILE="/etc/letsencrypt/live/$DOMAIN/cert.pem"
EXPIRE_DATE=$(openssl x509 -enddate -noout -in $CERT_FILE | cut -d= -f2)
EXPIRE_TIMESTAMP=$(date -d "$EXPIRE_DATE" +%s)
CURRENT_TIMESTAMP=$(date +%s)
DAYS_UNTIL_EXPIRY=$(( ($EXPIRE_TIMESTAMP - $CURRENT_TIMESTAMP) / 86400 ))
if [ $DAYS_UNTIL_EXPIRY -lt 30 ]; then
echo "WARNING: Certificate expires in $DAYS_UNTIL_EXPIRY days"
fiLoad Balancer Configuration: When using wildcard certificates with load balancers, ensure proper SNI (Server Name Indication) configuration for SSL termination. Most modern load balancers like HAProxy, Nginx, and cloud load balancers support wildcard certificates natively.
Certificate Backup: While Let’s Encrypt certificates can be regenerated, backup your /etc/letsencrypt directory regularly, especially on production systems where downtime during reissuing could be problematic.
Testing and Validation: Always test certificate deployment in staging environments first. Use SSL testing tools to verify proper configuration:
# Test SSL configuration
openssl s_client -connect subdomain.example.com:443 -servername subdomain.example.com
# Check certificate details
echo | openssl s_client -connect subdomain.example.com:443 2>/dev/null | openssl x509 -noout -textFor high-traffic production environments, consider deploying on dedicated servers where you have full control over certificate management and can implement custom monitoring solutions. Development and testing environments work well on VPS instances where you can experiment with different certificate configurations.
Additional resources for advanced certificate management can be found in the official Let’s Encrypt documentation and the Certbot documentation, which provide comprehensive guides for specific DNS providers and advanced use cases.
This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.
This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.
More stories
