“Do I Really Need Separate SSL Certificates for Every Subdomain?”

We get this question regularly from customers setting up their first multi-site architecture: “I have mydomain.com, www.mydomain.com, api.mydomain.com, and mail.mydomain.com. Do I really need to buy four separate SSL certificates?”

The short answer: no. That’s exactly what wildcard SSL certificates are designed for.

But there’s a longer answer that involves security trade-offs, cost comparisons, and architectural decisions. This guide covers when wildcard certificates make sense, when they don’t, and how to implement them properly.

What Is a Wildcard SSL Certificate?

A wildcard SSL certificate secures a domain and all its first-level subdomains with a single certificate. The common name is written with an asterisk: *.yourdomain.com

This single certificate validates HTTPS for:

  • yourdomain.com (the root domain, depending on the CA)
  • www.yourdomain.com
  • api.yourdomain.com
  • mail.yourdomain.com
  • staging.yourdomain.com
  • any-subdomain.yourdomain.com

The asterisk acts as a wildcard that matches one level of subdomain. It does not cover nested subdomains like api.staging.yourdomain.com — you’d need a separate certificate for that.

The Economics: Wildcard vs Individual Certificates

Here’s where the math gets interesting. Let’s compare costs for a typical small business setup with 5 subdomains:

Approach Certificates Needed Estimated Cost/Year Management Overhead
Individual DV certs (Let’s Encrypt) 5 Free 5 auto-renewals to manage
Individual OV certs (paid) 5 $375 – $1,000 5 separate renewals, expirations
Wildcard OV certificate 1 $150 – $400 1 renewal, covers all subdomains

For paid OV certificates, the wildcard typically becomes cost-effective at 3+ subdomains. For free Let’s Encrypt, the trade-off is purely management overhead — do you want to maintain 5 separate auto-renewals or 1?

When Wildcard Certificates Make Sense

Wildcard certificates are the right choice when:

1. You Have Multiple Public-Facing Subdomains

If your architecture uses subdomains for different services — app., api., docs., blog. — a wildcard simplifies certificate management dramatically. Add a new subdomain? No new certificate procurement needed. Just configure the web server and the existing wildcard covers it.

2. You Need Rapid Environment Spin-Up

Development teams often create ephemeral environments like feature-123.staging.yourdomain.com for testing. A wildcard certificate means you don’t need to request a new certificate every time someone spins up a test environment. (Though note: for this use case, the subdomain nesting — feature-123.staging — means you’d need *.staging.yourdomain.com, not just *.yourdomain.com.)

3. You Want Consolidated Renewal Management

One expiration date. One renewal process. One potential point of failure. For teams without dedicated DevOps staff, this simplicity has real value. Miss one renewal and your entire subdomain fleet goes secure at once — but the flip side is you only need to fix it once.

4. Cost Efficiency at Scale

For paid certificates, wildcards almost always cost less than equivalent individual certificates once you exceed 3-4 subdomains. The break-even point varies by CA and certificate type, but the math is straightforward.

When Wildcard Certificates Are the Wrong Choice

There are legitimate security and operational reasons to avoid wildcards:

1. High-Security Environments

If a wildcard private key is compromised, the attacker can impersonate every subdomain protected by that certificate. For organisations handling financial transactions, healthcare data, or other sensitive information, this blast radius is too large.

In these environments, use individual certificates with separate key pairs. A compromise of api.yourdomain.com shouldn’t also compromise admin.yourdomain.com.

2. Multi-Tenant or Customer-Facing Subdomains

If you provide subdomains to customers (e.g., customer-a.yourdomain.com, customer-b.yourdomain.com), sharing a wildcard private key across customer environments is a security anti-pattern. Each customer should have certificate isolation.

3. Compliance Requirements

Some compliance frameworks (PCI-DSS, SOC 2, HIPAA) recommend or require certificate segmentation. Using individual certificates with distinct key pairs provides an audit trail and limits exposure. Check your specific compliance requirements.

4. Different Validation Levels

Your main site might warrant an EV certificate for maximum trust, while your API or staging environment only needs DV. Wildcards are issued at a single validation level — you can’t mix EV for some subdomains and DV for others under one wildcard.

Wildcard vs Multi-Domain (SAN) Certificates

These are often confused but serve different purposes:

Certificate Type Covers Best For
Wildcard *.yourdomain.com (all first-level subdomains) Many subdomains under one domain
Multi-Domain (SAN) yourdomain.com, otherdomain.ca, thirddomain.net (specific list) Multiple different domains
Both *.yourdomain.com + otherdomain.ca (limited) Complex multi-domain setups

If you have yourdomain.com, yourdomain.ca, and yourdomain.net with no subdomains, a multi-domain certificate is more appropriate. If you have www.yourdomain.com, api.yourdomain.com, and mail.yourdomain.com, a wildcard is simpler.

How to Get and Install a Wildcard Certificate

Option 1: Let’s Encrypt (Free, DV Only)

Let’s Encrypt supports wildcard certificates via DNS-01 challenge validation. You’ll need API access to your DNS provider.

# Install certbot
sudo apt install certbot python3-certbot-dns-cloudflare

# Create Cloudflare API credentials file
echo "dns_cloudflare_api_token = YOUR_TOKEN" > /etc/letsencrypt/cloudflare.ini
chmod 600 /etc/letsencrypt/cloudflare.ini

# Request wildcard certificate
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "*.yourdomain.com" \
  -d "yourdomain.com" \
  --email admin@yourdomain.com \
  --agree-tos

The -d "yourdomain.com" is required separately because wildcards don’t cover the root domain by default. This command gets you both *.yourdomain.com and yourdomain.com in one certificate.

Option 2: Paid Certificate Authority (OV or EV)

For business validation, purchase a wildcard certificate from a CA like DigiCert, Sectigo, or through CWH’s SSL certificates. The process:

  1. Generate a CSR (Certificate Signing Request) with *.yourdomain.com as the common name
  2. Submit to CA with business documentation for OV/EV validation
  3. Complete validation — CA verifies domain control and organisation identity
  4. Receive certificate — typically within 1-3 days for OV, 3-7 days for EV
  5. Install on server — configure web server to use the certificate

Server Configuration Example (Nginx)

server {
    listen 443 ssl;
    server_name api.yourdomain.com;
    
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    
    # Same certificate file works for any *.yourdomain.com subdomain
    # No per-subdomain configuration needed
}

Security Best Practices for Wildcard Certificates

1. Protect the Private Key

The wildcard private key provides access to all subdomains. Store it securely, use strong file permissions (600 or 400), and never commit it to version control. Consider using a secrets management system for distribution.

2. Consider Key Rotation

If you suspect a private key may have been exposed, rotate it immediately. With a wildcard, you’ll need to update every server using that certificate. Document which systems use the wildcard for faster incident response.

3. Monitor Certificate Expiry

Set up monitoring for certificate expiration. When a wildcard expires, all your subdomains lose HTTPS simultaneously. Use automated renewal (Let’s Encrypt) or calendar alerts 30 days before expiry (paid certificates).

4. Use Different Certificates for Different Security Zones

Even with a wildcard, consider separate certificates for:

  • Public-facing services (*.yourdomain.com)
  • Internal tools (*.internal.yourdomain.com)
  • Development/staging (*.staging.yourdomain.com)

This limits blast radius if a key is compromised and provides audit separation.

5. Log Certificate Usage

Maintain an inventory of which servers and services use the wildcard certificate. When renewal time comes, you need to know every location that needs updating.

Common Questions

“Does a wildcard cover mydomain.com too?”

Most certificate authorities issue wildcards that cover both *.yourdomain.com and yourdomain.com, but you typically need to specify both in your certificate request. With Let’s Encrypt, include both -d "*.yourdomain.com" and -d "yourdomain.com".

“Can I get an EV wildcard?”

Yes, EV wildcard certificates exist but are less common. They provide the same extended validation as regular EV certificates but cover multiple subdomains. The cost is significantly higher than OV wildcards.

“What happens if I need to revoke a wildcard?”

Revocation affects all subdomains immediately. You’ll need to obtain a new certificate and deploy it to every server. This is one reason to consider certificate segmentation for critical services.

“Can I use Let’s Encrypt wildcards in production?”

Yes, but be aware of the trade-offs: 90-day certificate lifetime requires reliable automation, DV validation only (no organisation identity), and no warranty. For many production workloads, this is acceptable. For business-critical applications, paid OV certificates with longer validity and support may be preferable.

Where CWH Fits

Canadian Web Hosting offers wildcard SSL certificates as part of our SSL certificate lineup. Here’s what makes sense for different scenarios:

Your Situation Recommendation
Small business with 3-5 subdomains Wildcard OV certificate
Personal projects, budget-conscious Let’s Encrypt wildcard (free)
E-commerce with multiple subdomains Wildcard OV for general use, individual EV for checkout/login
Healthcare, financial services Individual certificates per service for compliance
Multiple different domains (.com, .ca, .net) Multi-domain (SAN) certificate

When you get a wildcard through CWH:

  • Canadian data residency — certificate issuance and support handled in Canada
  • Installation included — we handle CSR generation and installation on your hosting account
  • Auto-renewal available — never let a certificate expire unexpectedly
  • 24/7 support — real humans if something goes wrong with your SSL

Decision Checklist

Use this checklist to decide if a wildcard certificate is right for you:

  • ? Do you have 3+ subdomains under the same domain?
  • ? Do subdomains share a similar security level?
  • ? Is certificate management overhead a concern?
  • ? Do you need rapid environment spin-up capability?
  • ? Are you okay with DV-level trust (Let’s Encrypt) or willing to pay for OV?

If yes to most: A wildcard certificate is likely the right choice.

  • ? Do you handle financial or healthcare data?
  • ? Do you need different validation levels for different subdomains?
  • ? Does compliance require certificate segmentation?
  • ? Do you provide subdomains to external customers?

If yes to any: Consider individual certificates for isolation.

Next Steps

  • Audit your current subdomains — list every HTTPS endpoint under your domain
  • Check your current certificates — are you already using wildcards? Are they expiring soon?
  • If considering a wildcard, evaluate your security requirements — can you accept shared key material?
  • Browse CWH’s SSL certificate options for wildcard availability and pricing
  • After installation, test with SSL Labs to verify proper configuration
  • Read our SSL certificate types guide for the full DV/OV/EV comparison
  • For broader server security, see our VPS security hardening guide

A wildcard certificate is a tool — powerful when used correctly, risky when misapplied. Match the certificate architecture to your security requirements, not just your budget.