Why Your SSL Certificate Is Not Working After Connecting a Domain

You just connected your domain to your hosting — pointed the nameservers, updated the DNS, everything the guide said. The site loads… but instead of the padlock, your browser shows a warning: the certificate is invalid, untrusted, or "not for this domain." What went wrong?

Here's the reassuring part: this is one of the most common SSL problems, and it's almost always one of a handful of causes — DNS that hasn't caught up, or a certificate that was issued for a different hostname than the one you're visiting. This guide explains the real reasons in plain English and walks you through the fix in the right order, so you stop guessing.

The Short Version: It's Almost Always DNS or the Certificate's Name List

An SSL certificate does exactly two things: it encrypts the connection, and it proves which hostname you're connected to. When you connect a new domain, both of those things can break:

1. DNS still points somewhere else — your browser never even reaches your new host, so it sees the old host's certificate (or none at all).
2. The certificate's name list doesn't include your domain — the certificate was issued for example.com but you're visiting www.example.com, or it was issued before the domain was properly connected.

Fix the DNS, then make sure the certificate covers every hostname you use. That's the whole game. The rest of this article shows you exactly how to check each one.

How SSL and a New Domain Connection Relate

Two facts make everything else in this guide click:

Certificates are issued for exact hostnames, not for "your website" in general

