“Bağlantınız Özel Değil” Hatası Nasıl Giderilir

“Your connection is not private” is not an error. It is a screen. Chrome puts it in front of roughly a dozen different failures, and the only thing that identifies yours is a short line of grey text in the middle of the page, printed in capitals and smaller than everything around it.

Quick answer:

“Your connection is not private” is Chrome’s certificate warning screen, shown when the browser rejects a site’s certificate before any data is exchanged. Find the code in small capitals under the message, for example NET::ERR_CERT_AUTHORITY_INVALID or NET::ERR_CERT_DATE_INVALID: that code identifies the actual problem.

Then open the same site on a different network, such as a phone on mobile data. If it loads there, the fault is local: usually an unlogged-in Wi-Fi portal, a wrong device clock, or antivirus inspecting your traffic. If it fails everywhere, only the site operator can fix it, normally by reinstalling the full chain or replacing an expired certificate.

Firefox and Safari show their own screens for the same conditions, so the phrase depends on the browser, not the problem.

What the “Your Connection Is Not Private” Screen Actually Is

When a browser opens an HTTPS connection, the server presents a certificate, and before any page content moves the browser checks it: that a certificate authority it trusts signed it, that it covers the hostname you typed, that the current time falls inside its validity window, and that it has not been revoked. If any check fails the connection is abandoned, and nothing you typed was ever sent.

What you see next is an interstitial, a full-page block between you and the site. In Chromium, the engine behind Chrome, Edge, Brave, Opera and Vivaldi, it is assembled from fixed strings: the heading “Your connection is not private”, then “Attackers might be trying to steal your information from” plus the site name and “(for example, passwords, messages, or credit cards)”. Those are the same two sentences for every certificate failure Chromium blocks on, not a description of your problem, which is why the small line underneath is the only part of the page worth reading.

The wording is honest on one point: the browser is not saying the site is malicious, only that it could not prove the site is who it claims to be. A misconfigured server and an interception attempt produce identical evidence at this stage, so it refuses to guess.

Find Your Error Code First

On the warning page, look between the paragraph of text and the buttons. You will see something like NET::ERR_CERT_COMMON_NAME_INVALID. Chromium’s stylesheet renders it at 0.8 times the surrounding text size and forces uppercase, which is why the code always appears in capitals even though the internal name is mixed case.

If you cannot see a code, click Advanced, where some builds put it with a longer explanation. Write it down before changing anything, because several remedies below change which error you get rather than removing it.

The rule that decides which errors get this screen

Chromium does not choose this screen by inspecting what went wrong. It chooses by number. Every network failure has a negative integer, and certificate errors occupy one contiguous block of them. A single function decides membership:

bool IsCertificateError(int error) {
  return (error <= ERR_CERT_BEGIN && error > ERR_CERT_END) ||
         (error == ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN);
}

ERR_CERT_BEGIN is NET::ERR_CERT_COMMON_NAME_INVALID at -200 and ERR_CERT_END is -220, so the certificate family runs from -200 to -219 inclusive, with one documented exception bolted on: NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN at -150 counts as a certificate error too. The network stack routes on exactly that test: what it matches gets the certificate warning, everything else gets the ordinary error page.

Two codes listed under this warning across the web are not certificate errors at all:

• ERR_SSL_PROTOCOL_ERROR is -107.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH is -113.

Both sit far outside the range, so neither can produce this screen. They produce a different page, headed This site can’t provide a secure connection, with a Reload button rather than an Advanced link. If that is your heading, read ERR_SSL_PROTOCOL_ERROR or ERR_SSL_VERSION_OR_CIPHER_MISMATCH instead: those are handshake failures, with nothing to proceed past.

Chrome does not always use this screen

Before falling back to the generic warning, Chrome checks for conditions it can name precisely. Each of these pages has already done part of your diagnosis:

