Why does my website say "Not Secure"? (And how to fix it)

"Not Secure" in the address bar is the browser telling your visitors it cannot vouch for the connection to your site. Sometimes that means there is no certificate at all. Far more often the certificate is there and paid for, and something around it is broken: it expired, it names the wrong host, the server sends it incomplete, or the page pulls in a single file over plain HTTP.

Every one of these causes leaves a clear fingerprint. Work through them in order and you will find yours.

What the padlock actually certifies

The padlock is narrower than most people think. It says nothing about whether the business is legitimate or the site is free of malware. It certifies three things about the connection, and the browser needs all three:

• Identity of the name. The certificate was issued for the exact hostname in the address bar, by a certificate authority (CA) the browser trusts, and the browser can trace a chain of signatures from your certificate back to that CA's root.
• Validity in time. Today's date falls between the certificate's "not before" and "not after" dates.
• Everything was encrypted. The page and every script, stylesheet, font, image and frame it loaded came over HTTPS.

Fail the first two and the visitor gets a full-page interstitial such as NET::ERR_CERT_DATE_INVALID or NET::ERR_CERT_COMMON_NAME_INVALID. Fail the third, or load the site over http:// in the first place, and the page renders but the address bar shows "Not Secure". That difference alone narrows the search: a red warning page points at the certificate, while a page that loads but has no padlock points at redirects or mixed content.

The five causes, and how to diagnose each

1. The certificate has expired

Free Let's Encrypt certificates last 90 days, and since March 2026 the industry maximum for any public certificate is 200 days, falling in stages to 47 days by 2029. Renewal has to be automatic, and automatic renewal fails quietly. The usual reasons: the domain's DNS was moved to a new host, a leftover AAAA record points at an old server, or a security rule blocks the CA's validation request to /.well-known/acme-challenge/.

Diagnose: click the warning's "Advanced" link, or run an SSL check, and read the "valid until" date. From a terminal:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -ext subjectAltName

Fix: trigger a reissue in your hosting panel (covered below), then find out why renewal failed so it does not happen again in 90 days. Check that the A and AAAA records point at the server that issues the certificate.

2. The name does not match

A certificate lists the hostnames it covers in its Subject Alternative Name field. If it covers example.com but a visitor types www.example.com, the browser treats it as the wrong certificate entirely. This is the classic www versus apex problem, and it often appears after a launch when only one version was added to the certificate. A wildcard such as *.example.com covers www.example.com and shop.example.com but not the bare example.com, and not a.b.example.com.

Diagnose: the subjectAltName line from the command above, or the "Name matches" row in the SSL checker. Test both the www and non-www versions.

Fix: reissue the certificate with both names included, then pick one as canonical and 301 redirect the other to it. Both names still need to be on the certificate, because the browser checks the certificate before it ever sees your redirect.

3. The intermediate certificate is missing

CAs do not sign your certificate with their root directly. They use an intermediate certificate, and your server is supposed to send it alongside yours so the browser can build the chain. When it does not, the result is confusing: desktop Chrome often still shows a padlock because it can fetch or has cached the intermediate, while phones, apps, payment webhooks and command line tools such as curl fail with "unable to get local issuer certificate".

Diagnose: run openssl s_client -connect example.com:443 -servername example.com -showcerts and count the certificates printed. One means the chain is missing. The SSL checker flags this as "No intermediate sent".

Fix: install the full chain. With Let's Encrypt that is fullchain.pem, not cert.pem. On a paid certificate, paste the CA bundle into the "Certificate Authority Bundle" box in cPanel, or append the intermediates below your certificate in the file your web server loads.

4. Mixed content

The certificate is perfect, but the page loads something over http://. Browsers treat this in two tiers. Active content (scripts, stylesheets, web fonts, iframes and form actions) is blocked outright, which is why a freshly migrated site suddenly loses its styling or its contact form stops submitting. Passive content (images, video, audio) is upgraded to HTTPS automatically by current Chrome and Firefox, and blocked if no HTTPS version exists. Either way the padlock can disappear.

The sneaky ones are files you never see in the page content:

