SSL Works on Main Domain, Fails on Subdomain? Fixes Here

1. Wrong or Missing Wildcard Certificate

I know this error is infuriating. You check the main site—green padlock, all good. Then you type blog.yoursite.com and get a big red warning. The most common reason? Your SSL certificate doesn't cover the subdomain.

Here's the thing: a standard single-domain certificate (like the free Let's Encrypt one) covers only yoursite.com and www.yoursite.com. That's it. For subdomains like api.yoursite.com or shop.yoursite.com, you need either:

• Wildcard certificate — covers *.yoursite.com plus the root domain.
• SAN (Subject Alternative Name) certificate — you list every subdomain you need (e.g., api.yoursite.com, mail.yoursite.com).

If you're using Let's Encrypt with certbot, you generate a wildcard like this:

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

That uses DNS challenge, not HTTP. You need to add a TXT record to your DNS zone. This tripped me up the first time too—you can't skip the DNS step. If you skip it, the certificate won't validate.

After you get the wildcard cert, make sure it's assigned to the subdomain in your server config. In Apache, check your .conf file for the subdomain. The SSLCertificateFile and SSLCertificateKeyFile should point to the wildcard cert files, not the single-domain one.

2. Server Block or VirtualHost Missing for Subdomain

Second most common cause: your web server doesn't have a separate config block for the subdomain. So it falls back to the default server, which might not have SSL enabled or points to the wrong directory.

For Nginx, you need a separate server block for the subdomain. A typical setup looks like this:

server {
    listen 443 ssl;
    server_name blog.yoursite.com;

    ssl_certificate /etc/letsencrypt/live/yoursite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yoursite.com/privkey.pem;

    root /var/www/blog;
    index index.php index.html;
}

Notice the server_name is the subdomain. If you put yoursite.com there instead, the subdomain will either fail or redirect. Also, the root directory must exist and contain your subdomain's files. I once spent an hour debugging a 404 error because the folder was named blog but I typed bloger in the config.

For Apache, you need a block for the subdomain. Check your sites-available folder. If it's missing, create one and enable it with a2ensite.

3. DNS or Cloudflare SSL Settings

Third cause—and this one sneaks up on people using Cloudflare or other CDNs. You have a valid SSL on the server, but Cloudflare's proxy is interfering. If you use Cloudflare, you have two options:

• Full (strict) — requires a valid SSL on your origin server for both main domain and subdomain. This is what you want.
• Flexible — only encrypts between visitor and Cloudflare, not between Cloudflare and your server. Not recommended for sensitive data.

Log in to Cloudflare, go to SSL/TLS > Overview, and set it to Full (strict). Then check the DNS records for your subdomain—make sure the orange cloud (proxy) is enabled. If it's gray (DNS only), Cloudflare won't handle SSL for it.

Also check your DNS A or CNAME record for the subdomain. It should point to your server's IP (if A record) or to the main domain (if CNAME). If it points to an old IP, you'll get certificate errors.

Quick-Reference Summary

Start with the certificate check—it's the most common issue I've seen in 6 years of help desk work. If that's not it, move to the server config. And if you use a CDN, always check their SSL mode. You'll have your subdomain green in no time.