• Your clock is behind or Your clock is ahead, with an Update date and time button. Chrome shows this when your system clock and a network time source disagree by more than the measurement uncertainty plus five minutes.
• Connect to Wi-Fi or Connect to network, with a Connect button: the operating system has reported a captive portal.
• An application is stopping Chrome from safely connecting to this site, naming the program on your machine that is intercepting HTTPS.

The plain “Your connection is not private” screen means Chrome matched none of them.

Triage Table: What Your Code Means

Find your code, confirm who can act on it, then follow the link for the full procedure. The “Fixed by” column decides whether to troubleshoot at all or contact the site.

Code	What went wrong	Fixed by
NET::ERR_CERT_COMMON_NAME_INVALID	The certificate does not list the hostname you visited.	Site owner, or the network you are on
NET::ERR_CERT_DATE_INVALID	The certificate has expired or has not started yet, measured against your clock.	Either
NET::ERR_CERT_AUTHORITY_INVALID	The issuer is not trusted: self-signed, a private CA, or a missing intermediate certificate.	Site owner, or local software
NET::ERR_CERT_REVOKED	The CA cancelled the certificate before its expiry date. No proceed option.	Site owner
NET::ERR_CERT_INVALID	The certificate could not be parsed or is structurally broken. Current Chrome may also report a SHA-1 certificate under this code rather than the weak signature one below. No proceed option.	Site owner
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM	The certificate is signed with an algorithm no longer considered sound, typically SHA-1.	Site owner
NET::ERR_CERT_WEAK_KEY	The key is too small, for example an RSA key under 2048 bits.	Site owner
NET::ERR_CERT_VALIDITY_TOO_LONG	The lifetime exceeds the maximum browsers accept.	Site owner
NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED	The certificate was not published to public Certificate Transparency logs.	Site owner
NET::ERR_CERT_KNOWN_INTERCEPTION_BLOCKED	The certificate belongs to a known traffic interception product.	Whoever manages the device or network
NET::ERR_CERT_SELF_SIGNED_LOCAL_NETWORK	A self-signed certificate on a private address or a .local name, such as a router or NAS.	Device owner
NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN	The chain does not contain the key the site pinned. No proceed option.	Site owner, or interception software

Rarer codes fill the remaining slots: NET::ERR_CERT_CONTAINS_ERRORS, which also offers no proceed option, plus NET::ERR_CERT_NO_REVOCATION_MECHANISM, NET::ERR_CERT_UNABLE_TO_CHECK_REVOCATION, NET::ERR_CERT_NON_UNIQUE_NAME and NET::ERR_CERT_NAME_CONSTRAINT_VIOLATION. All are server-side and all are fixed by reissuing a correctly configured certificate from a publicly trusted CA. NET::ERR_CERT_SYMANTEC_LEGACY, referenced elsewhere, has been removed from Chromium’s error list, so a current browser cannot report it.

The One Test That Splits the Problem

Before trying any fix, spend thirty seconds establishing which half of the problem you have. Open the same URL on a different network and a different device. A phone with Wi-Fi switched off, using mobile data, is the ideal test because it shares nothing with your computer: not the network, not the resolver, not the clock, not the antivirus, not the browser profile.

• It loads on the phone. The certificate is fine. Something between your computer and the internet is the cause, and everything in the visitor section applies to you.
• It fails there too, with the same code. The certificate is genuinely broken. Nothing you do as a visitor will fix it, and the owner section is the relevant one. If it is not your site, tell the operator the exact code.
• It fails with a different code. Usually a partial deployment, where some servers behind a load balancer have the new certificate and some do not.

An SSL Checker gives you the same answer from outside your network without needing a second device. If the checker reports the certificate as valid and installed correctly, the problem is on your side.

Fixes That Work as a Visitor

Ordered by how often they are the real cause, not by ease.

1. You have not signed in to the Wi-Fi yet

This is the most common cause on hotel, airport, cafe and campus networks, and most guides never mention it. A captive portal intercepts your request and answers with its own login page. Because it is answering for a hostname it has no certificate for, the browser sees a mismatch and blocks it, usually with NET::ERR_CERT_COMMON_NAME_INVALID or NET::ERR_CERT_AUTHORITY_INVALID.

