Your connection isn't private [Zscaler]

Occasional Contributor

Hello everybody,

I'm currently using Microsoft Edge [Version 80.0.355.1 (Official build) dev (64-bit)] in my company network. Since few days ago I started having problems trying to load some websites such as . When I try to access these sites I get the error:


Your connection isn't private
Attackers might be trying to steal your information from <a href="" target="_blank"></a> (for example, passwords, messages, or credit cards).


On some websites I can click "advanced" and then continue, some other times instead I can't.

If I try opening the same websites with Google Chrome I get no error, everything works smoothly.

I guess it could be something related to my company network configuration (we are using Zscaler as a proxy) but I don't understand why it is happening only with some websites and why this issue started only few days ago.

I also compared the certificate details provided by Edge and Chrome, they differ for some reason:






Any idea?

8 Replies
temporary disable all of your extensions (if any) from here: edge://extensions/
also try disabling Tracking prevention: edge://settings/privacy

these are the most probable things that can affect page load and modify connections.

Btw I tried your site and i could access it, using Edge Version 80.0.359.0 (Official build) canary (64-bit)

Hi @HotCakeX, thanks for your help. I tried disabling all the extensions and the tracking prevention but nothing changed.

I would like to provide more details but didn't find anything useful (e.g. the browser console doesn't show any error).

so I think it is a problem with the new Edge dev because you mentioned Google chrome has no problem.
if it was a problem related to certificate or proxy (both of which are system wide) then the same symptoms would be visible in all browsers, not just Edge dev.

please use the feedback button at the top of the browser, after the feedback's mini window appeared, click on the "diagnostic data" and then choose "recreate my problem" .
check the box "I agree..." and press "start recording".
after that load all those problematic websites again and let the browser generate those errors all over again because this time they are being actively recorded. once you're done, click stop recording and send it with your feedback to Microsoft.
you can also add a link of this post of yours in your feedback too for reference

@HotCakeX thanks for the detailed information, I submitted the feedback with diagnostics attached. In the meanwhile I noticed a weird behavior: my PC is configured to use the Zscaler proxy through a configuration script, if I disabled it I am able to reach pages that usually don't work, even though the requests are still passing through Zscaler.

With Chrome, by the way, everything works in both case (proxy script enabled/disabled).

I have the exact same problem with Edge and ZScaler. If it is on I can't get to pages like If I turn ZScaler off it is working fine. It is working all the time in Chrome.

@Par Linderoth thanks for sharing your experience. When you talk about disabling Zscaler, do you mean you are using a PAC script for proxy configuration too?

@paolot No, I actually just have the option to exit the ZScaler application installed on my computer.

There is a known bug in ZScaler here, for which you will need to install their latest update.

You can verify if that ZScaler's bug is the root cause by closing all Edge instances and hitting Win+R, then running

   msedge.exe --disable-features=PostQuantumCECPQ2

If that works, then something on your network path is not compatible with large ClientHello messages in the HTTPS handshake. For instance, older versions of ZScaler are known to have a bug whereby they fail to see the ServerNameIndicator TLS extension if the ClientHello spans multiple packets, and when that happens, the server typically will return the wrong certificate, resulting in a NET::ERR_CERT_COMMON_NAME_INVALID error message. ZScaler has released a fix for this that you'll need to apply.

In other cases, the network device is completely incompatible with handshakes that span multiple packets and an ERR_CONNECTION_RESET will be seen instead. You'll need to talk to your network administrators about contacting the vendor of your networking equipment about getting a fix.

The reason this issue appeared and disappeared only to reappear again is because the PostQuantumCECPQ2 feature was changed to "off-by-default" for version 80/81 but it is now enabled again for version 82.

The upstream issue can be found here: