cPanel AutoSSL Won't Cover Your Wildcard Subdomain? Fix It

Your main domain has a nice green padlock, AutoSSL renewed it on schedule, everything looks fine — and then a customer emails you because blog.yourdomain.com or app.yourdomain.com is throwing "Not Secure" or NET::ERR_CERT_COMMON_NAME_INVALID. If you've ever assumed AutoSSL would just cover every subdomain you create, this is the ticket that proves it doesn't.

Symptom: One Domain Is Secure, Every Subdomain Isn't

The pattern is almost always the same. You check SSL/TLS Status in cPanel and the primary domain shows a valid, auto-renewing certificate. But any subdomain — especially a wildcard-style setup where you're spinning up new subdomains programmatically (multi-tenant SaaS, staging environments, client subdomains) — either has no certificate at all, or is riding on a certificate that doesn't list it in the Subject Alternative Names (SAN).

Browsers are strict about this. A certificate issued for yourdomain.com and www.yourdomain.com does nothing for anything.yourdomain.com unless that exact hostname is in the SAN list — or the cert is a genuine wildcard (*.yourdomain.com).

Why AutoSSL Skips Wildcards by Default

This isn't a bug, it's how the two validation methods work:

• HTTP-01 validation — AutoSSL's default method. It drops a token file on your server and asks the certificate authority to fetch it over http://hostname/.well-known/.... This proves you control that exact hostname, one at a time. It cannot prove you control every possible subdomain that might ever exist, so it can't issue a wildcard.
• DNS-01 validation — the only method that can issue a wildcard. It requires you to publish a specific _acme-challenge TXT record in DNS. Proving control of the DNS zone is treated as proof you control every subdomain under it, which is why this method unlocks wildcards.

cPanel's built-in AutoSSL (whether the provider is Sectigo or Let's Encrypt) uses HTTP-01 by default on shared hosting, which is exactly why it quietly skips wildcards and only secures hostnames it can directly verify — and only ones that already exist and resolve at the time AutoSSL runs.

Step 1: Rule Out the Easy Cause First

Before chasing wildcard certificates, check whether AutoSSL simply hasn't run since you created the subdomain:

1. In cPanel, go to Security > SSL/TLS Status.
2. Find the subdomain in the list. If it shows a red "Not Secure" or is missing entirely, tick it and click Run AutoSSL.
3. Give it a few minutes, then reload. AutoSSL issues certificates one hostname at a time, so a large account with many subdomains can take a while to work through the queue.

If the subdomain still fails after a manual run, check that it actually resolves to your server's IP first:

dig +short newsub.yourdomain.com

If that returns nothing, or an old IP, AutoSSL's HTTP-01 check will never succeed — fix the DNS record before touching certificates at all.

Step 2: If You Genuinely Need a Wildcard

If you're creating subdomains faster than you can wait for AutoSSL to catch up — or you want one certificate to cover an unlimited number of future subdomains — you need an actual wildcard cert, issued via DNS-01. Your options depend on what kind of access you have.

Option A: You Have WHM/Root Access

Newer cPanel/WHM builds can request wildcard AutoSSL certificates automatically, but only when both of these are true:

• The AutoSSL provider is set to Let's Encrypt (WHM > SSL/TLS > Manage AutoSSL > Providers).
• A supported DNS provider plugin (Cloudflare, Route 53, etc.) is installed and authorized in WHM, so cPanel can create the TXT record for you automatically instead of asking you to paste it in by hand.

Without a DNS plugin, WHM has no way to complete DNS-01 validation on its own, and it falls back to HTTP-01 — which, again, cannot issue wildcards.

Option B: No WHM Access, Just cPanel

If you're on shared hosting with cPanel-only access, you can't configure AutoSSL providers, but you can still get a wildcard cert manually using acme.sh from any machine with SSH — your own laptop, a small VPS, whatever — and then upload it to cPanel.

# On any machine with SSH and acme.sh installed
acme.sh --issue -d yourdomain.com -d '*.yourdomain.com' \
  --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please

This prints a TXT record you need to publish, something like:

_acme-challenge.yourdomain.com  TXT  "gfj9Xq...random-string..."

Add it in cPanel under Domains > Zone Editor > yourdomain.com > Manage > Add Record, wait for it to propagate (a minute or two on most setups, longer on old NS), then finish the issuance:

acme.sh --renew -d yourdomain.com \
  --yes-I-know-dns-manual-mode-enough-go-ahead-please

You'll end up with three files: the certificate, the private key, and the CA bundle. Take all three into cPanel:

1. Security > SSL/TLS > Install and Manage SSL for your site.
2. Select the domain, paste the Certificate (CRT), Private Key (KEY), and Certificate Authority Bundle (CABUNDLE) into their respective boxes.
3. Click Install Certificate.

The catch: this cert isn't managed by AutoSSL, so it won't renew itself. Let's Encrypt wildcards expire in 90 days — put a calendar reminder or a cron job on the machine running acme.sh to re-issue and re-publish the TXT record before then, or the subdomain will silently go back to "Not Secure" three months from now.

Option C: Skip Server-Side Wildcards Entirely

If you don't want to babysit renewals, put Cloudflare in front of the domain and set SSL/TLS mode to Full (or Full (strict) if your origin cert is valid). Cloudflare's edge certificate covers *.yourdomain.com for free and handles renewal itself — visitors get a secure connection to Cloudflare even if the origin-to-Cloudflare leg is using a plain AutoSSL cert for the main domain only.

Which Route Should You Take?

Prevention

• If you're building anything that creates subdomains dynamically (multi-tenant apps, client staging sites), plan for a wildcard from day one instead of discovering the gap in production.
• If you went the manual acme.sh route, automate the renewal — a simple cron job that re-issues and re-publishes the TXT record beats a manual reminder that gets missed.
• Check SSL/TLS Status in cPanel periodically rather than only when a customer reports the warning — it lists every hostname and whether it's currently covered.

The Bottom Line

AutoSSL not covering a subdomain almost never means anything is broken — it means the certificate authority genuinely can't validate a hostname it hasn't been asked to check, or can't prove wildcard ownership without DNS-level access it wasn't given. Once you know which of the three routes above matches your access level, the fix is usually a 15-minute job rather than a mystery.