Chrome tests for this by requesting a URL that should return an empty 204 No Content response. Run the check yourself:

curl -s -o /dev/null -w "%{http_code}\n" http://connectivitycheck.gstatic.com/generate_204

On a clean network that prints 204. Anything else, typically 200 or a redirect to a login page, means you have not completed the portal login.

To clear it, open a plain HTTP address such as http://neverssl.com, which cannot fail the same way because there is no certificate to check. Sign in on the portal page, then reload the original site.

One correction to advice you will see elsewhere: a VPN does not help here. It cannot connect until the portal has let you onto the network, so it is the one tool that cannot work. Connect it after signing in.

2. Your device clock is wrong

Certificates carry a start time and an end time, and the browser compares them against your device’s clock, so a device set to the wrong date rejects perfectly good certificates. That is why this shows up on a machine whose CMOS battery has died or a phone restored from a backup. The code is NET::ERR_CERT_DATE_INVALID, though Chrome often catches it first and shows the Your clock is behind or Your clock is ahead page instead.

Switch automatic time synchronization on rather than setting the clock by hand, because manual clocks drift and reproduce this error a few months later.

• Windows 11 and Windows 10: Settings, then Time & language, then Date & time. Turn Set time automatically on, set the correct time zone, then use Sync now to force an immediate update.
• macOS Ventura and later: System Settings, then General, then Date & Time. Turn on Set time and date automatically and Set time zone automatically using your current location. On older releases the same controls sit in System Preferences, then Date & Time.
• Android: Settings, then System, then Date & time, and enable the automatic date and time option. The exact path varies between manufacturers.
• iPhone and iPad: Settings, then General, then Date & Time, and turn on Set Automatically.
• Linux: on a systemd distribution, run timedatectl set-ntp true and confirm with timedatectl status, which should report that the system clock is synchronized.
• ChromeOS: Settings, then Advanced, then Date and time, and set the time zone to update automatically. ChromeOS has no manual clock control, so a wrong time is normally a wrong time zone.

To measure the offset without changing anything, on macOS and Linux:

sntp time.apple.com

A healthy result looks like +0.081879 +/- 0.034324 time.apple.com, where the first number is your offset in seconds. Hours or days off is certainly your cause. Our guide to NET::ERR_CERT_DATE_INVALID covers the cases where the certificate rather than your clock is at fault.

3. Antivirus or corporate software is inspecting your traffic

Security products that scan HTTPS break the connection in half: they present their own certificate to your browser, decrypt and inspect the traffic, then re-encrypt it to the real server. For that to be invisible, their root certificate has to sit where the browser looks for roots, and when it does not, every HTTPS site fails at once, usually with NET::ERR_CERT_AUTHORITY_INVALID.

The tell is the scale: every site fails, including ones you know are fine, and only on this machine. A wrong device clock and an out-of-date trust store do the same, so rule those out first. Chrome recognises several of these products by the issuer name and replaces the generic warning with An application is stopping Chrome from safely connecting to this site, naming the software. Its list covers Avast, Bitdefender, Kaspersky, Cisco Umbrella, Forcepoint, Fortinet, McAfee Web Gateway, Sophos, SonicWall, Symantec Blue Coat, Trend Micro and Zscaler, among others. Corporate proxies not on that list produce the plain warning instead.

On a personal machine, turn the HTTPS scanning feature off, or uninstall the product if it will not separate that feature from the rest. Turning off protection entirely is not the fix. On a managed work machine, do neither: the interception is deliberate, and your IT team either has a deployment problem or a policy you cannot override. Our guide to NET::ERR_CERT_AUTHORITY_INVALID covers the untrusted-issuer case.

4. Your DNS answers are being tampered with

Changing DNS servers is standard advice here, almost always given without a mechanism, which makes it look like superstition. There is a real one. DNS translates a hostname into an IP address, and if something returns the wrong address your browser connects to a machine never meant to serve that site. It presents a certificate for its own identity, the name does not match, and you get NET::ERR_CERT_COMMON_NAME_INVALID. Some ISPs do this on mistyped domains, and some malware does it deliberately.

