Fix Browser Connection Not Secure on Login Page

Your browser flags the login page as not secure because the SSL certificate is misconfigured, expired, or the system clock is wrong. Here's how to fix each cause fast.

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:

Open the browser's lock icon > Certificate Viewer. Look at the validity dates. If it's expired, you need a new cert.
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:

Update all hardcoded URLs to use https:// or protocol-relative URLs (//yourdomain.com/path).
On Nginx, add this to your server block to rewrite HTTP resource requests:
```
sub_filter_once off;
sub_filter 'http://' 'https://';
```
On Apache, use mod_headers to set Content-Security-Policy: upgrade-insecure-requests. Like this:
```
Header always set Content-Security-Policy "upgrade-insecure-requests"
```
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

Error	Likely Cause	Fix Time
`NET::ERR_CERT_DATE_INVALID`	Expired cert OR system clock wrong	5 minutes
`ERR_CERT_AUTHORITY_INVALID`	Self-signed cert or missing intermediate	15 minutes
`Mixed Content` in console	HTTP resources on HTTPS page	30 minutes
Yellow padlock, no error code	Mixed content or weak cipher	20 minutes

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.