HTTP/3 is a major change to HTTP. It switches away from using TCP as a transport and TLS separately to using QUIC as a transport which has TLS 1.3 or higher built in. These changes mean that migrating from HTTP/2 to HTTP/3 can uncover unexpected issues due to previously non-problematic configurations. Here are some configurations to check if HTTP/3 is not working on Windows Server 2022 and above.
Checking the basics
First things first: is HTTP/3 properly enabled? This blog post walks through the process of enabling HTTP/3 for http.sys on Windows Server 2022. Earlier versions of Windows Server do not support HTTP/3 in http.sys.
HTTP/3 requires QUIC and by extension TLS 1.3. Check the IIS configuration for the site binding and ensure TLS 1.3 and QUIC are not disabled. Here is an example of an HTTP/3 friendly site binding:
The above steps will turn on HTTP/3 advertising over HTTP/3 ALTSVC frames. If the HTTP/3 clients also expect an alt-svc header to advertise support, check that the service is providing one. Here is an example of the most basic alt-svc header that advertises HTTP/3 support in the IIS “HTTP Response Header” UI:
Narrowing down the issue
If HTTP/3, its dependencies, and its advertisements are properly enabled and it is still not working, try comparing a fresh Windows Server installation against the server under investigation. Be sure to not apply any custom configuration such as GPOs or initialization scripts for this comparison. The intention is to compare the existing server with out-of-the-box Windows Server.
If the fresh install of Windows Server can use HTTP/3 as expected, it is likely that the issue is being caused by non-default Windows TLS configuration. Proceed to the “TLS 1.3 Configuration” section to learn more.
If the fresh installation of Windows Server also cannot use HTTP/3, check the networking environment. HTTP/3 uses QUIC, which requires port 443 UDP to be open on the host and network firewalls. Proxies that perform TLS interception (also known as SSL termination) may also be causing issues.
TLS 1.3 Configuration
TLS 1.3 is supported and enabled by default on Windows 11 and Windows Server 2022 and later operating systems. Check whether TLS 1.3 has been disabled on a supported machine using Transport Layer Security (TLS) registry settings | Microsoft Docs.
HTTP/3 may not be working because the server was previously configured to disable cipher suites that TLS 1.3 requires. Schannel supports only three cipher suites for TLS 1.3:
|
TLS_AES_256_GCM_SHA384 |
Enabled by default |
|
TLS_AES_128_GCM_SHA256 |
Enabled by default |
|
TLS_CHACHA20_POLY1305_SHA256 |
Disabled by default
|
Troubleshooting TLS 1.3 Cipher Suite Configuration:
- To see what TLS cipher suites are currently enabled on a machine, use the PowerShell cmdlet Get-TlsCipherSuites.
- Check that the enabled list output contains at least one supported TLS 1.3 cipher suite listed above.
- Ensure TLS 1.3 cipher suites have not been disabled by Group Policy by checking the following registry key value: “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL”
- If no TLS 1.3 supporting cipher suites are enabled, manually enable one or more by using the PowerShell cmdlet Enable-TlsCipherSuite. They should be added to the top of the priority list using the Position flag, where the highest priority value is 0.
Additional troubleshooting resources
The msquic GitHub repo has several useful documents with additional context specific to QUIC:
- Deployment considerations (link)
- Diagnosing issues (link)
- Settings to tinker with (link)
- Troubleshooting guide (link)
