SOLVED

Certifcate Errors only in Edge Insider

Brass Contributor

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)?

8 Replies

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

 

Hi,
try disabling your extensions, see if it changes anything

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

@Andrew Sparks Not sure if this would help or not, but to get to my work's myapplications site, I had to log in using my work ID (e-mail and password), as opposed to my personal user ID/password.

@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

best response confirmed by Andrew Sparks (Brass Contributor)
Solution

@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

 

   msedge.exe --disable-features=PostQuantumCECPQ

 

3. Retry the sites.

Technical explanation:
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. 

What's next:

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.

@Eric_Lawrence Oh my, you are good! We are using Zscaler and I've updated this weekend to Version 81.0.396.0 and its working again. Thanks!

@Eric_Lawrence 

Hi,

I am on Version 84.0.522.52 (Official build) (64-bit) but still, I am getting the error. But after some seconds of showing error page, it redirects me to the page but not always. Sometimes many ajax requests from the site gets failed. I tried clearing my 4 weeks browsing data as well.

 

The page I am trying to access is my community page created on Tribe and later I got the URL changed through CNAME mapping at my domain.

Is it Microsoft edge issue or tribe's or my CNAME configurations? Please help.

1 best response

Accepted Solutions
best response confirmed by Andrew Sparks (Brass Contributor)
Solution

@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

 

   msedge.exe --disable-features=PostQuantumCECPQ

 

3. Retry the sites.

Technical explanation:
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. 

What's next:

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.

View solution in original post