How to fix "Not secure" warnings and SSL certificate errors

Start by running the SSL certificate checker on your domain. It shows whether HTTPS works, when the certificate expires, who issued it, which names it covers, and whether HTTP redirects to HTTPS. Then match what you see to one of the problems below.

"Not secure" in the address bar

This label means the page was loaded over plain HTTP, or that it contains a form that submits over HTTP. There is no certificate error; the connection simply is not encrypted.

1. Get a certificate. Most hosts offer free certificates (often from Let's Encrypt) that renew automatically; look for SSL or AutoSSL in your hosting panel.
2. Make sure the site loads at https:// for every hostname you use, including both www and the bare domain.
3. Redirect all HTTP requests to HTTPS with a permanent (301) redirect, at the server, CDN or hosting panel.
4. Update the site's own address to HTTPS. In WordPress, set both addresses under Settings > General.

A typical nginx redirect looks like return 301 https://$host$request_uri; in the port 80 server block. On Apache, many hosts provide a "Force HTTPS" switch; otherwise a rewrite rule in .htaccess does the same.

Certificate expired (NET::ERR_CERT_DATE_INVALID)

The certificate is past its expiry date, or occasionally the visitor's device clock is wrong. If several people see it, the certificate has expired. Renew or reissue it in your hosting panel or with your certificate provider, then find out why automatic renewal failed: a changed DNS record, a blocked validation path or a cancelled hosting service are common causes.

Certificates are getting shorter-lived. Under CA/Browser Forum ballot SC-081, publicly trusted certificates issued from 15 March 2026 can be valid for at most 200 days, dropping to 100 days in March 2027 and 47 days in March 2029. Manual renewal is becoming impractical, and expiry monitoring more important.

Name mismatch (NET::ERR_CERT_COMMON_NAME_INVALID)

The certificate is valid, but not for the address the visitor used. The classic case is a certificate for example.com that does not cover www.example.com, or the other way round. Reissue the certificate to include every hostname you serve, or redirect the uncovered name to one that is covered (the redirect itself needs a valid certificate, so the first option is usually better).

Untrusted certificate (NET::ERR_CERT_AUTHORITY_INVALID)

The browser cannot link the certificate to a trusted authority. Either it is self-signed (common on fresh servers and control panels), or the server is not sending the intermediate certificate. Install a certificate from a public authority, and make sure the server sends the full chain: on nginx, use the "fullchain" file rather than the certificate alone.

Mixed content: HTTPS page, HTTP resources

The page itself is HTTPS, but it loads scripts, stylesheets, images or frames over HTTP. Browsers block insecure scripts and frames outright, which often breaks the page, and may upgrade or block insecure images. Forms that submit to an HTTP address trigger a warning when submitted.

• Find the offending URLs in the browser console, or with a Webforta scan, which lists mixed content and insecure forms on the homepage.
• Change hard-coded http:// links in your theme, content and settings to https:// or relative paths.
• In WordPress, replace old URLs in the database with WP-CLI: run wp search-replace 'http://example.com' 'https://example.com' --dry-run first, then without --dry-run. Take a backup before you do.
• Once everything works, consider the upgrade-insecure-requests directive in your Content-Security-Policy as a safety net.

Too many redirects after switching to HTTPS

A redirect loop usually means two layers disagree. The most common case is a CDN or proxy connecting to your server over HTTP while the server redirects every HTTP request to HTTPS. If you use Cloudflare, set the SSL/TLS mode to Full (strict) with a valid certificate on the origin, rather than Flexible.

After the fix: keep it fixed

• Add an HSTS header (Strict-Transport-Security) once HTTPS works on every page and subdomain you include. Browsers then refuse to use HTTP for your site at all. Start with a short max-age; browsers remember it for the whole period.
• Monitor certificate expiry and get warned well before the date. Webforta Monitor checks expiry daily from public Certificate Transparency logs and alerts at the threshold you choose.
• Check headers after every deployment. The security headers checker grades them and gives copy-paste fixes.