Wildcard SSL Certificates Explained: What They Cover, What They Don’t, and When to Use One

Overview

A wildcard SSL certificate secures one domain and all of its first-level subdomains using a single certificate. Instead of issuing separate certificates for shop.example.com, blog.example.com, and mail.example.com, you install one wildcard SSL and all three are covered automatically. The wildcard part is the asterisk in the certificate’s common name: *.example.com.

You’ll typically run into this topic when you’re scaling a site that’s outgrown its original structure. Maybe you started with a single WordPress install and now you’re spinning up subdomains for client portals, staging environments, or regional storefronts. Managing individual certificates for each one gets tedious fast, and that’s exactly the problem wildcard SSL solves.

This article explains how wildcard SSL works, what it covers and what it doesn’t, how to request one through common hosting control panels, and the gotchas that catch people off guard.

Prerequisites

• Domain ownership and access to your DNS zone (through your registrar or your hosting control panel)
• Access to cPanel, WHM, Plesk, or your server’s command line depending on your hosting type
• A certificate authority (CA) account if you’re using a paid certificate — or Certbot installed if you’re going the Let’s Encrypt route
• Basic understanding of what a subdomain is
• DNS propagation can take up to 48 hours after making changes — plan for that before going live

How Wildcard SSL Actually Works

When a CA issues a wildcard certificate for *.example.com, the asterisk is a placeholder that matches exactly one level of subdomain. That’s it. One level.

So *.example.com covers:

• www.example.com
• shop.example.com
• api.example.com
• staging.example.com

It does not cover:

• example.com itself (the root domain) — unless your CA explicitly includes it as a Subject Alternative Name (SAN), which many do now but not all
• dev.api.example.com — that’s a second-level subdomain and falls outside the wildcard’s scope

That second point is the most common source of confusion I see on support tickets. A customer installs a wildcard cert and then wonders why dev.staging.example.com is throwing a certificate error. The cert was never going to cover it. If you need second-level subdomains secured, you’ll need either a separate certificate for each, or a multi-domain (SAN) certificate that lists them explicitly.

Wildcard SSL vs. Standard SSL vs. Multi-Domain SSL

Here’s a quick comparison so you can choose the right certificate type for your setup:

• Standard (single-domain) SSL — covers one domain or subdomain only. Cheapest option. Right for a single site.
• Wildcard SSL — covers one domain and all its first-level subdomains. Best when you have or expect multiple subdomains under one root domain.
• Multi-domain (SAN) SSL — covers a specific list of domains and subdomains you define at issuance. More flexible but requires reissuance every time you add a new domain. Good for agencies managing different client domains on one server.

If you’re hosting several distinct websites on a Shared Hosting plan, a standard SSL per domain is usually sufficient. If you’re on one of our VPS plans and running a multi-tenant SaaS or e-commerce platform with customer subdomains, a wildcard cert is almost always the smarter call.

Requesting a Wildcard SSL Certificate

Option 1: Let’s Encrypt via Certbot (Command Line)

Let’s Encrypt supports wildcard certificates, but they require DNS-01 challenge validation — you can’t use the standard HTTP challenge for wildcards. This means you need to add a TXT record to your DNS zone to prove domain ownership.

1. Run the following command to request a wildcard certificate with manual DNS validation:

   Copied to clipboard

   sudo certbot certonly 
     --manual 
     --preferred-challenges dns 
     -d example.com 
     -d "*.example.com"

   Including both example.com and *.example.com ensures your root domain is also secured — otherwise it won’t be.

2. Certbot will pause and ask you to create a DNS TXT record like this:

   Copied to clipboard

   Please deploy a DNS TXT record under the name:
   _acme-challenge.example.com
   with the following value:
   aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567890abcde

   Log into your DNS provider and add that exact TXT record before pressing Enter to continue.

3. Wait for DNS to propagate. You can check propagation with:

   Copied to clipboard

   dig TXT _acme-challenge.example.com +short

   Once it returns the correct value, go back to the Certbot prompt and confirm.

4. Your certificate files will be saved to:

   Copied to clipboard

   /etc/letsencrypt/live/example.com/fullchain.pem
   /etc/letsencrypt/live/example.com/privkey.pem

