Your site shows "Not secure", the padlock has vanished, or visitors hit a full-page warning. Do not pay the first quote you are given, and do not ignore it. Almost every HTTPS warning belongs to one of four fault classes — mixed content, an expired certificate, a wrong name or incomplete chain, or a forced-HTTPS trap. Name yours first, then follow its fix order only.
The short answer: name your fault first — the four HTTPS faults and their one-line tests
Fault one, mixed content: the page loads and mostly works, but the padlock is missing or the bar says "Not secure". Test: the console names the files still loading over HTTP. Fault two, expired certificate: a full-page warning coded NET::ERR_CERT_DATE_INVALID. Test: read the expiry date in the certificate viewer. Fault three, wrong name or incomplete chain: the warning appears only on some addresses, or the code is ERR_CERT_AUTHORITY_INVALID. Test: check both address versions and run an external chain check. Fault four, forced-HTTPS traps: after someone "fixed" SSL, pages loop or half-load. Test: the certificate checks out fine, so the fault sits in redirects.
Fault 1 — Mixed content: the padlock is gone but the certificate is fine
Mixed content means the page arrived securely over HTTPS, but something inside it — an image, script, stylesheet, font or embed — is still fetched over plain HTTP. The certificate is valid; some resources never made the move — most often after a migration or late SSL installation, when old addresses survive inside content, theme files and builder layouts.
Browsers treat the two kinds differently, as MDN Web Docs and Chrome's documentation describe. Active mixed content — scripts, stylesheets, iframes and data requests — can change the page, so browsers block it outright. Passive content — images, audio and video — cannot, so browsers automatically upgrade those requests to HTTPS and block the file only if no secure version loads. Either way, the padlock goes.
Fix it at the source: set your WordPress Address and Site Address to https://, replace old addresses in the database safely (see the fix-order section), refresh builder copies such as Elementor's URL store, regenerate its CSS, and re-embed third-party widgets with current HTTPS code. A web development consultation can confirm which layer your offenders live in.
Fault 2 — Expired certificate: what visitors see, and the renewal fix in order
An expired certificate produces the scariest warning: a full-page interstitial, coded NET::ERR_CERT_DATE_INVALID. Almost nobody clicks through the advanced options to reach a contact or payment page.
Fix it in order. Confirm the expiry in the certificate viewer. Renew or reissue: with Let's Encrypt, renewal is normally automatic via the ACME protocol, so an expiry means it failed — common causes are a changed DNS record, blocked validation, or a moved site whose new server was never enrolled. Ensure the new certificate is installed and served on every address, then re-check the padlock. Finally, fix the reason renewal failed: Let's Encrypt's own guidance is to automate renewal and renew well ahead of expiry — for its current 90-day certificates, renewing 30 days before expiration.
Fault 3 — Wrong name or incomplete chain: www, subdomains and ERR_CERT_AUTHORITY_INVALID
A certificate covers only the names listed on it. If it was issued for www.yourdomain but visitors land on the bare domain — or a subdomain such as shop. was never included — the browser reports a name mismatch, commonly NET::ERR_CERT_COMMON_NAME_INVALID. A single-name certificate covers exactly one hostname; several subdomains need a multi-name or wildcard certificate.
The chain fault is subtler. Your certificate is signed by an intermediate certificate, which is signed by a root browsers trust. If your server presents your certificate without the intermediate bundle, some browsers fill the gap from their caches while others cannot — why this fault appears on one phone and not another, under ERR_CERT_AUTHORITY_INVALID. Fix it at server level: install the full chain bundle your authority provides, then verify externally. Record the issuing authority and bundle location in your website handover and ownership records.
Fault 4 — Forced-HTTPS traps: redirect loops and pages that only half-load securely
Sometimes the certificate is fine and the loop or half-loaded page was created by the attempt to force HTTPS. Classic patterns: one redirect rule sends HTTP to HTTPS while a CDN, host or CMS setting sends it back, producing a "too many redirects" loop; HTTPS is forced before mixed content was cleaned up, so browsers block still-HTTP scripts and pages load unstyled.
Unpick traps in reverse order of addition: CDN and host settings first, then CMS addresses, plugin rules, then server redirects. One layer should own the redirect; every other layer should agree with it. The MDN-documented Content-Security-Policy directive upgrade-insecure-requests can upgrade remaining insecure requests as a safety net — but it is a net, not a repair. If the site fails to load entirely, our website-down troubleshooting guide, publishing alongside this article, covers the wider sequence.
The 10-minute diagnosis: browser console, certificate viewer and SSL Labs, step by step
One, open the affected page in Chrome and read the Console tab in developer tools: each mixed-content entry names the exact file and its HTTP address. Two, open the certificate viewer from the icon beside the address bar: expiry date, names covered and issuing authority separate faults two and three. Three, run your domain through the SSL Labs Server Test, which flags missing intermediates in the chain. Four, repeat on money pages — contact, checkout, booking, payment — because mixed content is page-specific. Five, record the fault before changing anything.
Fix order and safety rules: backup first, dry runs, and never a raw SQL replace
Whatever the fault, the safe order is the same. Back up first — files and database; our backup and disaster recovery guide, publishing alongside this article, covers what a usable backup contains. Change one layer at a time. For database replacements, use a tool that understands WordPress's serialized data — WP-CLI's search-replace or the Better Search Replace plugin — and always run the dry run first. Never run a raw SQL replace: it corrupts serialized values silently, and the site breaks days later in places nobody connects to the fix. Clear every cache afterwards, then re-run both checks.
Is it actually a hack? The signs that mean this is not a certificate problem
A browser warning alone is a configuration fault, and this article owns those. But change route if you also see pages you never created, redirects to gambling or pharmacy sites, admin users nobody recognises, a Google "hacked" flag, or warnings that survive a verified-clean certificate and a clean mixed-content check. Those are signs of intrusion, not expiry, and no renewal will remove them; our hacked WordPress recovery guide, publishing alongside this article, covers that route.
Prevention: auto-renewal, expiry alerts and a post-migration HTTPS checklist
Prevention is cheaper than every fault above. Turn on automatic renewal wherever your certificate supports it. Set calendar alerts as a backup net — DNSimple, for example, notifies customers at 60, 30, 14, 7 and 3 days before expiry. After any migration or domain change, run the HTTPS checklist before launch: certificate installed for www and bare domain, site addresses on https://, database swept, builder caches regenerated, one redirect layer only, console clean on money pages, chain complete. Add a monthly padlock check on contact and payment pages, as our web development team in the UAE does.
Common mistakes that turn a small warning into downtime
The expensive mistakes are consistent. Buying a new certificate for a mixed-content fault, which changes nothing. Replacing database addresses with raw SQL and corrupting serialized data. Forcing HTTPS before cleaning mixed content, turning a missing padlock into broken pages. Fixing only the homepage while the checkout keeps warning. Renewing by hand without fixing the failed auto-renewal, guaranteeing a repeat. And certificate, hosting and domain records scattered across three people's accounts.
FAQ
Why does my site say "Not secure" even though I have an SSL certificate?
Usually mixed content: the certificate is valid, but some resources load over HTTP, so the browser removes the padlock. Expiry, name mismatch or an incomplete chain produces a full-page warning instead. The console and certificate viewer tell you which you have.
What is the difference between active and passive mixed content?
Active mixed content — scripts, stylesheets, iframes and data requests — can change the page, so browsers block it outright. Passive content — images, audio and video — cannot change the page, so browsers automatically upgrade those requests to HTTPS and block the file only if no secure version loads.
What does NET::ERR_CERT_DATE_INVALID mean?
It means the certificate has expired, or the visitor's device clock is significantly wrong. If the certificate viewer's expiry date has passed, renew and install the certificate, then find out why automatic renewal failed — it will repeat at the next expiry.
How do I check whether my certificate chain is complete?
Run your domain through the SSL Labs Server Test. It shows the chain your server presents to outside visitors and flags a missing intermediate — the usual cause of ERR_CERT_AUTHORITY_INVALID appearing on some devices but not others.
How can I stop my certificate expiring again?
Enable automatic renewal, confirm one completes, and set expiry alerts as a backup. Let's Encrypt recommends renewing its 90-day certificates 30 days before expiration. Record who owns the certificate, hosting and domain accounts.
Still warning after the checks? Get the fault fixed at server level (CTA)
If the console is clean, the certificate is in date and correctly named, and it persists, the fault sits at server or chain level — not a layer to experiment on while the site trades. Send us the error code and affected addresses, and our website development company in Dubai will fix it at the right layer. WebStackRank provides an itemised proposal within 24 business hours.
