SSL Not Working on Shared Hosting: How to Fix It? 

Key highlights 

• Rule out propagation delay first. A new certificate can take up to 24 hours to activate. 

• Treat a “mixed content” warning as a working certificate. Some page resources are just still loading over HTTP. 

• Clear the browser cache or open a private window before assuming the certificate itself is broken. 

• Reissue the certificate if it only covers one domain variant, www or non-www. 

• Check the renewal date before digging further. A failed or missed auto-renewal is another common reason an SSL certificate may suddenly stop working. 

“Your connection is not private.” That warning replaces the padlock without explanation. Nothing changed in the SSL settings. No plugin was installed and no code was changed. The site works exactly as it did yesterday, yet the browser flags it as unsafe. 

SSL not working on shared hosting almost always traces back to one specific break, not a compromised site. Seven causes account for nearly every case: a certificate still propagating, mixed content, a cached browser warning, a domain mismatch, an expired renewal, a broken redirect or a CDN conflict. This guide checks each one in order, starting with the cause that catches new sites most often: a certificate that hasn’t finished installing yet. 

Quick summary table 

Here’s every cause and its fast fix before the deep dive. Match your exact browser warning against the symptom column to jump straight to the section that applies. 

S. No	Cause	Symptom	Fast fix
1	Certificate still propagating	Warning appears right after setup or a DNS change	Wait up to 24 hours, then recheck
2	Mixed content	Padlock shows but with a warning icon or “Not fully secure”	Update HTTP resource links to HTTPS
3	Cached browser warning	Warning persists after the certificate was already fixed	Clear cache, retest in a private window
4	Domain mismatch	Works on one of www or non-www, fails on the other	Reissue the certificate for both
5	Expired or failed renewal	Site worked fine for months, then broke suddenly	Check expiration, force a reissue
6	Broken redirect rule	Redirect loop or “too many redirects” error	Fix the HTTP to HTTPS rule in .htaccess
7	CDN or plugin conflict	Error only appears through a specific CDN or after a plugin update	Match SSL mode between CDN and host

Each section below expands one row, starting with the cause that catches new setups most often. 

1. Your SSL certificate hasn’t finished installing yet 

A warning that shows up minutes after you point a domain or finish hosting setup usually isn’t a broken certificate. It’s an incomplete one. Certificate issuance depends on DNS resolving first, and DNS doesn’t update everywhere at once. 

Check propagation status 

Run your domain through a DNS checker like [whatsmydns].net. If results are inconsistent across locations, propagation is still in progress and the certificate can’t fully validate yet. Confirm the same domain on an SSL checker like SSL Labs. A grade or valid result there, paired with incomplete DNS propagation, confirms the certificate is fine and just needs time to catch up everywhere. 

What normal setup delay looks like 

Once DNS resolves, Let’s Encrypt issuance itself usually completes within minutes. The bottleneck is almost always DNS propagation, which can take up to 24 hours and occasionally longer depending on your registrar’s TTL setting. 

Pro tip: If you’re still inside that 24-hour window, skip every other fix on this list. Changing SSL settings while propagation is mid-flight can create a second problem on top of the first. 

2. Mixed content is causing your SSL certificate error 

A padlock that shows with a warning triangle, or a browser message reading “Not fully secure,” almost always means the certificate itself is valid. Some elements on the page (an image, a script, a stylesheet) are still loading over HTTP instead of HTTPS, and the browser flags the mismatch. 

Find the insecure resources 

Open the browser’s developer console (F12, then the Console tab) and reload the page. Blocked or flagged requests show up there labeled “Mixed Content,” each one naming the exact HTTP resource causing the warning. A free scanner like Why No Padlock does the same check without opening dev tools, useful if you want a full-page report instead of checking line by line. 

Old hardcoded links are the usual source: a theme file, a plugin setting or leftover database entries from before the site moved to HTTPS. 

Fix mixed content on WordPress vs. static HTML 

On WordPress, update the Site Address and WordPress Address fields under Settings > General to the HTTPS version first. Then run a database search-and-replace, either through a plugin like Better Search Replace or with WP-CLI, to swap every remaining http:// reference to https://.  A plugin such as Really Simple Security can also help configure HTTPS and address mixed content if you’d rather not make these changes manually. 

 On a static HTML site, update HTTP references in the href and src attributes to HTTPS. For resources hosted on the same domain, you can also use relative paths instead of hardcoded HTTP URLs. 

Also read: How to Fix ERR_SSL_PROTOCOL_ERROR – Easy SSL Troubleshooting 

3. Your browser is showing a cached SSL connection error 

A warning that persists after you’ve already fixed the certificate usually means the browser, not the site, is the problem. Browsers and DNS resolvers cache certificate data and don’t always recheck it right away. 

Clear cache and test in a private window 

Open a private or incognito window and load the site there first. A private window skips the local cache entirely, so if the warning disappears, the fix already worked and only your regular browser session is stale. 

If it still shows the warning in private mode, clear the browser’s cached images and files (not just cookies) and reload. On a shared or public network, also try a different network or device. Some ISPs and corporate DNS resolvers hold onto old certificate data longer than the browser does. 

4. The certificate doesn’t cover both www and non-www 

The site loads fine at [yourdomain].com but throws a certificate warning at www.[yourdomain].com or the reverse. The certificate itself is valid. It just wasn’t issued to cover both versions of the domain, so the browser flags whichever version is missing from the certificate’s name list. 

This usually happens when a certificate gets reissued manually for a single domain variant, or when a redirect between www and non-www was added after the original certificate was already active. 