⚠ Warning: Let’s Encrypt wildcard certificates expire every 90 days. Manual DNS validation doesn’t support automated renewal — you’ll need to set up a DNS plugin for your provider (e.g., Certbot’s Cloudflare or Route53 plugins) to automate this. If you forget to renew, all your subdomains go down at once. That’s a painful lesson.

Option 2: Installing a Wildcard Certificate in cPanel / WHM

If you purchased a wildcard certificate from a commercial CA (e.g., Sectigo, DigiCert), you’ll have a certificate file, a private key, and usually a CA bundle.

1. Log into WHM as root or reseller.
2. Navigate to SSL/TLS > Install an SSL Certificate on a Domain.
3. In the Domain field, enter your root domain: example.com.
4. Paste your certificate contents into the Certificate (CRT) field.
5. Paste your private key into the Private Key (KEY) field.
6. Paste the CA bundle into the Certificate Authority Bundle (CABUNDLE) field.
7. Click Install Certificate.

📝 Note: In cPanel, a wildcard cert installed on the root domain does not automatically apply to subdomains that have their own dedicated IP or Apache VirtualHost entries. Each subdomain’s VirtualHost needs to reference the same certificate, or you’ll still see errors on those subdomains. In WHM, you can use Manage SSL Hosts to verify which domains are actually using the cert.

Option 3: Plesk

1. Go to Domains > select your domain > SSL/TLS Certificates.
2. Click Add SSL/TLS Certificate.
3. Enter a name (e.g., wildcard-example-com), paste your certificate, private key, and CA certificate into their respective fields.
4. Click Upload Certificate.
5. Return to the domain’s Hosting Settings and select this certificate from the SSL/TLS dropdown.

Common Issues and Troubleshooting

Second-Level Subdomains Show a Certificate Error

Symptom: dev.api.example.com throws a NET::ERR_CERT_COMMON_NAME_INVALID error even though the wildcard is installed.

Cause: Your wildcard cert (*.example.com) only covers one subdomain level. dev.api.example.com is two levels deep and simply isn’t in scope.

Fix: Either restructure your subdomain naming (e.g., dev-api.example.com instead), or obtain a separate certificate for *.api.example.com — yes, wildcards can exist at deeper levels, you just need a separate cert for each level.

Root Domain Not Covered by the Wildcard

Symptom: www.example.com loads fine over HTTPS but example.com shows a certificate warning.

Cause: *.example.com does not automatically include the apex domain example.com. These are technically separate entries.

Fix: When requesting your certificate, always include both example.com and *.example.com as SANs. For Let’s Encrypt, pass both -d example.com -d "*.example.com" in the Certbot command. For commercial CAs, check at order time — most include the root domain automatically, but confirm before you pay.

Let’s Encrypt Wildcard Won’t Auto-Renew

Symptom: The certificate expires and your cron job didn’t renew it automatically.

Cause: Wildcard renewal via Let’s Encrypt requires DNS-01 challenge, which can’t be fully automated without a DNS API plugin. If you set up the cert manually, there’s no way for Certbot to complete DNS validation unattended.

Fix: Install the appropriate Certbot DNS plugin for your DNS provider. For Cloudflare:

sudo pip install certbot-dns-cloudflare
sudo certbot renew --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/cloudflare.ini

Then add certbot renew to a cron job or systemd timer. Check Certbot’s documentation for a full list of supported DNS plugins.

Mixed Content Warnings After Installing Wildcard SSL

Symptom: The padlock icon appears broken or shows a warning in the browser even though the cert is installed correctly.

Cause: The certificate is fine — the problem is that your page is loading some resources (images, scripts, stylesheets) over HTTP instead of HTTPS. This is a content issue, not a certificate issue.

Fix: Use your browser’s developer tools (F12 > Console) to identify which URLs are loading over HTTP. Update them to HTTPS. For WordPress sites, the Really Simple SSL plugin or a search-and-replace in the database usually clears this up quickly.

Certificate Not Applying to All Subdomains on Apache

Symptom: Some subdomains still show the old certificate or the hosting provider’s default certificate.

Cause: Each subdomain with its own VirtualHost block in Apache needs to explicitly reference the wildcard certificate. Apache won’t automatically pick up a cert installed on the parent domain.

Fix: Edit the VirtualHost block for each subdomain and add the correct certificate paths:

SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Then reload Apache: sudo systemctl reload apache2

FAQ