Did this work before M55?

Are other HTTPS sites affected or just Google?

This is usually caused by a buggy firewall, antivirus, or other networking software/device. Please have the customer describe all such things in their deployment.

Responses from customer:

- Yes, this worked fine prior to M55 update
- Customer can connect to other Https sites just fine (only Google properties are affected)
- Customer has tried disabling both Firewall and Antivirus software; Same result. 
- None of the Chrome extensions appear to be interfering.
- Customer has a transparent proxy in their environment.

Could you ask the customer again to describe exactly what the firewall/antivirus/proxy deployments are used? We need the names of the vendors and products.

We didn't ship much in Chrome 55 on the TLS side, now that RSA-PSS got deferred to M56. There's GREASE, but that wouldn't have a failure mode that only breaks some sites. To confirm, does, say, https://example.com work?

From customer:
"We do not see errors from https://example.com, we can access other https:// sites.  It is just the Google related sites that are giving us problems.  Here is our Firewall information:  Fortenet FWF90D."

The customer also noted that the google sites work fine in other browsers and they are not doing any ssl inspection in the security appliance.

Additional Firewall model/version info:
https://drive.google.com/a/google.com/file/d/0B6fESMmJITTNcFphc2wyNVBRakk/view?usp=sharing

Can the customer check whether they are able to access "https://cert-test.sandbox.google.com/" and take a net-internals log when trying to access that site.

The fallback code was also removed, though that should have been a no-op on Windows. If the customer has other machines (non-Windows) that go through the firewall/proxy, information whether those also fail would be useful.

svaldez@, the customer provided a new net-internals while visiting the url in comment 6:

PII protected:
https://drive.google.com/drive/folders/0B6fESMmJITTNUEp5QzlwbXNmdEk?usp=sharing

To double-check, their Firewall deployment is only active on their wifi connections (assuming Fortinet FWF90D is the ForitWiFi product). Can they check that they aren't using the "Restrict Google Account Usage to Specific Domains" feature and whether this works when they disable "Web Filter" on the proxy?

They are not using the Fortinet feature "Restrict Google Account Usage to Specific Domains" nor are they filtering or ssl inspecting in their appliance.

Any other troubleshooting steps we can take?

Can you have them answer the question in comment #9? The product number suggests the device is only used on Wifi, but the bug is about Ethernet. We need to find a difference between Wifi and Ethernet.

To that end, a working net-internals log on wifi and a broken one on ethernet to compare would also be useful.

Next, when asking for net-internals logs, if some sites work and other don't, please include examples of both sites that do *and* sites that don't work. In most of these cases, the broken sites don't tell us much. From Chrome's perspective, what we're seeing is that we're trying to connect to a site and the network (probably a buggy firewall product) is closing the connection on us. Sometimes the working ones give us information like, say, telling us whether the user has a SSL MITM.

In general, this kind of thing is not something we're well situated to debug, as you may have noticed from us basically asking for everything blindly. It's really best that the enterprise user talk to their firewall vendors. Ultimately, it's almost always a bug in the firewall anyway. The firewall would be where any useful logs are or interesting configuration is. As this stuff is not standard, it's the firewall vendor that should be consulted.

On our end, the only actionable thing is to find out information, determine the problematic vendor, and then ask the enterprise user to file a ticket with the vendor.

The customer is looking for confirmation from an engineer. Looking at their firewall which is a Fortinet 90D for both Wifi and Ethernet, the difference I detect is that SSL inspection, Proxy, and Web filtering are enabled for the Ethernet network. The services are not configured or are turned off but are still enabled in the Ethernet network firewall rule. Having said that, can we jump on a hangout call with the customer as they are highly likely to move to another solution. 

That suggests one of those Ethernet-only features is probably to blame. Can they try disabling them to confirm?

Customer disabled SSL Inspection which resolved the issue.  Closing case.