Your SSL Certificate Is Installed—So Why Does the Website Still Say Not Secure?

59 minutes ago

7 min read

You install an SSL certificate, reload the site, and the browser still shows “Not Secure.” The natural reaction is to reinstall the certificate. In practice, that often fixes nothing because a secure website depends on more than the certificate itself. The browser also checks the exact hostname, the certificate chain and dates, the page protocol, every loaded resource, and the path through any CDN or reverse proxy.

The fastest repair starts by identifying which layer is failing. Use this guide to separate a certificate problem from mixed content, an HTTP redirect gap, a stale edge server, or a platform configuration issue.

First, identify the warning you actually have

Do not treat every security indicator as the same problem. Record the exact URL, browser, device, network and time before changing anything. Then match the symptom:

The address starts with http:// and the browser says Not Secure: the page itself is being served over HTTP or is not redirected to HTTPS.
A full-page “Your connection is not private” warning appears: certificate identity, validity, trust chain or local clock validation has failed.
The homepage is secure but one page is not: that template or page probably loads an insecure resource, form, iframe, font or script.
The root domain works but www, a subdomain or another regional hostname fails: the certificate or DNS route may not cover that hostname.
The warning appears only on some devices, locations or networks: investigate certificate-chain compatibility, DNS, IPv6, a CDN edge, or a cached service worker.

In Chrome, open DevTools, then the Privacy and security panel. Chrome documents that its Security view exposes the page’s origins, HTTP warnings, origin details and certificates. The Console and Network panels will usually identify an insecure request by its full URL.Chrome’s Security panel instructions

Run this 10-minute diagnostic before changing the site

Copy the exact failing URL, including http or https and the hostname. Test it in a private window so an old redirect or service worker is less likely to influence the result.
Open the certificate details. Check the subject alternative names, issuer, start and expiry dates, and whether the browser reports a complete trusted chain.
Test four common variants: http://example.com, https://example.com, http://www.example.com and https://www.example.com. Add any shop, booking or regional subdomains customers use.
Open DevTools Console and Network, reload the page, and search for http://, blocked mixed content, certificate errors and failed redirects.
Repeat on a phone using cellular data. If Wi-Fi and mobile data disagree, DNS, IPv6, firewall or CDN routing becomes more likely than page content.
Check a representative product, blog, form, checkout and landing page—not only the homepage.

This sequence prevents a common mistake: fixing the visible page while the actual failure lives on another hostname or only appears on a specific template.

Cause 1: the certificate does not cover the hostname

A certificate is valid only for the names listed in it. A certificate for example.com does not automatically prove ownership of www.example.com, shop.example.com or client.example.com. Wildcards have limits too: *.example.com normally covers one subdomain level, not example.com itself or deeper names such as checkout.us.example.com.

Fix the DNS and certificate together. Decide which hostname is canonical, ensure every public hostname routes to the intended platform, and provision a certificate that includes each hostname customers can reach. Then redirect the non-preferred host to the preferred HTTPS URL. If an old server still answers for an obsolete A, AAAA or CNAME record, some visitors may reach the wrong certificate even though your own browser looks fine.

Cause 2: the certificate is expired, not yet valid or missing part of its chain

Check both certificate dates and the device clock. An incorrect local date can make a valid certificate appear expired or not yet valid. On the server side, successful renewal does not guarantee that the active web server, load balancer or CDN edge received the new certificate.

Also verify that the server sends the required intermediate certificates. Browsers build a chain from the site certificate to a trusted root; a missing intermediate can produce inconsistent results across operating systems and devices. Let’s Encrypt’s certificate documentation explains these chains of trust and the currently active intermediates.Let’s Encrypt chains of trust

After renewal, reload or deploy the certificate on every termination point—CDN, reverse proxy, load balancer and origin where applicable—then test from more than one network.

Cause 3: the page is HTTPS but its resources are not

Mixed content occurs when an HTTPS page requests a resource over HTTP. The certificate can be completely valid while an old image URL, stylesheet, font, script, iframe, video, form action or tracking endpoint weakens the page. Modern browsers may upgrade some media requests automatically, but they block riskier resource types such as scripts, stylesheets, iframes, fetch requests and web fonts.

MDN recommends serving every resource over HTTPS and using relative or HTTPS references. Its mixed-content guide also notes that the browser console shows resources that were upgraded or blocked.MDN mixed-content guidance

Fix the source, not just the symptom:

Replace hard-coded HTTP asset URLs with working HTTPS versions.
Re-upload legacy images or documents if the original host does not support HTTPS.
Check CSS background images, @font-face rules, embedded maps, chat tools, booking widgets and form actions.
Update CMS records and theme settings with a backup and a serialization-safe search-and-replace process where required.
Remove or replace a third-party vendor that cannot serve its production asset securely.
Purge platform and CDN caches after the source URLs are corrected.

Do not rely on a Content Security Policy upgrade rule as the only repair. It can be a useful safety net, but the underlying URL must still exist over HTTPS and should be corrected at its source.

Cause 4: HTTP redirects and canonical signals disagree

Installing a certificate does not force visitors onto HTTPS. Every HTTP URL should redirect permanently to its matching HTTPS URL, preferably in one hop. Avoid sending http://www to https://www and then again to https://example.com when a direct redirect is possible.

Update internal links, canonical tags, hreflang references and XML sitemaps so they point directly to the final HTTPS version. This is both a security cleanup and a technical SEO cleanup. Google’s site-move guidance recommends redirects from old URLs to new URLs and warns against redirect chains.Google’s site-migration guidance

If Google is selecting an unexpected URL after the change, use Webcurry’s canonical troubleshooting guide to align redirects, internal links, sitemap entries and canonical tags.

Cause 5: the CDN, proxy and origin disagree

Many sites terminate HTTPS at a CDN or load balancer before traffic reaches the origin. A valid edge certificate can coexist with an expired origin certificate, an insecure origin connection, or a redirect loop caused by incorrect proxy headers. Some providers call an edge-only arrangement “flexible” SSL; it is not equivalent to an encrypted connection all the way to the origin.

Check where TLS terminates, whether the proxy connects to the origin over HTTPS, and whether the application correctly recognizes the original scheme. Confirm that every CDN edge has the same active certificate and that both IPv4 and IPv6 DNS records lead to the intended service. If the problem appears only on cellular networks, continue with the Wi-Fi versus mobile-data diagnostic.

Cause 6: customers are seeing a cached insecure version

A browser cache, CDN cache or service worker can preserve an older page shell after HTTPS migration. Test in a private window and on another device, but do not stop at telling customers to clear their cache. Purge the appropriate server or CDN layer, update the service worker lifecycle, and version changed assets.

For a layer-by-layer workflow, use the old-version and cache troubleshooting guide. If Safari behaves differently from Chrome, the Chrome-versus-Safari diagnostic helps separate caching, storage and browser-compatibility issues.

Platform-specific fixes

Wix

Confirm that the custom domain is fully connected, the site is published, and Wix reports SSL as active for the preferred domain. Check both the root and www variants. Wix-managed pages and media normally use HTTPS, so persistent warnings often come from custom embeds, external scripts, linked documents, marketing pixels or third-party widgets. Remove the suspect element, publish, and retest before adding it back with an HTTPS source.

WordPress

Verify that WordPress Address and Site Address use HTTPS. Back up the database before changing stored URLs, and use a tool that safely handles serialized data rather than a blind text replacement. Check theme options, page-builder content, plugin settings and custom CSS. If WordPress sits behind a proxy, configure the application and host to recognize the forwarded HTTPS scheme, then purge page, object, CDN and browser caches.

Shopify

Check that the correct custom domain is connected and selected as primary. Inspect theme code and app blocks for external HTTP images, scripts, fonts and iframes. Custom pixels, review apps, legacy page-builder sections and externally hosted assets deserve special attention. Duplicate the live theme before editing code, then test product, cart and checkout paths after publishing.

Do not overlook forms, payments and embedded tools

A page can look secure while its conversion path is not. Inspect form action URLs, booking embeds, payment badges, chat widgets, analytics endpoints and downloadable files. A blocked script may leave a button visible but nonfunctional, which turns a security repair into a conversion problem. Test a real submission or sandbox transaction and confirm the server-side result—not merely the success animation.

If the form submits but the lead never arrives, follow the contact-form delivery workflow.

Pre-launch verification checklist

Every public hostname presents a valid certificate that covers its exact name.
The server sends a complete trusted certificate chain and the active certificate is within its validity period.
Every HTTP page redirects once to the intended HTTPS page without loops.
Internal links, canonical tags, hreflang and XML sitemap entries use final HTTPS URLs.
Console and Network checks show no HTTP resources or mixed-content warnings on key templates.
Forms, bookings, carts and third-party widgets work after insecure resources are removed.
The site is tested in Chrome and Safari, on desktop and mobile, over Wi-Fi and cellular data.
CDN, proxy, origin, IPv4 and IPv6 routes all reach the same intended deployment.

Add these checks to routine maintenance instead of waiting for a customer warning. Webcurry’s technical SEO checklist and website maintenance guide provide a practical schedule for redirects, crawl signals, updates and monitoring.

The real fix is to repair the failing layer

A certificate only proves one part of the HTTPS path. The durable solution is to identify whether the failure is the hostname, certificate chain, page protocol, subresource, redirect, proxy, DNS route or cache—and then correct that layer at its source.

If the warning is inconsistent or you cannot reproduce what customers see, ask Webcurry for a focused website review. Bring the exact URL, screenshot, device, browser, network and time of failure; those details usually turn a vague “Not Secure” complaint into a testable diagnosis.