1

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
  • Are you seeing this accessing dynamic content, static content, or both? Have you tried sniffing the SSL negotiation, too? – Evan Anderson Nov 17 '14 at 22:43
  • 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 Nov 17 '14 at 23:05
  • Thanks again Evan - I've updated the question with packets from a failing machine. Successful machines use TLS 1.1. Strange - yeah? – SteadH Nov 18 '14 at 0:28
2

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.