The client will access a Qlik site such as the HUB/QMC using Google Chrome, however, the site hangs for a long time but does eventually load, or receives one of many error messages (such as This site can’t be reached, INADEQUATE_SECURITY, or ERR_UNEXPECTED.
Example:
err_http2_inadequate_transport_security
This is caused by a combination of Win2012R2 and Win2016 not supporting windows authentication over HTTP2 (HTTP/2) and chrome's handling of the protocol downgrade in combination with the authentication negotiation while using a Windows 10 computer. It’s related to ALPN as well which is a TLS extension for application layer protocol negotiation—HTTP2 needs this in order to function.
Information: If the server requests NTLM or Negotiate scheme negotiation over an HTTP/2 connection, then mark the origin as one that requires HTTP/1.1 (as opposed to HTTP/2) and retry the request without using HTTP/2 (also known as HTTP2). Otherwise the server would reset the retry on HTTP/2 with error code HTTP_1_1_REQUIRED, resulting in an extra roundtrip, and additionally a flash of error page before finally loading about 10 seconds later. It can occur when clients authenticate using Active Directory or NTLM.
Environment:
Qlik Sense Enterprise on Windows
Steps to reproduce the problem:
1. Host a Qlik install on Windows Server 2012/2016 (most often occurs with 2016) with Windows Authentication Enabled (clients may or may not authenticate with Active Directory--doesn’t matter)
2. Using Chrome, a client loads a Qlik webpage such as the Hub or QMC
3. The Chrome error page "This site can't be reached” is displayed for awhile and then the requested site loads. If the page never loads, you’ll see one of the following error messages: “INADEQUATE_SECURITY”, or “ERR_UNEXPECTED” at the very bottom of the webpage’s error screen.
Cause:
This is caused by a combination of some Windows Server 2016 environments not supporting windows authentication over HTTP2 (HTTP/2) with certain cipher suites in addition to Google Chrome's handling of the protocol downgrade in combination with the authentication negotiation with end-users using a Windows 10 computer and Google Chrome or FireFox. It’s related to ALPN as well which is a TLS extension for application layer protocol negotiation—HTTP2 needs this in order to function.
Resolution:
Disabling “HTTP2” support for Chrome (and Firefox if applicable) in Windows 10 and on the Windows Server, then rebooting (required), resolves the problem. This can be done via Regedit or through Chrome flags, depending upon the version of your Operating System and your Chrome version.
In addition, the negotiated cipher suites should be reordered to meet the latest Cipher Suite requirements for HTTP2 specifications may help to resolve the issue, and should be done anyways (IIS Crypto 2.0 is a downloadable program which can assist with this).
If Chrome does not list is under its “flags” option, try entering the following in an elevated RUN prompt in Windows: chrome --disable-http2
Finally, if these do not work, please modify the Windows registry using “Regedit” as follows:
- Open “Regedit” in elevated mode
- Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
- On the right side in the empty space, right click and add 2 new DWORD (32-bit) values: EnableHttp2Tls and EnableHttp2Cleartext
- Ensure both new values have been set to 0 (disabled) by right-clicking the value and clicking modify.
- Restart Win10/Server2016/Server2012R2