Test before changing anything. Compare what your current resolver says against one you choose:

dig +short example.com A
dig +short @1.1.1.1 example.com A

On Windows without dig installed, use nslookup example.com and nslookup example.com 1.1.1.1. Address sets can legitimately differ between resolvers for large sites behind a CDN, so look for an answer that is unrelated rather than merely reordered. If yours returns something clearly different, change your DNS servers to 1.1.1.1 or 8.8.8.8 and test again. If both agree, DNS is not your problem.

5. A browser extension is interfering

Opening the site in a private or incognito window is a useful test, but not for the reason usually given. Certificate validation there is identical: the same trust store, the same clock, the same checks. What differs is that most extensions are disabled by default, so if the site loads you have not bypassed a certificate check, you have found the cause. Re-enable your extensions one at a time.

6. The device’s list of trusted roots is out of date

Trust ultimately rests on a list of root certificates held by the device or the browser, and that list is not static: roots expire, new ones are introduced, and certificate authorities rotate to them. A device that has stopped receiving updates keeps the list it had, and eventually sites start chaining to a root it has never heard of. The clearest example was the expiry of DST Root CA X3 on September 30, 2021, which broke Let’s Encrypt sites on many older devices in a single day, none of which had anything wrong locally.

How exposed you are depends on which list is consulted. Chrome carries its own root store and ships it with the browser, so keeping Chrome current keeps its list current whatever the operating system. Software that defers to the platform, including Safari and most native apps, is only as current as the OS, which is why this shows up mainly on hardware too old to run a current one.

The tell is that a set of sites fails on one old device while the same sites load on a current one, usually with NET::ERR_CERT_AUTHORITY_INVALID. Install pending operating system and browser updates. If the device can no longer receive them, no change at the site’s end will restore it.

What will not fix this

Four remedies appear in nearly every guide to this error. Each addresses something real, and none of them addresses this:

• Reloading the page. Certificate validation is deterministic. The same certificate and the same clock produce the same verdict every time. Reloading helps with server overload and dropped connections, neither of which produces a certificate error.
• Clearing the browser cache. The cache stores page resources: images, scripts, stylesheets. It holds no certificate state, so emptying it changes nothing about validation. Clearing the separate HSTS and TLS state is a different operation with a different effect, and clearing cookies only helps if the site itself is misbehaving after you get past the warning.
• Connecting a VPN. A VPN moves where your traffic exits, which helps only if the interference is on your local network. It does nothing about an expired or misissued certificate.
• Disabling antivirus wholesale. Only the HTTPS scanning component can cause this. Switching off real-time protection to load one website trades a blocked page for an unprotected machine.

Fixes That Work as the Site Owner

If the site fails from every network, the certificate is the problem. Start with what your server is actually sending, which is often not what you think you installed.

Read what your server is sending

This command answers most of the questions below at once:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

To read just the certificate’s identity and dates, pipe it onward:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

A note on macOS before you rely on any of this. What a Mac installs as openssl is LibreSSL, which rejects several of the options below and disagrees with OpenSSL about at least one verdict, so the commands carry their own warnings. Run openssl version first to see which you have. Installing OpenSSL through Homebrew is not by itself enough, because your PATH may still find the system binary first, so if it still reports LibreSSL, call the full path /opt/homebrew/bin/openssl instead.

Cause 1: the intermediate certificate is missing

This is the most common server-side cause of NET::ERR_CERT_AUTHORITY_INVALID, and the most missed. A certificate authority signs your certificate with an intermediate rather than its root, so your server has to send that intermediate alongside your own for the browser to build a path back to a trusted root.

It goes unnoticed for months because Chrome compensates. When the chain is incomplete, Chrome tries to download the missing intermediate from the address published inside the certificate, a mechanism called AIA fetching, and the page then loads normally. Clients that do not make that request fail instead, which is why the classic symptom is a site that works in your browser and breaks in a native mobile app or an API client.

