HTTPS & CERTIFICATE TROUBLESHOOTING
How to Fix “Your Connection Is Not Private”
“Your connection is not private” means your browser cannot confidently authenticate an HTTPS connection. The cause may be the website’s certificate, your device, or the network between them—not necessarily a compromised website.
Chrome, Edge, Safari, and Firefox use different wording and error codes. This guide helps visitors narrow down the problem safely and gives website owners practical checks for certificate installation, renewal, and HTTPS configuration.
Start with these safe checks
Verify the address and device clock, record the exact warning, and compare another browser or trusted network. Website owners should then check certificate dates, hostname coverage, and the chain served by the endpoint. Do not enter passwords, payment information, or personal data while a certificate warning remains unresolved.
What Does “Your Connection Is Not Private” Mean?
HTTPS uses TLS to encrypt information in transit and a certificate to help authenticate the requested hostname. Your browser checks whether that hostname is covered, whether the certificate is currently valid, and whether it can build a chain to a trusted certificate authority.
A warning can result from an expired certificate, a hostname mismatch, an untrusted issuer, or missing intermediate certificates. An incorrect device clock, a Wi-Fi captive portal, or network interception can also affect validation. The error code gives a clue, but does not establish the cause by itself.
NET::ERR_CERT_AUTHORITY_INVALIDNET::ERR_CERT_DATE_INVALID
NET::ERR_CERT_COMMON_NAME_INVALID
SEC_ERROR_UNKNOWN_ISSUER
The NET::ERR_CERT codes commonly appear in Chromium-based Chrome and Edge. SEC_ERROR_UNKNOWN_ISSUER is a Firefox message. Safari may say that the connection is not private or that it cannot verify a website’s identity. Exact messages and certificate-viewing controls vary by browser, operating system, and version.
Treat the warning as a reason to pause
Do not bypass certificate warnings on sites handling passwords, payments, or personal information. Do not install an unknown root certificate or turn off verification to make the warning disappear. HSTS-protected sites may deliberately prevent bypassing the warning.
Quick Fixes for Website Visitors
1. Verify the website address
Check the hostname character by character, including www or a subdomain. Use a trusted bookmark or an address supplied by the organization. If a link redirects to an unfamiliar hostname, stop rather than assuming the destination is legitimate.
2. Check the device’s date and time
Confirm the actual date, time, and time zone. Use automatic synchronization when available and correct a failed time sync. A clock far in the past or future can make a valid certificate appear expired or not yet valid. Do not deliberately change the clock to fit an expired certificate.
3. Reload the page
Retry once after confirming the address and clock. A recently corrected server configuration or a temporary connection problem may produce a different result. Repeated refreshes will not renew an expired certificate or fix a hostname mismatch.
4. Try another up-to-date browser
Test the same address on the same device. A difference can point to browser configuration, a managed policy, or trust-store differences; it is not proof that the website is safe. Keep both the browser and operating system updated through their normal update mechanisms.
5. Compare another trusted network
Try a trusted home connection or your own mobile hotspot, where appropriate. If only one network produces the warning, investigate its proxy, filtering, router, or portal. Avoid signing in or sending sensitive information while testing an untrusted connection.
6. Check for a public Wi-Fi captive portal
Use the operating system’s “sign in to network” prompt and confirm that the network belongs to the venue you intended to join. An unfinished portal login can interfere with browsing. Do not bypass a warning on the original website to reach the portal; use another trusted connection if the login process looks suspicious.
7. Review relevant VPN or security software settings
A VPN, proxy, or security product with HTTPS inspection may present its own certificates. Check the vendor’s documented settings or contact IT. On a managed device, do not remove certificates, disable protection, or alter corporate policies without administrator approval.
One device, one network, or every device?
If only one device fails, start with its clock, updates, browser settings, and trust configuration. If several devices fail only on one network, investigate that network. If independent devices and networks fail for the same hostname, a server-side certificate issue becomes more likely. These comparisons narrow the cause; they are not a security guarantee.
Fix the Warning in Google Chrome
Read the detailed warning and record the exact code. NET::ERR_CERT_DATE_INVALID points to date validation, which can involve an expired certificate or an incorrect clock. NET::ERR_CERT_COMMON_NAME_INVALID points to hostname coverage. NET::ERR_CERT_AUTHORITY_INVALID indicates a trust-validation problem; missing intermediates or interception can be involved.
Where your version offers certificate information, inspect the requested hostname, Subject Alternative Names, issuer, and validity dates. The warning details or site-information controls may provide a certificate viewer. You do not need to load an unsafe page to diagnose the issue; if the viewer is unavailable, use a certificate checker or contact the website owner.
Check operating-system time synchronization, update Chrome, and compare another trusted network and device. Review configured proxies or HTTPS-inspecting software with the responsible administrator. If the problem follows the website across those tests, changing local browser settings is unlikely to repair its certificate.
Do not use experimental flags, hidden bypass commands, or options that disable certificate checks. Clearing ordinary browsing cache is not a general certificate repair and will not change the certificate installed on a server.
Fix the Warning in Microsoft Edge
Edge uses Chromium-based certificate checks and often shows the same NET::ERR_CERT codes as Chrome. Record the code and exact address, then view certificate information if the warning or site controls in your version allow it.
On Windows, open Settings → Time & language → Date & time. Confirm the correct time and time zone, enable automatic time when appropriate, and use the synchronization control if available. Menu labels vary by Windows version. Edge on macOS or mobile uses the corresponding device settings.
Test the same URL on another updated browser and a separate trusted connection. If a work-managed device fails while personal devices do not, ask IT to review certificate deployment, proxy inspection, and security policies. Do not add unknown certificates or change managed policies yourself.
When multiple independent clients report the same certificate error, send the provider the hostname and warning details. Updating Edge may help with an outdated client, but it cannot replace a missing certificate or repair an expired server certificate.
Fix the Warning in Safari
On macOS
Verify the full URL, then check System Settings → General → Date & Time on recent macOS versions; older releases use System Preferences. Confirm automatic time and the correct time zone. Install supported macOS/Safari updates through the normal update process, then retest.
Use “Show Details” or the certificate information offered by your Safari version to inspect the hostname, issuer, and dates. Do not select a trust override for an unknown certificate. A private or corporate certificate should be managed by the organization responsible for the device, not accepted simply to remove a warning.
On iPhone and iPad
Check Settings → General → Date & Time and Settings → General → Software Update. Automatic time can be restricted on managed devices. Compare your trusted Wi-Fi connection with mobile data where available; iPads without mobile data can use another trusted network.
If the warning affects multiple updated devices and independent networks, contact the website owner. Do not install an unfamiliar configuration profile or root certificate to visit a public website. Clearing Safari website data may remove local session data, but it does not renew a certificate or correct the server’s certificate chain.
How to Check a Website’s SSL Certificate
Use Hostingcone’s free SSL Certificate Checker to inspect the certificate publicly presented for the exact hostname you are visiting. It reports certificate dates, issuer, hostname coverage, trust verification, and available TLS connection details.
Check the website’s SSL certificate with Hostingcone’s free tool
Compare the expiration and start dates, requested hostname, and Subject Alternative Names. Review the chain result separately. Expiring-soon certificates need renewal planning; a hostname mismatch needs coverage or server configuration changes. If untrusted metadata is shown, it is labelled and must not be treated as a successful validation.
The check samples one public address on port 443 using the Hostingcone server’s trust store. It does not inspect every regional endpoint, validate a private origin behind a proxy, or reproduce every browser’s trust decision. A network failure does not prove that a certificate is expired, and a successful certificate check does not establish that the website is free from malware or other threats.
How Website Owners Can Fix Certificate Errors
Expired SSL Certificate
Renew or replace the certificate and install it on the endpoint actually serving HTTPS. Check automated renewal logs, domain validation, and the deployment/reload step: a successful issuance does not prove the web server is serving the new certificate. Test all affected hostnames after installation and monitor future expiration dates.
Hostname Mismatch
The certificate’s Subject Alternative Names must cover the requested hostname. example.com and www.example.com are distinct names. A wildcard such as *.example.com normally covers shop.example.com, not example.com or a.b.example.com. Reissue with the required names or correct the virtual host/SNI configuration if the wrong site’s certificate is being served.
An HTTPS redirect cannot fix an invalid certificate on the original hostname: the browser checks that connection before following the redirect. Keep valid coverage for old HTTPS names that still redirect visitors.
Untrusted Certificate Authority
A public website normally needs a certificate that chains to a publicly trusted authority. Self-signed certificates and private organizational issuers need an explicitly managed trust model and should not prompt ordinary visitors to install unknown roots. An outdated client trust store can also cause failures; compare supported, updated clients before assuming every case is server-side.
Incomplete Certificate Chain
Configure the server to present the leaf certificate and the required intermediate certificates in the order recommended by the issuer or hosting platform. Clients normally already hold trusted roots. Some clients can obtain missing intermediates while others cannot, so a working result on one device does not prove the chain is complete. Retest after applying the correct chain.
Incorrect HTTPS Configuration
Check certificate assignment for the exact virtual host, SNI handling, and whether the installed key corresponds to the certificate. Review all servers or load-balancer nodes, including destinations reached through AAAA records. Follow the platform’s supported TLS settings rather than disabling validation or enabling obsolete protocols. Some TLS configuration failures produce protocol errors instead of a “not private” warning; capture the precise error.
Cloudflare SSL Issues
A proxied Cloudflare website has two TLS connections: browser to Cloudflare and Cloudflare to the origin. Cloudflare Universal SSL concerns the visitor-facing edge certificate; it does not prove the origin certificate is valid. Check the edge certificate’s activation and hostname coverage separately from the origin configuration.
Full (strict) validates the origin certificate’s trust, dates, and hostname when correctly configured. The origin can use an appropriate publicly trusted certificate or Cloudflare Origin CA certificate. Origin CA certificates are intended for the Cloudflare-to-origin connection and are not generally trusted by browsers connecting directly to the origin. Do not switch to a less strict mode merely to conceal an invalid origin certificate.
Cloudflare error 525 indicates an SSL handshake failure with the origin; 526 indicates invalid origin certificate validation in Full (strict). Those error pages are different from a browser warning about the visitor-facing certificate. A public checker sees the edge certificate for a proxied hostname, so origin problems may require hosting/Cloudflare diagnostics.
SSL Problems After Website Migration
Moving hosts, changing domain names, editing DNS, enabling a proxy, or changing web server configuration can change which endpoint presents a certificate. Confirm that the new server has the required certificate and chain before routing visitors to it.
Compare A and AAAA destinations and check for old DNS answers. IPv4 and IPv6 visitors may reach different servers. During a migration, cached DNS can still direct some clients to the previous host; keep certificate coverage in place where traffic can still arrive. Clearing a local DNS cache may change which server you reach, but it will not renew a certificate.
Check www, the root domain, and any affected subdomains individually. A domain change requires appropriate certificate names, and old HTTPS redirects need their own valid coverage. After a Cloudflare change, validate the edge and origin connections separately.
Explore Hostingcone’s website migration service
Get help with domain pointing and standard DNS configuration
When to Contact Your Hosting Provider
Ask for assistance when the certificate is expired despite automated renewal, the control panel shows one certificate while the server serves another, multiple independent clients fail, or you cannot configure the correct chain. Managed hosting, load balancers, proxies, and shared virtual hosts may require provider-side changes.
Provide the exact hostname, browser error code, affected devices/networks, approximate time, and recent DNS or hosting changes. Share certificate dates and issuer if available. Do not send private keys, passwords, API tokens, or sensitive customer information in an ordinary support request.
Explore Hostingcone SSL Certificates
Request assistance with website repairs and configuration issues
Explore ongoing Hostingcone Website Care
Service scope depends on the plan or work agreed. A certificate or HTTPS issue may involve the hosting environment, DNS provider, proxy, or third-party software, and troubleshooting outcomes are not guaranteed.
Frequently Asked Questions
Why does Chrome say my connection is not private?
Chrome could not validate the HTTPS connection’s certificate. Common causes include expired dates, a hostname mismatch, an untrusted issuer, a missing intermediate, or an incorrect device clock. The exact error code helps narrow the cause.
Is it safe to continue to a website with this warning?
Do not continue to submit passwords, payment details, or personal information while the warning is unresolved. Verify the address and contact the website owner or administrator. Do not disable certificate checks or install unknown certificates as a workaround.
Can an expired SSL certificate cause this error?
Yes. Browsers reject certificates outside their validity period. A wrong device clock can create a similar date-validation error, so check the clock as well as the certificate’s expiration.
Does clearing browser cache fix certificate errors?
It does not renew a certificate, add missing hostname coverage, or repair the server’s chain. Local browser or network state can affect a test, but clearing ordinary browsing cache is not a general fix for certificate validation failures.
What does NET::ERR_CERT_AUTHORITY_INVALID mean?
The browser could not validate the certificate to a trusted authority. Possible causes include a self-signed or private issuer, incomplete chain, or HTTPS interception. Review the chain and device/network trust configuration rather than trusting the issuer name alone.
How do I check whether a website’s certificate has expired?
Inspect the certificate’s validity dates in a browser certificate viewer, where available, or use a verified certificate-checking tool. Check the exact hostname and compare the expiration against the correct current time. A failed connection alone does not prove expiration.
Can Cloudflare cause HTTPS certificate errors?
Edge coverage or activation problems can affect the browser-facing certificate, while origin handshake or certificate failures can produce Cloudflare error pages. These are separate TLS connections. Universal SSL does not establish origin certificate validity.
Why does the warning appear on only one device?
Its clock, updates, trust store, managed policies, or HTTPS-inspecting software may differ. The device may also reach a different network or server. Compare a trusted connection and updated clients, and ask IT before changing managed settings.
How can website owners prevent SSL expiration problems?
Use supported automated renewal, monitor certificate dates and renewal/deployment failures, and verify the certificate actually served after renewal. Check all affected endpoints and hostnames. These practices reduce risk but do not guarantee uninterrupted HTTPS availability.
Need Help Fixing an SSL Certificate Error?
Check your website’s SSL certificate details, explore Hostingcone’s SSL solutions, or get professional assistance with HTTPS configuration issues.
Get help with website troubleshooting through Hostingcone Website Care
Find more certificate troubleshooting guides in Hostingcone’s SSL Troubleshooting Hub.