Browser Says Connection Not Secure on Login Page – Fix It

Cause #1: Expired or Invalid SSL Certificate

If you see NET::ERR_CERT_AUTHORITY_INVALID or ERR_CERT_DATE_INVALID, the SSL certificate on the server is expired or issued by an untrusted authority. The culprit here is almost always a forgotten renewal — especially with Let's Encrypt certificates that expire every 90 days. I've seen this kill a login page for an entire day before someone checked the cert.

What to check:

1. Open the browser's lock icon > Certificate Viewer. Look at the validity dates. If it's expired, you need a new cert.
2. Use openssl s_client -connect yourdomain.com:443 -servername yourdomain.com to verify the cert chain. If you see verify error:num=20, the chain is incomplete.

Fix it:

• If it's a self-signed cert (common for internal apps), export the cert as .crt and install it in the Trusted Root Certification Authorities store on each client machine. Use certlm.msc for machine-wide install.
• If it's a paid cert, re-issue it through your provider and upload the full chain (intermediate + root).
• For Let's Encrypt, run certbot renew --force-renewal and restart your web server.

Cause #2: Mixed Content Blocker

The page loads over HTTPS, but some resources (images, scripts, stylesheets) are served over HTTP. Browsers block those and show a yellow padlock or Not Secure in the URL bar. I've seen this most often on WordPress login pages where a plugin hardcodes HTTP URLs.

How to check:

• Press F12 > Console tab. Look for Mixed Content: errors with specific resource URLs.
• In Firefox, the Security tab in Network Monitor shows blocked content.

Fix it:

1. Update all hardcoded URLs to use https:// or protocol-relative URLs (//yourdomain.com/path).
2. On Nginx, add this to your server block to rewrite HTTP resource requests:

   sub_filter_once off;
   sub_filter 'http://' 'https://';

3. On Apache, use mod_headers to set Content-Security-Policy: upgrade-insecure-requests. Like this:

   Header always set Content-Security-Policy "upgrade-insecure-requests"

4. For WordPress, install a search-replace plugin and swap http:// with https:// in the database.

Cause #3: System Clock Is Wrong

Your computer's date or time is off by more than a few hours. Browsers check the certificate's validity period against the system clock. If the clock thinks it's 2022 and the cert started in 2023, you get a lockout. This is super common on dual-boot machines that lose clock sync between Windows and Linux.

Check it:

• Right-click the clock > Adjust date/time. Make sure Set time automatically is ON and the time zone is correct.
• In Windows, run w32tm /resync in an admin command prompt to force sync.

Fix it:

• Turn on automatic time sync. If it still fails, set it manually to the correct time, then re-enable auto sync.
• For dual-boot users: in Windows, disable Real-Time Clock from using local time (reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_DWORD /d 1).
• On Linux, run timedatectl set-ntp true and check timedatectl status.

Quick-Reference Summary Table

If none of these work, clear the browser cache and SSL state (certmgr.msc on Windows, then delete all certs under Intermediate Certification Authorities). Also check firewall rules — some enterprise filters strip certs and re-issue their own, which causes trust issues if the CA isn't installed on clients.