Please attach the *full* NetLog per these instructions. Thanks!
https://www.chromium.org/for-testers/providing-network-details

Log file is attached.

Thanks you very much, guys.

Deleted: chrome-net-export-log.json 329 KB

chrome-net-export-log.json 329 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I see the server is requesting client certificates and resetting the connection. That suggests that, for whatever reason, it didn't like your client certificate.

You mention this used to work in Chrome 41. Could you capture a NetLog from a working Chrome? Preferably something more recent than 41 if you can. Chrome 41 was four years ago. One would expect that, if we broke something four years ago, this would have already been reported.

It seems that v49 is the last version that works well and v50 has the problem I described.
Those versions don't have the logging method mentioned above (chrome://net-export/). Is there any other way to export the log with those versions?

Thanks.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Open about:net-internals to start logging. Then go to the "Export" tab to export it.

Can you also attach the client certificate you are using? (Just the public half, not the private key.) I have a vague suspicion as to what's going on.

PS: Chrome 50 was almost three years ago. A lot of security fixes go into Chrome releases. I would recommend being much more up-to-date, both for security reasons and because, if problems come up, bug reports are much more actionable and quicker to diagnose when problems are reported more promptly.

Thanks for your reply. 
Both logs and pem file have been attached. Please tell me if something else is missing.

Thanks in advance.

Deleted: net-internals-log v49.json 545 KB

net-internals-log v49.json 545 KB View Download

Deleted: net-internals-log v50.json 343 KB

net-internals-log v50.json 343 KB View Download

Deleted: RxEditor without PK.pem 1.7 KB

RxEditor without PK.pem 1.7 KB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks! Alright, that does partially confirm my suspicions.

In Chrome 50, we removed the insecure TLS version fallback, in order to plug a security hole. Your M49 NetLog shows that your setup is relying on it. For some reason, your server is resetting the connection at TLS 1.2, but not the insecure TLS 1.1 and 1.0.
https://groups.google.com/a/chromium.org/d/msg/security-dev/yz1lU9YTeys/NqDvDJqNEQAJ

It sounds like your server is on Windows? I'm aware of two possible causes on the Windows end, but of course there may be another issue.

1. Windows Schannel is finicky at TLS 1.2 about signature algorithms. If you had, say, an MD5 self-signed certificate, Schannel would reject at TLS 1.2 and potentially ignore it in other contexts. However, assuming "RxEditor without PK.pem" is indeed the client certificate you are using, that doesn't seem to be it. (That certificate uses SHA-1 and the server's CertificateRequest indicates that it accepts SHA-1.)

2. Windows Schannel had a bug around AES-GCM cipher suites ( issue #433406 ) caused by a faulty update. Microsoft quickly fixed that update, but given that you also didn't update Chrome for 4 years, perhaps you failed to take that update too? I see your server is responding with TLS_RSA_WITH_AES_256_GCM_SHA384, so it's possible you are hitting the buggy path.

The advice we got from Microsoft about their Schannel bug was the following:

Server administrators should ensure their software is up-to-date and, if still unresolved, reach out to their software vendor. Affected software vendors should fix bugs in their server implementations and follow the protocol specification. The Windows issue above was addressed in KB3042058. Note that KB3042058 describes important prerequisites that must be installed prior to installing KB3042058.

Perhaps try applying that fix, and any others you've missed? In general, you must take your updates if you expect software on the internet to work. Not updating Chrome for four years is far too long. Had you discovered this issue when the change was made, we would have diagnosed it faster and we may have been able to account for it at the time. Now, it is far too late to make any changes and regress security for the rest of Chrome's users.

> The advice we got from Microsoft about their Schannel bug was the following:
>
> Server administrators should ensure their software is up-to-date and, if still unresolved, reach out to their software vendor. Affected software vendors should fix bugs in their server implementations and follow the protocol specification. The Windows issue above was addressed in KB3042058. Note that KB3042058 describes important prerequisites that must be installed prior to installing KB3042058.

A small correction: I copy-and-pasted that from that link above and copied more text than I intended. The advice from Microsoft is just that issue "was addressed in KB3042058. Note that KB3042058 describes important prerequisites that must be installed prior to installing KB3042058." But the remainder is good advice in general. :-)

Thank you very much for your help!

Meanwhile we had to rollback and use Chromium v47, but I hope that after installing those updates mentioned above, we'll be able to work with latest edition on our Windows 8 Embedded machines.

Thanks again. We really appreciate your help and effort.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot