Dec 09 2019 09:55 AM
Dec 09 2019 09:55 AM
Since the update 80.0.345.0, I'm having lots of sites are failing to open due to an invalid certificate. If the site is using HSTS click through is prevented.
We're using Zscaler and this seems to be an incompatibility with Zscaler's ZApp (see screenshots).
If I disable Zscaler it works ok and other browsers (Brave, Firefox, IE) work ok, this is only affecting Edge Dev.
An example is https://microsoftedgeinsider.com
It seems that ZApp (performing SSL inspection) is getting confused about the requested FQDN and is presenting an incorrect certificate.
Dec 15 2019 08:44 PM
@Edward Haynes I have had similar experience on this site. I found mention that Chrome was enforcing HSTS in the same way. From observation the address in the URL bar is not matching the Subject or any of the SANS. I need to dig again I believe the issue is to do with the Certificate Template used for the proxy.
Dec 15 2019 08:57 PM
https://help.mulesoft.com/s/article/chrome-net-err-cert-common-name-invalid is the URL I found that suggested that the mismatch between the URL address, common name and SANs is the cause.
Dec 16 2019 02:37 AM
@Geoff165 Ah ok, interesting. I'm opening a support ticket with Zscaler as well so will pass this on, thanks!
Dec 16 2019 05:45 AM
Dec 18 2019 04:05 PM
Hi Edward, have ZScaler provided any guidance yet? I held back until this weeks Insider release hoping it would be addressed by MS.
My gues is that the first certificate encountered is the one that ZScaler brokers and because the address doesn't match any named n the certificate HSTS says no.
Dec 19 2019 02:28 AM
answer from Zscaler zupport :
We are aware of that issue. There is a ticket opened internally for that (BUG-67731).
Certificate related issues seem to be only happening with Zscaler APP and Explicit Proxy mode (Dedicated Port, PAC file). When Client Hello is fragmented, we are not able to get the SNI from client hello.
Hence our outbound connection does not have SNI, this causing issues with certificate.
Everything works fine with transparent forwarding methods (IPSEC/GRE Tunnel).
Can you please get in contact with Microsoft and Google to get that checked?
Temporary solution for users who are using browsers based on Chromium 80 is adding affected URLs to SSL Inspection bypass list.
Dec 23 2019 01:56 AM
Jan 13 2020 01:55 AM
Just had an update from Zscaler support on this, the fix is estimated to be pushed for 5.7 version of Zscaler on 17th for ZS3 and 24th for the rest of the clouds.
Jan 24 2020 08:13 AM
Feb 27 2020 08:44 AM
It seemed like this problem had been fixed for a little while, but I am again unable to access HTTPS sites with Edge Dev 82.0.432.3 and Zscaler 18.104.22.168.
Feb 27 2020 09:00 AM
@danielschmidt Yes, I can confirm it's stopped working again with v82 (82.0.432.3) for us as well.
Feb 27 2020 01:37 PM
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: https://crbug.com/1028602
As seen earlier in this thread, 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
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.
Feb 27 2020 03:38 PM
we do not run the ZScaler app. Tried it on our iDevices and got lots of whining about battery life and then found that it could not competently switch between IPv4 and IPv6 networks.
So we run some on-prem vZens to allow for IP pinning to our gateway for some vendor licensing and intra-government traffic. The 82 engine manifests as gateway timeouts for any TLS site rather than declaring it unsafe.
Looking forward to seeing how long it takes ZScaler to react to this update.
Feb 27 2020 03:42 PM
Feb 27 2020 03:55 PM
to be honest I had not tried until you asked. Set up a shortcut on my desktop and away I go, a functional browser again.
Feb 28 2020 01:07 AM
@ericlaw Thanks for the update, turning off PostQuantumCECPQ2 works for me too.
Hopefully Zscaler will roll out an update soon.