Wildcard SSL Certificates: Complete Implementation Guide 2025

November 20, 2025 By SSL Checker Pro Team 7 min read

Wildcard SSL certificates provide an elegant solution for securing multiple subdomains under a single domain with one certificate. Instead of managing separate certificates for blog.example.com, shop.example.com, and api.example.com, a wildcard certificate (*.example.com) secures them all. This comprehensive guide covers everything you need to know about wildcard SSL certificates in 2025.

What is a Wildcard SSL Certificate?

A wildcard SSL certificate is a digital certificate that secures a domain and all its first-level subdomains using a single certificate. The asterisk (*) in the Common Name (CN) field acts as a wildcard placeholder, matching any valid subdomain name.

Wildcard Certificate Coverage

Certificate for: *.example.com

✅ Secures:

  • blog.example.com
  • shop.example.com
  • api.example.com
  • mail.example.com
  • Any other first-level subdomain

❌ Does NOT secure:

  • example.com (root domain - requires separate entry)
  • sub.blog.example.com (second-level subdomain)
  • admin.api.example.com (second-level subdomain)

When to Use Wildcard SSL Certificates

Wildcard certificates are ideal for specific scenarios where multiple subdomains need SSL protection.

Perfect Use Cases

Scenario Why Wildcard Works Example
Multi-tenant SaaS Each customer gets subdomain customer1.saas.com, customer2.saas.com
Microservices Architecture Each service on separate subdomain api.app.com, auth.app.com, data.app.com
Development Environments Multiple staging/dev environments dev.example.com, staging.example.com
Content Delivery Regional or service-specific subdomains cdn.site.com, static.site.com, media.site.com
Email Services Multiple mail-related subdomains mail.domain.com, webmail.domain.com