A complete chain looks like this, each certificate’s issuer appearing as the subject of the next:

Certificate chain
 0 s:CN=example.com
   i:C=US, O=Let's Encrypt, CN=R13
 1 s:C=US, O=Let's Encrypt, CN=R13
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1

An incomplete one sends only certificate 0. Against a deliberately broken test host, OpenSSL is explicit:

$ openssl s_client -connect incomplete-chain.badssl.com:443 \
    -servername incomplete-chain.badssl.com </dev/null

Certificate chain
 0 s:CN=*.badssl.com

verify error:num=20:unable to get local issuer certificate
verify error:num=21:unable to verify the first certificate
Verify return code: 21 (unable to verify the first certificate)

The fix is to install the certificate together with the CA bundle your issuer supplied, in the right order, then reload the web server. Two warnings. The verify error lines go to standard error, so piping through 2>/dev/null discards exactly the lines that prove the fault. And on macOS LibreSSL this test silently passes, printing 0 (ok) for the same broken host, so read the certificate list rather than the summary line. Our guide to an expired or missing intermediate certificate covers the repair per platform.

Cause 2: the wrong virtual host is answering

When several sites share one IP address, the server picks which certificate to present from the hostname the client sends in the TLS handshake, a field called SNI. A request that arrives without SNI, or names a host the server has no configuration for, falls back to the default site and gets that site’s certificate: a name mismatch for a certificate that is perfectly valid, just for a different site.

Connecting to a test server by IP and asking for the right name returns the right certificate:

$ openssl s_client -connect 104.154.89.105:443 -servername badssl.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject

subject=CN=*.badssl.com

Suppressing SNI makes the default site answer instead, and its certificate says so in its own subject:

$ openssl s_client -connect 104.154.89.105:443 -noservername </dev/null 2>/dev/null \
    | openssl x509 -noout -subject

subject=C=US, ST=California, L=San Francisco,
        O=BadSSL Fallback. Unknown subdomain or no SNI.,
        CN=badssl-fallback-unknown-subdomain-or-no-sni

-noservername is required for the second test. Since OpenSSL 1.1.1 the tool fills in SNI automatically from whatever you passed to -connect, so plain s_client -connect host:443 is not a no-SNI test and proves nothing here. LibreSSL rejects the flag, so this comparison cannot be run on a stock Mac.

If the certificate you get back belongs to a different site of yours, the virtual host for the affected name is missing or misconfigured. Check that its server block names the host, that the certificate paths are right, and that it loads.

One trap while editing: a VirtualHost block is valid only in the server configuration, and Apache rejects it in .htaccess, returning 500 Internal Server Error on every request until removed. Our guide to moving from HTTP to HTTPS gives the correct redirect form, along with the mixed content redirects tend to expose.

Cause 3: the certificate covers www but not the bare domain, or the reverse

Browsers match the hostname against the certificate’s Subject Alternative Name list and ignore the Common Name entirely. example.com and www.example.com are separate names, and a certificate covering one does not cover the other. A wildcard does not solve it: *.example.com matches www.example.com but not example.com, because a wildcard covers one label and the bare domain has no label to cover.

Read the actual list and compare it against every name that resolves to your server. The -text form is used rather than -ext because LibreSSL, which is what macOS installs as openssl, does not accept -ext:

$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:*.example.com

That certificate is correct: both forms are listed. If yours lists only one and both resolve, reissue covering both, then redirect permanently onto your canonical hostname. The name mismatch guide covers the reissue.

Cause 4: the certificate expired, and it expires sooner than it used to

Maximum certificate lifetimes are falling on a published schedule agreed by the CA/Browser Forum. The Baseline Requirements now set these limits by issuance date:

• Issued before March 15, 2026: at most 398 days.
• Issued on or after March 15, 2026: at most 200 days.
• Issued on or after March 15, 2027: at most 100 days.
• Issued on or after March 15, 2029: at most 47 days.

