I am able to reproduce this issue in latest stable -56.0.2924.76 but works fine in previous stable M55- 55.0.2883.87.

Working on bisect to find the suspect.

Able to reproduce the issue on Windows 10, Mac 10.12.2 and Ubuntu 14.04 using chrome reported version #56.0.2924.76 and latest canary #58.0.2997.0.

Bisect Information:
=====================
Good build: 56.0.2898.0	 Revision(426930)

Bad Build : 56.0.2899.0  Revision(426989)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/715e724f5eb62b3517f093cadf5716e0fb3040ea..4177ecbfc8cbe19cbe48ca3da2052f3d83aec5e5

From the above change log suspecting below change

Review url: https://chromiumcodereview.appspot.com/2442883002

davidben@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Performed per-revision bisect on both Linux and Windows for confirmation on bisect result.

Thanks...!!

I found an error on the FreightCenter.com server logs

An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

I'm pretty sure we have a valid TLS 1.2 cert installed on the server.

Here is my diagnosis:

We are hosting on Windows Server 2012 R2, and apparently TLS 1.2 is broken, even with update KB2929781, TLS 1.2 breaks. We disabled TLS 1.2 in Windows to see if Chrome would work with TLS 1.1 to no avail. 

Windows is trying to negotiate a key exchange using sha1 & rsa since TLS sha256 fails. My guess is that Chrome 56 no longer supports sha1.

Here are some details I've found about the error I am receiving on Windows Server 2012: https://social.technet.microsoft.com/Forums/office/en-US/bc2381fb-4fb0-4b74-84a0-6a3adccda8d0/schannel-eventid-36888-fatal-alert-40-error-state-12051207-etc?forum=winservergen

Here are the details I linked above that should be taken into account: 

An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

When using a SHA256 SSL certificate (server authentication) in ISS default website bindings the server immediately issues a connection reset after client hello is received.   

The client(s) sending the client hello do not adhere to the TLS 1.2 specification in RFC 5246 - http://tools.ietf.org/html/rfc5246

The Developers are referencing section: 7.4.1.4.1 – Signature Algorithms

If the client does not send the signature_algorithms extension, the

server MUST do the following:

- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,

DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had

sent the value {sha1,rsa}.

TLS 1.2 introduced signature_algorithms extension where the client advertises supported signature and hash algorithm combinations.

The failing clients send TLS 1.2 but do not send the signature_algorithms extension.

RFC 5246 says:

“If the client does not send the signature_algorithms extension, the

server MUST do the following:

- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,

DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had

sent the value {sha1,rsa}…”

When failing clients offers TLS1.2 without signature_algorithms extension, SChannel server assumes that this client only understands SHA1.

If the SChannel server only has a SHA256 certificate, it will terminate the handshake.

However, the same client offering TLS<=1.1 will succeed.

The bottom line is that SChannel servers implement TLS 1.2 RFC strictly (some would argue, too strictly), which results in interop issues with certain primitive clients.

My conclusion: We are using a TLS 1.2 certificate that uses CBC mode (i think), and Chrome 56 removed support for CBC mode

https://developers.google.com/web/updates/2016/12/chrome-56-deprecations

here is the certificate information

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, 256 bit keys, TLS 1.2

I will update my TLS certificate immediately

You want to enable either ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. The CBC-mode construction in TLS is broken.

mentingh@ could you please update thread whether the issue is fixed as per instruction in #9.

The site appears to be working now, and I see it's using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 now, which is one of our preferred ciphers. I'll go ahead and close this.