01-09-2020 08:29 AM
01-09-2020 08:29 AM
On a number of sites, I get a certificate error, NET::ERR_CERT_COMMON_NAME_INVALID.
The sites work fine in IE, Chrome, Firefox and old Edge
For example if I go to https://myapplications.microsoft.com/, I get the error and the certifcate is issued to graph.windows.net. If I go to Engadget it redirects me to https://consent.yahoo.com/ and i get the error and the cert is for guce.oath.com with no SAN for the orginal site. There are other example to.
Why is this just an issue in Edge Chromium (running Dev channel 81)?
01-09-2020 08:53 AM
@Andrew Sparks This was an error I received regularly, on this and the previous version of Dev on particular sites. What worked for me was to Reset Settings to default, and Clear All Browsing Data. All I kept was my Passwords. After restarting I could access those sites without a problem.
01-13-2020 06:41 AM
thanks both for the replies, unfortuenly neither of these have worked, even updating to Version 81.0.381.0 (Official build) dev (64-bit) has not resolved the issue
01-14-2020 06:01 AM
@bradmacdonald Thanks but I need to use my work account as I'm tetsing the new workspaces. myapps works but the new experience myapplications.microsoft.com gives the cert error.
As I said all work fine in Chrome, IE, Firefox and the old edge, so I will have to use one of them for now
10 hours ago
@Andrew Sparks Thanks for the report! This issue should be fixed by now, as Edge Dev should contain the workaround/fix.
Using my psychic debugging skills, I predict that your network has deployed a ZScaler network interception device. If you're still on a build with the problem, try upgrading. If you can't for whatever reason, as a workaround, try:
1. Close all Edge instances.
2. Win+R and run
3. Retry the sites.
These ZScaler devices attempt to parse the ClientHello TLS message before sending the request to the target server. However, if a ClientHello message spans multiple packets (as will happen when the request is large) the ZScaler device does not see the ServerNameIndicator TLS extension in the client hello and fails to send that extension to the target server. As a consequence the target server gets a request without the SNI telling it what certificate to return to the client, and depending on the configuration, it sends the wrong certificate, meaning that the hostname(s) in the certificate do not match the URL requested, leading to the security error message.
Now, why did the ClientHello messages start getting large? There was an experiment (see https://crbug.com/1028602) that resulted in the key_share TLS extension growing by ~1200 bytes, causing the ClientHello to grow bigger than what could fit in one TCP/IP packet.
1. Zscaler is working on a fix for their software. Your network admins will need to deploy the update when available.
2. The reason that it doesn't repro in Edge Stable is that the regression landed in Chromium 80.0.3967.0, and the reason it doesn't repro in Edge Dev/Canary is it was disabled in 81.0.4021.0.
For Edge 80 Beta, it was fixed in Edge Beta v80.0.361.33 because that uses Chromium v80.0.3987.53.