An SSL certificate is not a blanket pass for your website. It contains a list of exact hostnames it is valid for — the Subject Alternative Name (SAN) list. A certificate issued for example.com is not automatically valid for www.example.com, and neither covers blog.example.com. Browsers compare the hostname in the address bar against that list character by character; any mismatch produces an error. (This is documented behaviour — Microsoft's own support write-ups list hostname mismatch as the first cause of certificate validation failures.)

The certificate authority must verify you control the domain — via DNS

Before any authority (Let's Encrypt, or your host's built-in SSL system) issues a certificate, it has to prove you control the domain. The most common proof is DNS-based: the authority checks that your domain's DNS records point where you say they do. If your DNS is wrong, half-propagated, or still pointing at your old host, validation fails — and the certificate either never gets issued or gets issued covering only the names that could be validated.

This is why "I connected the domain, then installed SSL" so often breaks: the domain connection (DNS) and the certificate are two separate steps, and the second one depends on the first being fully finished.

Reason 1: Your DNS Isn't Pointing at the New Host Yet

The single most common cause. You changed nameservers or A records an hour ago, installed (or auto-installed) SSL, and now the browser shows a certificate error.

What's actually happening: your browser is connecting to your old host, not the new one. The old host serves whatever certificate it has — possibly an old certificate for your domain, possibly a generic server certificate, possibly nothing. The error you see has nothing to do with your new certificate, because the browser never reaches it.

There's a documented real-world version of this: a Cloudflare community case where a custom domain sat at "Verifying" for 20+ hours with TLS handshake failures — the root cause turned out to be that the domain was never actually delegated to Cloudflare's nameservers at the registrar. The dashboard said "Active," but traffic was going to the old host. The lesson: don't trust dashboards — verify DNS yourself.

How to check where your domain actually points

• Use a propagation checker like whatsmydns.net — enter your domain, select "A", and see which IP address the world resolves it to. Compare that IP with your hosting account's server IP.
• From a terminal: nslookup -type=NS yourdomain.com shows which nameservers the domain is actually delegated to. If they aren't your host's nameservers, delegation hasn't happened (or was reverted).
• Query the registry directly (ignores all caches): for .com, https://rdap.verisign.com/com/v1/domain/yourdomain.com shows the authoritative nameservers.

If DNS doesn't point at your new host yet, stop troubleshooting SSL — fix DNS first, then come back.

The "old host's certificate" trap

Here's the trap to recognize: the browser shows a certificate error, and the certificate details show your old host's name, a CDN's name, or something you don't recognize. That's proof the browser connected to the wrong server. No amount of reinstalling SSL on your new host will fix it, because the new host isn't in the conversation yet.

Reason 2: The Certificate Doesn't List Your Domain (Hostname Mismatch)

DNS is correct, the site reaches your host — but the browser still complains. Now look at the certificate itself.

The www vs non-www trap

This is the classic: your certificate covers example.com, and you visit www.example.com (or the reverse). The browser sees a hostname that isn't on the certificate's list and throws ERR_CERT_COMMON_NAME_INVALID or similar. It also bites when you redirect: if you redirect non-www to www but the certificate only covers the non-www name, visitors hit the error before the redirect ever runs (SiteGround's KB documents exactly this redirect scenario).

The fix is to reissue the certificate so its SAN list includes every hostname you use — at minimum, both example.com and www.example.com. On managed hosting this is usually a checkbox or a "reinstall SSL" button. On a VPS with Certbot, it's -d example.com -d www.example.com.

How to read a certificate's name list in your browser

Don't guess — look:

1. Click the padlock (or the "Not secure" warning) in the address bar.
2. Open Certificate / Connection is secure → Certificate details.
3. Find the Subject Alternative Name section. It lists every hostname the certificate is valid for.

Compare that list against the hostname you're visiting. If your domain isn't there, you've found the problem: the certificate needs reissuing with the right names.

Reason 3: You Installed the Certificate Before DNS Finished Propagating

This one is subtle and extremely common. You pointed the domain, then immediately clicked "install SSL" in your hosting panel. The certificate authority tried to validate your domain — but DNS propagation was still in flight.

What happens, per SiteGround's SSL documentation: the authority validates whatever names it can reach. Your example.com A record may have propagated to the authority's servers while www.example.com hadn't — so the issued certificate covers the root domain but not www. Or validation fails entirely and you're left with an error like "Certificate is not for the chosen domain."

DNS propagation can take up to 72 hours (usually much less, but the safe assumption matters here). The rule:

1. Point your DNS first.
2. Verify with a propagation checker that the records are stable worldwide.
3. Then install or reinstall the SSL certificate.

If you already installed too early, the fix is simple: wait until propagation is complete, then reinstall the certificate so it's issued against the now-stable DNS.

Reason 4: A CAA Record Is Blocking Issuance

Less common, but worth knowing. DNS has a record type called CAA (Certification Authority Authorization) that lets a domain owner say "only these certificate authorities may issue certificates for my domain." If your domain has a CAA record naming a different authority than the one your host uses (say, it only allows one commercial CA, but your host issues via Let's Encrypt), every issuance attempt silently fails.

Check for a CAA record with any DNS lookup tool (whatsmydns.net supports CAA queries). If one exists and doesn't include your host's authority, either add the authority or remove the record, then reissue.

Reason 5: Your Site Still Loads Some Content Over HTTP (Mixed Content)

Sometimes the certificate is perfectly fine, but the browser still won't show a full padlock — it says the page is "not fully secure." That means the page itself loads over HTTPS, but some of its resources (images, scripts, stylesheets) still load over plain HTTP. Browsers distrust the mixture.

Quick check: open your browser's developer tools (F12), go to the Console tab, and reload the page — mixed-content warnings list the exact offending URLs. The usual fix is updating those URLs to HTTPS (or relative paths). This is a big enough topic to deserve its own walkthrough — see our guide on fixing mixed content errors after enabling HTTPS — but know that it's a content problem, not a certificate problem: reinstalling SSL won't help.

Reason 6: WordPress (or Your App) Still Thinks It's on HTTP

If you run WordPress, there's one more layer. WordPress stores its own address in Settings → General as "WordPress Address (URL)" and "Site Address (URL)." After connecting a domain and enabling SSL, both must start with https://. If they still say http://, WordPress keeps generating HTTP links and redirects, which can produce redirect loops or keep the browser from ever settling on a secure page — even with a valid certificate installed.

Update both fields to the HTTPS version of your domain (using the exact hostname your certificate covers), save, and clear any caching plugin.

The Step-by-Step Fix, in Order

Do these in sequence. Most people find the problem by step 3 or 4.

Step 1 — Confirm DNS points to the right server

Check your domain's A record (and nameservers, if you changed those) with a propagation tool. The IP must match your hosting account's server IP. If it doesn't, fix DNS and stop here — nothing else matters until this is right.

Step 2 — Wait out propagation if you just changed DNS

If you changed DNS within the last day or two, give it time. Don't install or reinstall SSL while records are still settling; you'll just get a half-valid certificate. Verify stability on a propagation checker first.

Step 3 — Inspect the certificate your browser actually receives

Click the padlock/warning → certificate details → Subject Alternative Name list. Ask three questions:

• Is my domain on the list? (If no → reissue with the right names.)
• Does it cover both www and non-www? (If no → reissue covering both.)
• Is it issued to some other host entirely? (If yes → your DNS is still pointing at the old server; go back to step 1.)

Step 4 — Reinstall/reissue the certificate covering all hostnames

With DNS stable and correct:

• Managed hosting: use the panel's SSL installer/"reinstall SSL" option. Make sure both yourdomain.com and www.yourdomain.com are selected (SiteGround's KB stresses that both A records must point at your server for this to succeed).
• VPS (Certbot): reissue with all names, e.g. -d yourdomain.com -d www.yourdomain.com, and make sure the web server reloads afterward so it serves the new certificate.

Step 5 — Clear every layer of cache and test clean

Browsers cache certificate errors aggressively. Test in a private/incognito window, or clear the browser cache. If you use a CDN or caching plugin, purge that too. Then re-check with an independent SSL checker (ssllabs.com/ssltest or sslshopper.com) to see what the world sees, not just your browser.

Step 6 — Update your site's settings to HTTPS

In WordPress: Settings → General, set both URLs to https://. In other apps/CMSs, find the base-URL or site-address setting and do the same. Then scan for mixed content (Reason 5) and fix any HTTP resource URLs.

Gotchas That Catch People

Retrying issuance too fast triggers rate limits

Let's Encrypt limits how many certificates you can request for a domain in a given period. Hammering "reinstall" every few minutes while DNS is still propagating can land you on a 429 Too Many Requests error — and then you're locked out of retrying for a while. Fix DNS first, verify it's stable, then issue once. Patience here literally saves you days.

The padlock looks fine to you but broken for visitors

Your browser may be seeing a cached or locally-resolved version of DNS while the rest of the world sees something else. Always verify with an external checker (propagation tool + independent SSL test), not just your own browser.

"It works without www but not with www" is the same bug

This is just the hostname-mismatch case wearing a different hat (Reason 2). One certificate, one missing SAN entry. Reissue covering both names and it disappears.

Frequently Asked Questions

I just pointed my domain to hosting — how long before SSL works?

Give DNS propagation up to 24–72 hours, though it's often much faster. The practical sequence: point DNS → verify it's stable worldwide with a propagation checker → then install/reinstall SSL. Installing the certificate before DNS settles is the #1 reason it ends up broken. If your host auto-installs SSL, check after propagation that the certificate actually covers your domain (padlock → certificate details).

SSL works on www but not the root domain (or vice versa) — why?

Your certificate's name list (SAN) only includes one of the two hostnames. Browsers match the address-bar hostname against that list exactly. Reissue the certificate including both yourdomain.com and www.yourdomain.com and the error goes away.

The browser says the certificate belongs to a different/old domain. What's going on?

Your DNS is still pointing at the old server (or a CDN/proxy you no longer use). The browser is connecting to that old server and receiving its certificate. Check your A records and nameserver delegation — fix DNS first, then reinstall SSL once traffic actually reaches your new host.

I reinstalled the SSL certificate but the error is still there. What now?

Three usual suspects: (1) Cache — test in incognito and purge any CDN/plugin cache; (2) the reinstall didn't cover all names — re-check the certificate's SAN list in your browser; (3) the server is still serving the old certificate — on a VPS, the web server must reload after renewal/reissue. Verify with an independent SSL checker to see what the world receives.

Why does Let's Encrypt keep failing with "too many requests"?

You've hit Let's Encrypt's rate limits by requesting certificates too many times in a short window — typically from retrying while DNS was still propagating. Stop requesting, fix the underlying DNS issue, verify it's stable, and try again later. In the worst case the limit window can last up to a week, which is why you should never spam the install button.

Do I need a new certificate every time I add a subdomain?

Only if the new subdomain isn't on the certificate's name list. A standard certificate covers exactly the hostnames you requested. If you plan to use many subdomains, a wildcard certificate (*.yourdomain.com) covers all of them at once — ask your host whether their SSL offering includes one, or reissue adding each new subdomain as you create it.

Connecting a new domain? Do the DNS part right first — our complete domain registration guide walks you through pointing a domain at hosting step by step. And if HTTPS still misbehaves after that, work through the six steps above in order — one of them is your answer.