“Not Secure” Warning in the Address Bar

What’s actually happening

The address bar shows 'Not Secure' to the left of the URL on every page of the site. The page still loads — this isn't a blocking error — but visitors see the label and trust drops. If there's a login or payment field on an HTTP page, Chrome escalates the warning and may show a red treatment. This is about the page origin being HTTP, which is different from mixed content where an HTTPS page pulls some HTTP assets.

Common causes

• The site has no TLS certificate at all and only listens on port 80.
• A certificate exists but there's no redirect, so users land on the http:// URL and stay there.
• Hard-coded http:// links, bookmarks, or internal references keep routing users to the insecure version.
• HTTPS is configured on the origin but a CDN/proxy in front terminates or serves HTTP to the browser.
• Cert installed for the apex but not www (or vice versa), so one hostname falls back to HTTP.

How to fix it

1. Install a TLS certificateIf there's no cert, get one. Let's Encrypt via certbot is free and automated: `certbot --nginx` or `certbot --apache` provisions and wires it in. Managed hosts (Cloudflare, Netlify, most platforms) issue one with a toggle. Confirm https:// loads with a padlock before moving on.
2. Force HTTP to redirect to HTTPSAdd a 301 from http to https for every path. nginx: a server block on port 80 with `return 301 https://$host$request_uri;`. Apache: a RewriteRule or `Redirect permanent`. The certificate alone doesn't help if users never get sent to the secure URL.
3. Cover every hostname on the certMake sure the cert's SAN list includes both apex and www (and any subdomains in use). A cert for www.example.com only will leave example.com on HTTP. Re-issue with all names or add a SAN, then redirect the bare domain to the canonical https host.
4. Fix HTTP at the CDN/edgeIf a proxy sits in front, set its SSL mode so it both accepts HTTPS from clients and talks HTTPS to your origin (Cloudflare 'Full' or 'Full (strict)'). 'Flexible' mode leaves the browser-to-edge leg vulnerable and can loop. Enable the 'Always Use HTTPS' edge rule.
5. Lock it in with HSTSOnce HTTPS is solid sitewide, add a `Strict-Transport-Security` header so browsers refuse HTTP automatically. Start with a short max-age, confirm nothing breaks, then raise it. Don't enable HSTS before HTTPS works on all hostnames or you'll lock users out.