Reissue the certificate for both versions 

To confirm and fix it: 

• Check the certificate details in the browser (click the padlock icon, then “Certificate”) and look at which domain names are listed. If only one variant appears, that’s the mismatch. 

• In cPanel, run AutoSSL manually from Security > SSL/TLS Status rather than waiting for the next scheduled run. 

• Confirm both [yourdomain].com and www.[yourdomain].com are selected before reissuing, not just the primary one. 

• Recheck the certificate details after reissuing to confirm both names now appear. 

Once both variants are covered, set a single redirect (www to non-www, or the reverse) so visitors and search engines always land on one canonical version going forward. 

5. Your SSL certificate expired or failed to renew 

A site that worked fine for months and then suddenly throws a certificate warning almost always points to a missed renewal, not a new problem. Let’s Encrypt certificates are valid for 90 days and renew automatically, but that automation can fail silently if AutoSSL was disabled, DNS changed since the last renewal, or a domain validation check didn’t complete. 

Check the expiration date 

Click the padlock icon in the browser and view the certificate details. The “Valid until” date tells you immediately whether this is the cause.   

If the expiration date has already passed, the certificate has expired. If it expires within the next few days, check that automatic renewal is working, but continue troubleshooting because the certificate is still valid until its expiration date. 

Force a reissue 

• In cPanel, go to Security > SSL/TLS Status and run AutoSSL manually instead of waiting for the next automatic cycle. 

• Confirm the domain’s DNS still points to the correct hosting IP. A DNS change since the last renewal is the most common reason auto-renewal fails. 

• Watch for a domain validation error in the AutoSSL log. This usually means the validation file or DNS record couldn’t be reached, not that anything is wrong with the certificate authority. 

• Once reissued, recheck the expiration date to confirm it now shows a date 90 days out. 

If AutoSSL keeps failing on the same domain after a manual reissue, that’s a sign of an underlying DNS or nameserver issue rather than a one-off renewal glitch.  On Bluehost, AutoSSL handles certificate renewal automatically. If renewal fails, check that the domain’s DNS points to the correct hosting account and review the AutoSSL validation status for the specific cause.

6. A redirect rule or .htaccess file is breaking SSL 

“Too many redirects” or “This page isn’t working” usually means two rules are fighting each other, not that the certificate failed. A common cause: an HTTP-to-HTTPS redirect rule sits in .htaccess, but the certificate isn’t fully active yet, or a caching plugin has its own redirect layered on top. The browser bounces between them until it gives up. 

Check for a redirect loop 

• Open the site’s .htaccess file (via File Manager or FTP) and look for duplicate RewriteRule lines forcing HTTPS. Two versions of the same rule, often added by both a plugin and a manual edit, is the most common cause. 

• On WordPress, check the SSL or “Force HTTPS” setting inside any security or caching plugin. If a plugin-level redirect and an .htaccess redirect are both active, disable one. 

• Test the redirect chain directly with a tool like redirect-checker.org, entering the HTTP version of the URL. It shows every hop the browser takes, so you can see exactly where the loop starts. 

• If the loop only started after a plugin update, deactivate that plugin and retest before touching .htaccess at all. That isolates whether the plugin or the file is the actual source. 

Once the duplicate rule is removed, a single clean redirect from HTTP to HTTPS is enough. Adding more rules on top to “make sure” it works is usually what caused the loop in the first place. 

7. A CDN, firewall or security plugin is interfering 

A CDN, firewall or security plugin can sometimes interfere with HTTPS even when the SSL certificate itself is valid. This usually happens when the CDN and hosting server use conflicting SSL settings or when a plugin adds its own HTTPS redirect. 

Match your CDN’s SSL/TLS mode to your host 

If you use a CDN such as Cloudflare, check its SSL/TLS settings and make sure they match the SSL configuration on your hosting account. Also review any security or caching plugins that force HTTPS or add redirects. 

Temporarily disable the CDN proxy or recently updated security plugin and test the site again. If the SSL error disappears, recheck that service’s SSL and redirect settings before enabling it again. 

Still seeing “SSL not working on shared hosting”? Quick checklist 

Work through these in order. Most SSL errors resolve by the third or fourth check. 

1. Check the timing: Hosting or DNS changed in the last 24 hours? Wait for propagation before touching any settings. 

2. Read the warning type: A padlock with a warning icon points to mixed content. A full-page block points to an expired, mismatched, or redirect-looped certificate. 

3. Isolate the browser: Load the site in a private window on a different device. Warning gone? The certificate was already fine. 

4. Check expiration and domain coverage: One check on the certificate’s “Valid until” date and listed domains rules out two causes at once. 

5. Trace the most recent change: A CDN setting, a plugin update, a redirect edit. SSL errors almost always follow a change. 

6. Force a manual reissue: If nothing above resolves the issue, reissue the certificate through AutoSSL rather than continuing to troubleshoot the site configuration. 

Final thoughts 

Most SSL errors on shared hosting trace back to one of the seven causes above, and the fix rarely requires touching code. Propagation delays resolve on their own. Mixed content, cache and mismatch issues resolve with the checks covered here. 

If SSL keeps breaking on a host that requires manual certificate management, that’s worth factoring into whether the host is still the right fit. Bluehost Web Hosting auto-issues and renews SSL on every plan through AutoSSL, so certificates don’t lapse silently or need a manual reissue after every DNS change. Explore Bluehost Web Hosting plans to see what’s included. 

FAQs