The 200-day limit is already in force, so certificates issued today expire in under seven months, and the requirements advise CAs to stay one day under each cap, making issuance 199 days in practice. A yearly renewal habit now lapses mid-year, long before the reminder you set when you bought the certificate. Move to ACME-powered certificate management, which handles validation, issuance and installation automatically, and monitor the live endpoint rather than your records. Our guide to what happens when a certificate expires covers the consequences.

The same schedule explains why NET::ERR_CERT_VALIDITY_TOO_LONG is becoming more common. It is not an expired certificate but one issued with a lifetime longer than browsers accept, which now catches any internal or private CA still stamping out one-year or five-year certificates.

Cause 5: the certificate was created on a machine whose clock was wrong

This one is widely described backwards. The validity dates are written into the certificate when it is issued, and a browser checks them against the visitor’s clock, not against yours. If a public CA issued your certificate, your server’s clock has no bearing on whether visitors accept it, and a drifted server clock on its own produces this error for nobody.

What does produce it is a certificate generated on the machine with the wrong clock: a self-signed certificate, one from an internal CA, an appliance that mints its own, or a freshly imaged VM that came up before time synchronization ran. The wrong time is baked into notBefore, and every client with a correct clock rejects it as not yet valid. On a host running two days fast, the certificate reads:

$ openssl x509 -in cert.pem -noout -dates
notBefore=Jul 24 11:22:59 2026 GMT
notAfter=Aug 21 11:22:59 2026 GMT

$ openssl verify -CAfile cert.pem cert.pem
CN=example.test
error 9 at 0 depth lookup: certificate is not yet valid or the system clock is incorrect
error cert.pem: verification failed

Visitors see NET::ERR_CERT_DATE_INVALID, the same code an expired certificate produces, which is why it gets misdiagnosed as expiry and “fixed” by reissuing on the same unsynchronised host. Check the machine for drift against a clock you trust:

curl -sI https://example.com/ | grep -i "^date:"
date -u '+%a, %d %b %Y %H:%M:%S GMT'

The first line is the server’s idea of the time, the second is yours, and they should agree within a couple of seconds. Fix time synchronization first, then regenerate the certificate: correcting the clock does nothing to the dates already written into the file you installed.

Cause 6: revocation and Certificate Transparency

Two conditions produce this screen with nothing visibly wrong in the certificate file. NET::ERR_CERT_REVOKED means the CA cancelled it, normally because the private key was exposed or the validation behind it was withdrawn. NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED means it was never published to the public logs browsers require for publicly trusted certificates. Both need a replacement certificate, and neither offers the visitor a way through.

OpenSSL will not warn you about either. It performs no revocation check by default, so a revoked certificate reports a clean result:

$ openssl s_client -connect revoked.badssl.com:443 \
    -servername revoked.badssl.com </dev/null 2>/dev/null | grep "Verify return code"

    Verify return code: 0 (ok)

That host is revoked and every current browser blocks it. Use an SSL Checker or a browser rather than reading anything into that line, and see the revoked certificate guide and the Certificate Transparency guide.

That summary line has one further limit: plain s_client skips the hostname check browsers perform, so a certificate issued for the wrong name still reports 0 (ok). Add -verify_hostname example.com when investigating a name mismatch, and note that macOS LibreSSL refuses that flag.

What Each Browser Shows for the Same Problem

The exact phrase “Your connection is not private” belongs to Chromium. Other engines block the same certificates in their own words, so the wording tells you which browser you are in, not what went wrong.

Chrome, Edge and other Chromium browsers

Chrome shows the wording quoted throughout this guide. Edge shows the same screen with the contraction, “Your connection isn’t private”, and the identical code line beneath. Brave, Opera and Vivaldi share the engine and behaviour. Whatever the browser, the NET::ERR_CERT_* code is the part to read.

Firefox

Firefox never used the Chromium phrase, and its warning was redesigned recently, so two layouts are in circulation.

