IIS 7 and Above
IIS 10 briefly fails to load HTTPS page with TCP RST
Last post Jul 22, 2019 09:32 AM by cloudreign
Jul 10, 2019 09:35 AM|cloudreign|LINK
I'm using IIS 10.0 on Windows Server 2016.
A web site is published with both HTTP and HTTPS bindings, this web site is in fact the Okta IWA Desktop SSO agent.
However when browsing from a location with higher latency (315 to 325ms) with Chrome and using HTTPS I briefly get an error page "This site can't be reached" and then I get the expected page.
When the issue occurs the HTTP.sys logs show a ClientCancel error.
I also captured network traffic with Wireshark while reproducing the issue and compared it to a trace from a low latency location.
I noticed the following when the issue is occuring:
Any idea on the possible cause of this behavior?
Jul 10, 2019 02:51 PM|lextm|LINK
Please open a support case via http://support.microsoft.com and share your packet capture with them. A thorough analysis on packets might reveal what's the culprit.
Jul 10, 2019 03:46 PM|cloudreign|LINK
Thanks for your answer.
I did open a case with Microsoft and shared the capture a few hours ago.
They are analyzing the capture, I will post the outcome of the troubleshooting here.
Jul 22, 2019 09:32 AM|cloudreign|LINK
Some progress has been made on this issue.
The Wireshark traces allowed to identify that the issue is occuring when falling back from HTTP/2 to HTTP/1.1.
This fallback occurs because the Okta IWA Desktop SSO web app is using Windows authentication and as stated
here in the IIS 10 documentation HTTP/2 is not supported when using Windows authentication.
Thus I disabled HTTP/2 on the web server by setting the following registry value and rebooting the server:
After the reboot the issue was gone.
It is an acceptable workaround since the IIS web server is only used for the Okta IWA Desktop SSO and it prevents all clients to fall back from HTTP/2 to HTTP/1.1.
Okta has confirmed that at the time of this writing it is a supported configuration for them.
However it is still a workaround and the root cause of the issue has not been identified yet.
The case is still open with Microsoft and I will update this thread if additional insight is provided.