Dev build v80.0.345.0 cert validation fails with Zscaler ZApp

Copper Contributor

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.

18 Replies

@Edward Haynes 

I confirm.

I have the same problem...

@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.

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.

@Geoff165 Ah ok, interesting.  I'm opening a support ticket with Zscaler as well so will pass this on, thanks!

Looks like this is a Chromium 80 issue, Google Chrome dev 80.0.3987.7 is also affected.

@Edward Haynes 

 

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.

@Edward Haynes 

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.

"

@jpellois Thanks for the update.

 

@Geoff165 Zscaler have given me much the same feedback, basically that they are working on a fix and to wait 🤷‍:male_sign: 

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.

The new Dev release appears to have fixed this for us. I'm able to access HTTPS sites without any issue now.

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 1.5.2.7.

Anyone else?

@danielschmidt Yes, I can confirm it's stopped working again with v82 (82.0.432.3) for us as well.

@Steven Newcomb @Edward Haynes 

 

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


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.

 

@Eric_Lawrence @Steven Newcomb @Edward Haynes 

 

Hi Guys,

 

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.

 

Geoff

@Geoff165 - To confirm, are you saying that using the --disable-features=PostQuantumCECPQ2 command line flag unblocks your browsers too?

@Eric_Lawrence 

 

Hi Eric,

 

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.

 

Geoff

@Eric_Lawrence Thanks for the update, turning off PostQuantumCECPQ2 works for me too.

 

Hopefully Zscaler will roll out an update soon.