You may see your connection is not private when you are trying to log in, check out, open a client site, or reach WordPress admin. The warning is alarming, but it does not automatically mean the site was hacked or your data was stolen. It is different from this site may harm your computer, a separate browser security warning.
Do not enter a password, payment detail, or other sensitive information while the warning remains. First find out whether the problem affects one site, every site, or only your current network. That answer usually points to the right fix.
TL;DR
Visitors: Check the address, reload the page, correct your device time, try a private window, and switch networks. Do not bypass the warning or enter personal data while it remains.
WordPress owners: Check the certificate and every domain it covers, host and CDN settings, WordPress URLs, HTTPS redirects, and cached copies. For a related label, see why a WordPress site may show “not secure”. If the site also shows suspicious changes, scan it for malware.
What the warning means
HTTPS is the protected version of a website connection. It encrypts information between your browser and the site, and it uses a digital certificate to help confirm that the site is serving the address you requested.
The warning appears when the browser cannot complete that check. The certificate may be expired, issued for another domain, missing part of its trust chain, or replaced by a network or security tool. Your device clock can also make a valid certificate appear invalid. The message means the browser cannot establish enough trust in this connection yet; it is not, by itself, proof that the site is hacked.
This warning is not a final judgment about the whole site. A valid certificate helps verify the connection, but it does not prove that a WordPress site has no malware.
The wording changes by browser:
| Browser | Common warning |
|---|---|
| Chrome | Your connection is not private |
| Safari | This connection is not private |
| Firefox | Warning: Potential Security Risk Ahead |
| Edge | Your connection isn’t private |
Different wording does not change the safe first step: pause before entering sensitive information and identify what is failing.
Find the likely cause first
Check how widely the warning appears before changing settings. This prevents you from trying device fixes when the website is the real problem.
| What you see | Start here |
|---|---|
| One website fails | That site’s certificate, address, server, or delivery service |
| Your WordPress site fails | Certificate coverage, host or CDN settings, WordPress URLs, redirects, cache, or site changes |
| Every HTTPS site fails | Device time, browser, operating system, security software, or network |
| Several sites fail only on public Wi-Fi | The Wi-Fi sign-in page or network filtering |
| One browser fails and another works | Browser settings, extensions, stored site data, or browser policy |
If every HTTPS site fails, your device or network is more likely to be responsible than all those websites at once. If only one site fails, start with that site’s certificate. Clearing WordPress cache will not fix a wrong device clock, and changing browser settings will not renew a site certificate.
Safe checks for visitors
Use these checks without accepting an untrusted connection. Stop when the warning disappears, then confirm the address is still correct.
-
Check the exact website address: Look for missing letters, extra words, strange subdomains, or a lookalike domain. A certificate for the real site does not make a misspelled domain safe.
-
Reload once and restart the browser: A temporary connection problem can leave a bad state. Reopen the browser, but repeated refreshes will not repair a bad certificate.
-
Correct the device date and time: Certificates work only between their stated dates. Turn on automatic date, time, and time-zone settings, then restart the browser. NET::ERR_CERT_DATE_INVALID can also indicate an expired site certificate.
-
Use a private window as an isolation test: If the site works there, an extension, cookie, stored redirect, or browser profile may be involved. Clear that site’s stored data and review extensions one at a time. Private mode does not prove certificate safety.
-
Switch to a trusted network: Move from public Wi-Fi to mobile data or a known home or office network. Public Wi-Fi sign-in pages can interrupt HTTPS checks.
🧭 Note: If you trust the network, open a simple HTTP page to bring up its sign-in screen. Do not enter personal details on a page you cannot verify.
-
Test another browser and security layer carefully: If one browser fails but another works, check extensions and settings. VPNs, proxies, company filters, and antivirus HTTPS scanning can act as intermediaries. On a trusted network, briefly pause one tool, test the page, and restore it immediately. This is an isolation test, not a permanent fix.
-
Update the browser and operating system: Older software may not recognize newer certificate trust records. Install updates through normal settings. Do not download a replacement certificate from an unknown website.
If the warning remains, contact the site owner through another trusted channel. Do not sign in or submit a form just to test the page.
Do not bypass the warning blindly
Do not choose Proceed, Continue, or an equivalent option on a banking page, WordPress login, checkout, contact form, email account, or payment page. That option means you are accepting the browser’s stated risk. It is not a safety approval.
Some browsers remove the bypass option for serious certificate failures. HSTS, a rule that forces a site to use HTTPS, can also prevent a bypass. Treat the missing option as a reason to investigate, not as a problem to work around.
The only narrow exception is a known local development site or internal company tool whose certificate policy you understand. It does not apply to an unfamiliar public website.
For contrast, this is the ordinary WordPress login surface when it loads over a healthy HTTPS connection:
Use the error code to choose a fix
Copy the small error code shown below the warning before changing settings. These codes point toward likely causes, but they are not perfect diagnoses.
| Error code | Likely direction |
|---|---|
| NET::ERR_CERT_DATE_INVALID | The certificate dates or device clock do not match the current date. |
| NET::ERR_CERT_COMMON_NAME_INVALID | The certificate does not cover the exact website address, or the server sent the wrong certificate. |
| SSL_ERROR_BAD_CERT_DOMAIN | Firefox found a mismatch between the certificate and the requested domain. |
| NET::ERR_CERT_AUTHORITY_INVALID | The browser cannot trust the certificate issuer or the linked records used to verify it, or another service is replacing the certificate. |
| SEC_ERROR_UNKNOWN_ISSUER | Firefox cannot establish trust in the certificate issuer or chain. |
| ERROR_SELF_SIGNED_CERT | The site is using a certificate signed only by itself, which public browsers do not generally trust. |
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | The server’s HTTPS security settings are too old or do not work with the browser. |
| MOZILLA_PKIX_ERROR_MITM_DETECTED | Firefox suspects that security software, a proxy, or another network layer is inspecting the connection. |
| NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED | Chrome could not complete a required certificate-transparency check. |
Date errors can be local or site-side. Domain errors usually point to the address or server. Issuer and interception errors can come from the site, work network, antivirus software, or a proxy. For broader WordPress error diagnosis, see MalCare’s WordPress errors guide. These are directions for investigation, not absolute diagnoses. Send the code to whoever manages the site or network.
Fix the warning on a WordPress site
If visitors see the warning on your WordPress site, repair the protected connection before investigating malware. Most cases begin with the certificate, domain settings, server, delivery service, redirects, or stored copies. Treat the warning as an HTTPS problem first unless the site also shows signs of compromise.
Confirm the certificate matches every address
Open the certificate details from the browser controls beside the address bar. Check the expiry date, issuer, trust status, and listed domain names.
The exact address matters. A certificate for example.com does not automatically cover www.example.com, shop.example.com, staging.example.com, or an old domain that still receives visitors. Confirm that every public address has coverage, including the version visitors reach after a redirect.
If the certificate is expired, renew it through your host, CDN, or certificate provider. Replace a self-signed certificate on a public site with one recognized by public browsers.
If the certificate is missing or incorrectly installed, follow this guide to install an SSL certificate on WordPress after confirming the correct domain and host or CDN path.
🧾 Note: An installed certificate can still fail if it covers the wrong domain, lacks a record used to verify it, or is not the one selected by shared hosting.
Use a public certificate checker such as SSL Labs to review the certificate, domain names, trust records, and server settings. Record the browser code first.
Check the host and CDN separately
When a CDN is in use, there are two protected connections: visitor to CDN and CDN to the host server. The first can work while the second fails because the host certificate is expired, mismatched, or untrusted.
Review the CDN’s HTTPS mode and origin settings. Confirm that the host accepts the CDN’s domain and that both sides use compatible settings. If you do not manage the host, send the domain, error code, and certificate result to support.
WordPress Site Health can provide environment context while you separate WordPress settings from host and CDN problems:
Set both WordPress URLs to HTTPS
In Settings > General, WordPress Address (URL) identifies where WordPress files live, while Site Address (URL) is the public address visitors use. After the certificate works, both should use the intended HTTPS address.
If these fields cannot be edited, the values may be fixed by the WP_HOME or WP_SITEURL constants in the site’s configuration file. Ask your host or developer to check the file or database. Back up the site before changing configuration.
Use one place for HTTPS redirects
After the certificate is valid, set the HTTP-to-HTTPS redirect in one controlled place, such as the host, CDN, server, or a trusted WordPress security plugin.
If you are deciding whether WordPress should help manage HTTPS, compare WordPress SSL plugins after confirming who manages the certificate.
If WordPress, the host, and the CDN all force different HTTPS versions, they can send visitors in a loop. Test the bare domain, the www version, important subdomains, and wp-admin. Each should reach the intended address without a loop or warning.
🛠️ Note: A working homepage does not prove that every hostname works. Test the addresses visitors and administrators actually use after changing certificates or redirects.
Clear stored copies after the repair
Purge the browser, WordPress, host, and CDN caches when they are in use. Do this after correcting the certificate, URLs, and redirects. Cache clearing cannot repair an invalid certificate.
Separate mixed content from a certificate failure
Mixed content means an HTTPS page still requests an image, script, font, frame, or stylesheet over HTTP. It can create a “not secure” label, block some files, or break the layout. It is different from a full certificate warning that stops the page before it loads.
If the browser blocks the whole page, investigate the certificate, exact domain, and server security settings first. If the page loads but some files are blocked or marked insecure, inspect the page’s HTTP addresses separately. This WordPress CSS over HTTPS troubleshooting guide can help when a certificate issue is actually a mixed-content or stylesheet-loading problem. Fixing mixed content will not renew an expired certificate or correct a certificate for the wrong domain.
Scan when the site shows suspicious changes
A certificate warning alone does not prove malware is present. Malware is unwanted code or content that changes how a site behaves. Start with the certificate and HTTPS path unless other warning signs appear. The malware branch begins with suspicious site behavior, not with the browser warning alone.
Scan the WordPress site when the privacy warning comes with:
- unexpected redirects from a hacked WordPress site
- injected pages or spam addresses
- changed server rules
- unknown administrator accounts
- visitors seeing different content from the site owner
- browser or security warnings plus unexplained site changes
- certificate or redirect problems that return after a clean configuration fix
At that point, scan your WordPress site for malware to inspect the files and database. A scan can help identify or clean malware, but it does not renew an expired certificate or replace host and CDN settings. Keep the two investigations separate: one can be necessary without the other.
Prevent the warning from returning
Make the repair easier to maintain with a WordPress security maintenance checklist:
- Automate certificate renewal through the host, CDN, or certificate provider.
- Set expiry alerts so a failed renewal is noticed before visitors do.
- Record where HTTPS is managed so future changes do not conflict.
- Check new domain coverage after adding www, subdomains, staging addresses, or a new primary domain.
- Purge relevant WordPress caches after certificate, CDN, or redirect changes.
- Apply WordPress security updates along with browser and operating system updates.
- Monitor site changes such as new administrators, redirects, and unexpected files.
For cache-layer ownership and response-header checks, see Airlift’s Cache-Control guide.
Know when to escalate
If you are a visitor and the warning persists on one site, stop using the page and contact the site owner another way. Do not enter data because you need the page urgently.
If you own the site and the certificate checker reports problems you cannot fix, contact the host, CDN, or certificate provider. Send the exact address, browser, error code, screenshot, and result.
If the warning began after a host or domain move, WP Remote’s safe WordPress migration guide covers related DNS, SSL, cache, and testing checks.
Before making risky certificate, CDN, redirect, server, or WordPress configuration changes, confirm that you have a current backup and a way to restore the site.
If every HTTPS site fails, contact device, browser, network, or workplace support. This pattern is more consistent with the device clock, operating system, security software, proxy, VPN, or network than with one WordPress site.
Conclusion
The warning is your browser’s way of saying it cannot verify the protected connection yet. Use the scope of the problem to choose your path: visitors should check the address, device, browser, and network, while WordPress owners should start with the certificate and HTTPS setup. Do not enter sensitive information until the warning is resolved.
Once the connection works, verify every important address and monitor renewal, redirects, caches, and unexpected site changes with this WordPress security maintenance checklist. A certificate problem and a malware problem need different fixes, so keeping those investigations separate helps you resolve the warning safely and keep it from returning.
