Google Chrome Returns err_connection_aborted, all other browsers display site

Question

We're hosting a website with IIS on Windows Server 2012. Normally, the site is accessible from any browser. We're seeing the site intermittently accessible on campus when using Google Chrome. The chrome error is: err_connection_aborted. A user that gets this error can immediately open Firefox or IE and access the site. This issue only seems to affect Windows Chrome, that I've seen so far.

Here's what I've tried:

• Disabling AV (TrendMicro OfficeScan, not Kaspersky like in http://community.spiceworks.com/topic/330365-103-net-err_connection_aborted-unknown-error)
• Checking Certificate Chain - on a Chrome that works, the certificate chain reports that the intermediate and root certs are OK and the site shows the green lock and reports all is well
• Checking our other sites that use the same Digicert wildcard certificate: no reported issues on those sites
• Windows update history - Installed five days ago, but issues didn't start until today
• NSLOOKUP on a failing machine reports the correct server address (same address as good machine)
• Uninstall and reinstall Chrome does not fix
• Restarting IIS. This looks like it helped this morning, but a different set of computers came up with the issue.
• Other subdomains hosted on this server result in the same Chrome error - which makes me think that IIS could be to blame.
• Clear cache in Chrome and Restart Computer - No luck
• Chrome is up to date

I'm not totally sure where to go next. I appreciate any and all suggestions and requests for clarification. I am suspicious that this is an IIS issue, since it seems to have come up suddenly with no change to client configuration, but I'm not aware of how/why IIS would be discriminating.

Update - Using incognito mode on chrome always causes the error

Looking at a packet capture - it appears it fails when Chrome uses TLS 1.2. When Chrome uses TLS 1.1 - it works.

Packets from not functioning:

• 633 10.497010000 192.168.2.38 192.168.0.35 TLSv1.2 288 Server Hello, Certificate, Certificate Status, Server Key Exchange, Server Hello Done
• 634 10.497044000 192.168.0.35 192.168.2.38 TCP 54 51200→443 [ACK] Seq=215 Ack=3473 Win=65536 Len=0
• 635 10.497070000 192.168.0.35 192.168.2.38 TCP 54 51200→443 [ACK] Seq=215 Ack=4615 Win=64512 Len=0
• 636 10.498957000 192.168.0.35 192.168.2.38 TLSv1.2 244 Client Key Exchange, Change Cipher Spec, Hello Request, Hello Request
• 637 10.498979000 192.168.2.38 192.168.0.35 TCP 60 443→51199 [RST, ACK] Seq=4615 Ack=405 Win=0 Len=0

Solution

This issue was caused by Microsoft Update KB2992611 which intended to fix some vulnerabilities. Unfortunately, it also caused several SSL issues. Uninstalling the patch worked, and we'll be looking for manual ways to solve the security issues caused by this patch.

http://www.infoworld.com/article/2848574/operating-systems/microsoft-botches-kb-2992611-schannel-patch-tls-alert-code-40-slow-sql-server-block-iis-sites.html

Comments

[Spence]

Are you seeing this accessing dynamic content, static content, or both? Have you tried sniffing the SSL negotiation, too?

[SteadH]

The site is usually dynamic content - but at your suggestion I made a simple html file. I can view it from my desktop (which also displays the site correctly). My Coworker's desktop (which does not currently display the site) won't show the HTML file. We're grabbing Wireshark right now and I'll report back about the SSL negotiation! Is there a better tool than Wireshark for this?

[SteadH]

Thanks again Evan - I've updated the question with packets from a failing machine. Successful machines use TLS 1.1. Strange - yeah?