• Favicons and touch icons hard-coded in the theme header as <link rel="icon" href="http://...">. The icon is requested on every page, so one bad tag affects the whole site.
• CSS fonts and backgrounds inside stylesheets: @font-face { src: url(http://...) }, @import url(http://...) or background-image: url(http://...). Searching the page source will not find these, because they live in the CSS file.
• Old embeds such as visitor counters and third-party badges pasted in years ago.

Diagnose: open the browser console (F12) and look for "Mixed Content" messages, or scan the page so you get a list of every insecure URL, where it was found, and whether an HTTPS version of that file exists.

Fix: change each URL to https://, or to a relative path like /wp-content/uploads/logo.png for files on your own domain. Then add a safety net header so browsers upgrade any stragglers:

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>

That header only helps when the file exists over HTTPS. Third-party files that never supported HTTPS must be removed or replaced.

5. No redirect from HTTP to HTTPS

Everything works at https://example.com, but someone types example.com or follows an old link and lands on the plain http:// version. The certificate never comes into play, so the address bar says "Not Secure".

Diagnose: curl -sI http://example.com should return a 301 with a Location: https://... header. A 200 means no redirect.

Fix: on Apache and LiteSpeed hosts (Hostinger, most cPanel hosts), add this near the top of .htaccess, above the WordPress block:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

On Nginx, the port 80 server block becomes a single line: return 301 https://$host$request_uri;. Use a 301 rather than a 302 so search engines move their index to the HTTPS URLs.

Platform-specific fixes

Hostinger (hPanel)

Open the website's dashboard in hPanel, then Security, then SSL. Hostinger includes a free certificate with its hosting plans; if its status is anything other than active, reinstall it and make sure both the apex and www versions are listed. The same screen has a Force HTTPS option, which adds the redirect for you. If installation keeps failing, the cause is almost always DNS: the domain must resolve to the Hostinger server, so check for stale A or AAAA records at your registrar or at Cloudflare.

cPanel and AutoSSL

Go to SSL/TLS Status, select the domains, and click Run AutoSSL. Watch the log: AutoSSL proves control of each name by requesting a file under /.well-known/pki-validation/ or /.well-known/acme-challenge/, or with a DNS record. It skips any name that does not resolve to the server, which is how mail. or www. subdomains silently end up uncovered. Rewrite rules or security plugins that block /.well-known/ break validation too. Newer cPanel versions have a Force HTTPS Redirect toggle under Domains.

WordPress

1. In Settings, General, set both WordPress Address (URL) and Site Address (URL) to https://. If they are greyed out, they are defined as WP_HOME and WP_SITEURL in wp-config.php; edit them there.
2. Replace old URLs in the database. Posts, widgets and page builder data store absolute URLs, and much of that data is serialized, so never run a raw SQL replace. Use WP-CLI or a plugin such as Better Search Replace, which handle serialization:

   wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
   wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

3. Check the theme's header.php, Customizer CSS and page builder global settings for hard-coded http:// logos, favicons and fonts.
4. Purge every cache layer: the caching plugin, the host's server cache (LiteSpeed Cache on Hostinger), and the CDN. Until you do, visitors keep getting old HTML that still references http://.

Cloudflare SSL modes

Cloudflare sits between visitors and your server, so there are two connections to secure. The SSL/TLS mode controls the second one:

• Flexible: visitor to Cloudflare is HTTPS, Cloudflare to your server is plain HTTP. The padlock shows, but traffic travels unencrypted for the last leg. If your server also redirects HTTP to HTTPS, you get an infinite loop (ERR_TOO_MANY_REDIRECTS): Cloudflare requests over HTTP, the server redirects to HTTPS, Cloudflare requests over HTTP again.
• Full: HTTPS to your server, but any certificate is accepted, including expired or self-signed ones.
• Full (strict): HTTPS to your server with a valid certificate. This is the setting to use.

To get to Full (strict), install a certificate on the origin (your host's free one, or a free Cloudflare Origin CA certificate, which Cloudflare trusts but browsers do not), switch the mode, then turn on Always Use HTTPS so Cloudflare handles the redirect at the edge.

HSTS: when to turn it on

HTTP Strict Transport Security is a response header that tells the browser to use HTTPS for your domain for a set period, even if someone types http://. It closes the window where that first plain HTTP request could be intercepted before your redirect fires.

Turn it on only after HTTPS works everywhere, and ramp up the duration:

# Week one: five minutes, main domain only
Header always set Strict-Transport-Security "max-age=300"

# Once everything is confirmed: one year, all subdomains
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Be careful with includeSubDomains: a staging site or webmail on a subdomain without a certificate becomes unreachable in browsers that have seen the header. Be more careful still with the preload directive and the hstspreload.org list. Preloading ships your domain inside browser releases as HTTPS-only, it requires includeSubDomains and a max-age of at least one year, and removal takes months to reach users. Only preload a domain you are certain will serve every subdomain over HTTPS for years.

A quick troubleshooting flow

1. Does the browser show a full-page red warning? Check the certificate: expiry date first, then the names it covers, then trust.
2. Expired? Reissue in your panel, then check DNS and /.well-known/ access to find why renewal failed.
3. Name mismatch? Reissue covering both apex and www, and redirect one to the other.
4. Works on desktop but not on phones or in curl? Install the intermediate chain.
5. No red warning, page loads but no padlock? Check the URL bar for http://. If you are on HTTP, add the 301 redirect.
6. On HTTPS but still no padlock? Scan for mixed content and fix each URL, starting with blocked scripts, styles and fonts.
7. Behind Cloudflare and seeing redirect loops? Move from Flexible to Full (strict) with a certificate on the origin.
8. All green? Purge caches, retest on a phone, then consider HSTS.

Frequently asked questions