⚠️ When NOT to Use Wildcard Certificates

  • Single Domain: If you only need to secure one or two subdomains, individual certificates are more secure
  • Multi-level Subdomains: Wildcards only cover one level (*.example.com doesn't cover *.api.example.com)
  • Different Organizations: If subdomains are managed by different teams with different security requirements
  • Compliance Requirements: Some regulations prohibit wildcard certificates due to security concerns

Obtaining a Wildcard SSL Certificate

Wildcard certificates require DNS-01 validation since HTTP-01 validation cannot verify wildcard domains. Here's how to obtain them from various providers.

Free Wildcard Certificate with Let's Encrypt

Let's Encrypt offers free wildcard certificates using DNS-01 challenge validation.

#!/bin/bash
# Install Certbot with DNS plugin
sudo apt-get update
sudo apt-get install certbot python3-certbot-dns-cloudflare

# Create Cloudflare credentials file
cat > ~/.secrets/cloudflare.ini << EOF
dns_cloudflare_api_token = your_cloudflare_api_token
EOF

chmod 600 ~/.secrets/cloudflare.ini

# Request wildcard certificate
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d example.com \
  -d *.example.com \
  --non-interactive \
  --agree-tos \
  --email admin@example.com

# Certificate files will be saved to:
# /etc/letsencrypt/live/example.com/fullchain.pem
# /etc/letsencrypt/live/example.com/privkey.pem

DNS Providers Supported by Certbot

DNS Provider Plugin Package Installation Command
Cloudflare certbot-dns-cloudflare apt-get install python3-certbot-dns-cloudflare
AWS Route53 certbot-dns-route53 apt-get install python3-certbot-dns-route53
Google Cloud DNS certbot-dns-google apt-get install python3-certbot-dns-google
DigitalOcean certbot-dns-digitalocean apt-get install python3-certbot-dns-digitalocean
Namecheap acme-dns-route53 Manual DNS update required

Using acme.sh for Wildcard Certificates

acme.sh is a lightweight alternative to Certbot with extensive DNS provider support.

#!/bin/bash
# Install acme.sh
curl https://get.acme.sh | sh
source ~/.bashrc

# Set DNS provider credentials (Cloudflare example)
export CF_Token="your_cloudflare_api_token"
export CF_Account_ID="your_account_id"

# Issue wildcard certificate
acme.sh --issue --dns dns_cf \
  -d example.com \
  -d *.example.com \
  --keylength 2048

# Install certificate to nginx
acme.sh --install-cert -d example.com \
  --key-file /etc/nginx/ssl/example.com.key \
  --fullchain-file /etc/nginx/ssl/example.com.crt \
  --reloadcmd "systemctl reload nginx"

# Enable automatic renewal
acme.sh --upgrade --auto-upgrade

Configuring Web Servers for Wildcard Certificates

Once you have your wildcard certificate, configure your web server to use it across all subdomains.

Nginx Configuration

# /etc/nginx/sites-available/wildcard-ssl.conf

# Redirect HTTP to HTTPS for all subdomains
server {
    listen 80;
    server_name example.com *.example.com;
    return 301 https://$host$request_uri;
}

# Main domain HTTPS configuration
server {
    listen 443 ssl http2;
    server_name example.com;
    
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    
    root /var/www/html;
    index index.html;
}

# Wildcard subdomain configuration
server {
    listen 443 ssl http2;
    server_name *.example.com;
    
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    
    # Route based on subdomain
    location / {
        if ($host = "api.example.com") {
            proxy_pass http://localhost:3000;
        }
        if ($host = "blog.example.com") {
            proxy_pass http://localhost:4000;
        }
        if ($host = "shop.example.com") {
            proxy_pass http://localhost:5000;
        }
    }
}

# Specific subdomain configurations
server {
    listen 443 ssl http2;
    server_name api.example.com;
    
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Apache Configuration

# /etc/apache2/sites-available/wildcard-ssl.conf

# Enable required modules
# a2enmod ssl rewrite proxy proxy_http headers


    ServerName example.com
    ServerAlias *.example.com
    
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]



    ServerName example.com
    ServerAlias *.example.com
    
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder on
    
    # Main domain
    
        DocumentRoot /var/www/html
    
    
    # API subdomain
    
        ProxyPreserveHost On
        ProxyPass / http://localhost:3000/
        ProxyPassReverse / http://localhost:3000/
    
    
    # Blog subdomain
    
        DocumentRoot /var/www/blog
    
    
    # Shop subdomain
    
        ProxyPreserveHost On
        ProxyPass / http://localhost:5000/
        ProxyPassReverse / http://localhost:5000/
    

Wildcard Certificates in Cloud Environments

AWS Certificate Manager (ACM)

AWS ACM provides free wildcard certificates with automatic renewal for AWS services.

# Using AWS CLI
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names *.example.com \
  --validation-method DNS \
  --region us-east-1

# Get validation records
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc123 \
  --region us-east-1

# Add CNAME records to Route53 for validation
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch file://validation-records.json

Terraform Configuration for ACM Wildcard

resource "aws_acm_certificate" "wildcard" {
  domain_name               = "example.com"
  subject_alternative_names = ["*.example.com"]
  validation_method         = "DNS"
  
  lifecycle {
    create_before_destroy = true
  }
  
  tags = {
    Name = "Wildcard Certificate"
    Environment = "production"
  }
}

resource "aws_route53_record" "cert_validation" {
  for_each = {
    for dvo in aws_acm_certificate.wildcard.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }
  
  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 60
  type            = each.value.type
  zone_id         = aws_route53_zone.main.zone_id
}

resource "aws_acm_certificate_validation" "wildcard" {
  certificate_arn         = aws_acm_certificate.wildcard.arn
  validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

# Use with CloudFront
resource "aws_cloudfront_distribution" "main" {
  # ... other configuration ...
  
  viewer_certificate {
    acm_certificate_arn      = aws_acm_certificate_validation.wildcard.certificate_arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2021"
  }
  
  aliases = ["example.com", "*.example.com"]
}

Security Considerations

⚠️ Wildcard Certificate Security Risks

  • Broader Attack Surface: Compromise of private key affects all subdomains
  • Key Management: Single private key must be distributed to all servers hosting subdomains
  • Revocation Impact: Revoking wildcard certificate affects all subdomains simultaneously
  • Certificate Transparency: Wildcard certificates are visible in CT logs, revealing subdomain structure
  • Compliance Issues: Some security standards (PCI DSS) have restrictions on wildcard usage

Best Practices for Wildcard Certificate Security

1. Implement Strict Key Management

# Store private key with restricted permissions
chmod 600 /etc/ssl/private/wildcard.key
chown root:root /etc/ssl/private/wildcard.key

# Use hardware security modules (HSM) for production
# Store keys in AWS Secrets Manager or HashiCorp Vault
aws secretsmanager create-secret \
  --name wildcard-ssl-key \
  --secret-string file:///path/to/privkey.pem \
  --kms-key-id alias/ssl-keys

2. Monitor Certificate Usage

Track which servers and services use the wildcard certificate. Implement certificate pinning where appropriate.

3. Use Separate Certificates for Critical Services

High-security services (payment processing, authentication) should use dedicated certificates, not wildcard certificates.

4. Implement Certificate Rotation

Rotate wildcard certificates more frequently than standard certificates (every 60-90 days instead of annually).

Cost Comparison

Provider Wildcard Certificate Cost Validation Method Renewal
Let's Encrypt Free DNS-01 Automatic (90 days)
AWS ACM Free (for AWS services) DNS Automatic
DigiCert $595 - $1,495/year DNS/Email Manual
Sectigo (Comodo) $239 - $599/year DNS/Email Manual
GoDaddy $299 - $899/year DNS/Email Manual

Cost Savings Example

Scenario: Securing 10 subdomains

  • Individual Certificates: 10 × $50/year = $500/year
  • Wildcard Certificate: $239/year (Sectigo) or Free (Let's Encrypt)
  • Savings: $261/year or $500/year

Break-even point: Wildcard becomes cost-effective at 5+ subdomains

Troubleshooting Common Issues

Issue: DNS Validation Failing

# Check DNS propagation
dig _acme-challenge.example.com TXT +short

# Verify DNS record from multiple locations
nslookup -type=TXT _acme-challenge.example.com 8.8.8.8
nslookup -type=TXT _acme-challenge.example.com 1.1.1.1

# Wait for DNS propagation (can take up to 48 hours)
# Use DNS propagation checker: https://dnschecker.org

Issue: Certificate Not Covering Root Domain

Remember: *.example.com does NOT cover example.com. Always include both in your certificate request:

certbot certonly --dns-cloudflare \
  -d example.com \
  -d *.example.com

Issue: Second-Level Subdomains Not Secured

Wildcard certificates only cover one level. For multi-level subdomains, you need multiple wildcards or specific entries:

# Option 1: Multiple wildcard certificates
certbot certonly --dns-cloudflare \
  -d example.com \
  -d *.example.com \
  -d *.api.example.com

# Option 2: Specific subdomain entries
certbot certonly --dns-cloudflare \
  -d example.com \
  -d *.example.com \
  -d admin.api.example.com \
  -d v2.api.example.com

Conclusion

Wildcard SSL certificates offer a powerful, cost-effective solution for securing multiple subdomains with a single certificate. They're ideal for SaaS platforms, microservices architectures, and organizations with numerous subdomains. However, they require careful security considerations, proper key management, and DNS-01 validation. By following the implementation strategies and best practices outlined in this guide, you can effectively deploy and manage wildcard certificates in your infrastructure.

Verify Your Wildcard SSL Certificate

Use our free tools to validate your wildcard certificate installation: