Summary
Environment: Windows Server 2016, IIS 10, MSSQL 2008, SSRS, ASP.NET webforms site, Wildcard SSL/TLS Certificate, IIS URL Rewrite 2.1 (MS supported download)
Issue Summary: Two of the site features i.e. downloading files and displaying SSRS reports fail with a first-time-processing error or fail entirely, depending upon the browser, with the SSL certificate bound to the site. Subsequent attempts to execute these features within the same browser window succeed in most cases. Various browsers fail in different ways and some don't fail at all depending upon the browser in question. Please bear with me as I try to provide details below.
NOTE: Both features work fine without the SSL certificate in the mix.
I have scoured the Internet for a solution to no avail and would be very grateful for any assistance on this.
Goal: a) Determine and resolve the root cause(s) of the issue, b) [preferred] Get the two failing features working without users having to change settings on their browser, c) get the two failing features working, period, without first-time-processing issues on ubiquitous browsers (Chrome, FF, Edge, IE, Safari, Opera).
Details
I have a client with an ASP.NET Webforms site containing file download and SSRS report display features. Users must be logged in to access these features. Sadly, the site uses a rudimentary, homegrown approach for authenticating users i.e. it's not a "formal" authentication framework ... could this be part of the issue?
Both of the aforementioned features have been working flawlessly for years using all current, major browsers. My client recently purchased a wildcard SSL/TLS certificate which I installed on the production IIS instance and configured the appropriate site bindings. In case this matters, the site is also using URL Rewrite with a basic <rewrite> rule in the web.config to modify all HTTP protocol requests to the HTTPS protocol.
All aspects of the site work fine with the SSL certificate in place except file downloading and SSRS report displaying. Current versions of Chrome and Firefox [Windows], and Mac browsers (I don't have first-hand access to a Mac environment) are exhibiting errant behavior. IE 11 (go figure) appears to be the only browser with no issues whatsoever. I have not tested Edge as I don't have access to that browser version.
File Downloading
The site has a feature that allows users to download files from the site.
Chrome
Chrome displays a first-time-processing error "Failed - Network error" shown in the download status bar at the bottom of the browser. Clicking the chevron in the error message and choosing the "Resume" option from the context menu completes the download but, any attempt to open (double-click) the zip archive from its actual folder location results in the following error message: "Windows cannot open the folder. The Compressed (zipped) Folder '{path}' is invalid." Repeating the file download operation in the same browser window works fine (culminating in a successfully downloaded, valid zip archive) and all subsequent file download attempts also succeed with no further issues for the remainder of the life of that browser instance. If the user closes their browser (all Chrome instances must be closed) and then re-opens Chrome navigating to the site, the browser, again exhibits the first-time-processing error and then works fine from then on for the remainder of the life of that browser window.
NOTE: All instances of the Chrome browser must be closed to reproduce the issue a second time. If the user leaves even one Chrome instance open on their computer and then navigates to the site using a new browser window and retries the file download, there are no issues. Perhaps Chrome is caching some kind of an authentication token? I am intentionally shying away from using the term "session" as the behavior does not appear to be session related. Opening a new tab within Chrome (after experiencing the aforementioned first-time-processing behavior) and navigating to the site (which culminates in a new session) does not exhibit the issue.
Firefox
Firefox displays a "Secure Connection Failed" error message when trying to download files from the site. All subsequent attempts continue to fail. This differs from Chrome's first-time-processing only behavior. Modifying the Firefox advanced preference "network.http.spdy.enabled.http2" from true (the default) to false permanently resolves the issue.
IE 11
IE 11 does not fail at all. No browser settings were altered from the default installation of IE 11.
Mac Browsers
Mac users report that file download attempts appear to succeed but attempts to open the zip archive culminate in the Mac environment thinking that the zip archive is password protected. NOTE: There is no explicit assigning of a password to the zip archive in the code that processes the download request. No users in Windows environments report this behavior.
SSRS Report Display
The site has a feature to display a PDF document created at runtime from SSRS. The PDF displays directly in the browser window (as opposed to immediately initiating a download operation).
Chrome
Chrome displays a similar first-time-processing error when the user attempts to display an SSRS report. The browser displays the following error message: "Error Failed to load PDF document." The error message has a "Reload" button which culminates in the report displaying successfully. All subsequent attempts to display reports in the same browser window succeed with no further issues. The first-time-processing behavior is, again, experienced when the user closes and re-opens Chrome to the site, and retries the report display.
NOTE: It is interesting that in Chrome with either feature (file downloading or SSRS report display), once the user has experienced the first-time-processing issue with either feature, then the other feature works fine with no issues for the life of that browser instance. Example: User opens new Chrome instance, navigates to site, and attempts to download files. The file download will fail the first time. Immediately attempting to display a report succeeds ... and vice versa.
Firefox
Firefox displays the same "Secure Connection Failed" error message as was the case with the file downloading feature. Modifying the same Firefox advanced preference "network.http.spdy.enabled.http2" from true (the default) to false permanently resolves the issue.
IE 11
IE 11 does not fail at all. No browser settings were altered from the default installation of IE 11.
What I have tried:
I've disabled all URL Rewrite rules in case that had an adverse affect ... but, all errant browsers exhibit the described behavior with or without the URL Rewrite rules in place.
I enabled Failed Request Tracing and analyzed the results (I am not a trace expert by any means). All of the first-time failures culminate in a 200 HttpStatus code (i.e. OK).
- For file download first-time-processing errors, the GENERAL_FLUSH_RESPONSE_END section in the trace indicates that "The parameter is incorrect. (0x80070057)". I do not know what parameter this message is referencing.
- For SSRS report display first-time-processing errors, the GENERAL_FLUSH_RESPONSE_END section in the trace indicates that "An operation was attempted on a nonexistent network connection. (0x800704cd)".
Analysis of Windows Server event logs revealed the following:
- For file download first-time-processing errors, there were no event logs of any kind.
- For SSRS report display first-time-processing errors, the Application event log has a Warning level entry (Source: ASP.NET, EventID: 1309) indicating a HttpException with the exception message of "The remote host closed the connection. The error code is 0x800704CD."
Submit an article or tip