• Current Firefox releases show Warning: Security Risk, with the body heading “Be careful. Something doesn’t look right.” Expanding Advanced reveals the code and, where an exception is permitted, a link reading “Proceed to (site) (Risky)” alongside “Go back (Recommended)”.
• Firefox ESR 140, still supported and common in managed environments, shows the older page headed Warning: Potential Security Risk Ahead.

Firefox codes are named differently but map onto the same conditions: SEC_ERROR_UNKNOWN_ISSUER for an untrusted or missing issuer, matching NET::ERR_CERT_AUTHORITY_INVALID, SEC_ERROR_EXPIRED_CERTIFICATE for an expired one, SSL_ERROR_BAD_CERT_DOMAIN for a name mismatch. Two more are routinely misdescribed:

• MOZILLA_PKIX_ERROR_MITM_DETECTED is not a hacker alert. It means Firefox worked out that something on your own machine is re-signing HTTPS traffic, under the heading “Software is Preventing Firefox From Safely Connecting to This Site”. Firefox ships its own root list through NSS and, because security.enterprise_roots.enabled defaults to true, also imports third-party roots from the Windows and macOS stores, so a correctly installed product normally works. You get this error when that import has not happened or does not cover the root in use. The remedy is the antivirus section above.
• SSL_ERROR_WEAK_SERVER_EPHEMERAL_DH_KEY is a handshake failure rather than a certificate failure, so it does not produce this screen at all, though it is listed among certificate errors often enough to be worth naming. Our guide to SSL_ERROR_NO_CYPHER_OVERLAP covers it.

See our guide to SEC_ERROR_UNKNOWN_ISSUER for the Firefox procedure, the code behind most of these warnings.

Safari

Safari uses the title case form, This Connection Is Not Private, in plainer language: “This website may be impersonating (site) to steal your personal or financial information. You should go back to the previous page.” Where the certificate cannot be trusted at all it adds “Safari warns you when a website has a certificate that is invalid” and says you cannot visit the site.

Safari prints no machine-readable code, which makes it the hardest of the three to diagnose from the screen, so open the same site in Chrome to read it. Safari relies on the system trust store, so a certificate trusted in Keychain Access applies to it.

Android and iPhone

On Android, Chrome shows the same screen as desktop Chrome, with the same wording and the same code line. There is no separate mobile version. The “This site is not secure” phrasing older guides attribute to the long-retired stock Android Browser is not a certificate warning at all: the closest Chromium string, “Your connection to this site is not secure”, is the site information panel shown for plain HTTP pages.

Apps other than browsers behave differently, because a native Android app uses the system trust store and its own network library rather than Chrome’s. A site that loads in Chrome on the phone but fails inside an app usually has a chain problem Chrome is papering over by fetching the missing intermediate itself. For device-specific steps see our guides to fixing the error on Android and on iPhone.

About Clicking Through the Warning

Chrome does offer a way past this screen: click Advanced, then the “Proceed to (site) (unsafe)” link. Plenty of guides present that as routine. It is not.

Proceeding tells the browser to accept a certificate it could not verify. If the cause is a misconfigured server, you have skipped a warning about a harmless mistake. If it is interception, you have handed the interceptor everything you send on that site from then on. The browser cannot tell those apart, which is why it asked, and the decision persists: Chrome remembers a bypass for one week.

A workable line to draw:

• Defensible: your own development server, a device on your own network such as a router or NAS with a self-signed certificate, or a staging site you control, where you know why the certificate is untrusted.
• Not defensible: anything where you sign in, pay, or send personal information. Banking, email, shopping, work systems. If the certificate cannot be verified, neither can the login form on the other side.

Sometimes the choice is not yours. Chrome withholds the proceed option entirely in four conditions: when the site sends an HSTS policy declaring that certificate errors must be fatal, when the certificate has been revoked, when it fails a key pinning check, and when it is too malformed to interpret. Those pages offer no button to proceed anyway, only Reload. Firefox does the same on HSTS sites and on errors it treats as non-overridable. This is deliberate, and the right response is to stop, not to look for a workaround.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.