Enabling HTTP/3 support on Windows Server 2022

Credit and thanks to Matthew Cox and Daniel Ring for implementation work

Windows is currently in preview as announced earlier this year. One of the new features it brings is native support for hosting HTTP/3 services. In this post, we will discuss enable it and how it can benefit web services.

HTTP/3 is a major overhaul of HTTP with performance and security in mind. It uses QUIC as a transport (our HTTP server, http.sys, is using msquic) to gain the benefits of eliminated head of line blocking at the transport layer. This is a significant improvement over HTTP/2 which eliminated head of line blocking only at the HTTP layer with streams that allowed a single HTTP/2 connection to replace a set of HTTP/1.1 connections. HTTP/3 also benefits from many lessons learned in HTTP/2, such as simplifying the protocol by removing prioritization.

The HTTP/3 standard is nearly complete; its final publication as an RFC is only waiting on formal process at this point. It is already supported by major browsers which means web services are ready to benefit from deploying it.

One thing to note before proceeding: these instructions presume there were no changes made to the list of enabled cipher suites on the Windows installation. If this is not the case, consult RFC9001 (“Using TLS to Secure QUIC”) and ensure there are some cipher suites in common between the server and its expected clients. HTTP/3 is built on QUIC which requires 1.3. Turning off TLS 1.3 or disabling TLS 1.3 cipher suites will result in HTTP/3 deployment failures. See “TLS Cipher Suites in Windows Server 2022” to learn add cipher suites and which ones are enabled by default.

HTTP/3 support is opt-in on Windows via a registry key named “EnableHttp3” with value 1 at “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesHTTPParameters”. Running this command from an elevated prompt will create the key:

reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesHTTPParameters" /v EnableHttp3 /t REG_DWORD /d 1 /f

Once this key is set, either restart the http.sys service or reboot Windows to apply the setting.

It is likely the web service will need to advertise it is available over HTTP/3 as well using “Alt-Svc” headers in HTTP/2 responses (though this can also be done using HTTP/2 ALTSVC frames). This allows clients who connect over HTTP/2 to learn the service's HTTP/3 endpoint and use that going forward. This is done by sending an HTTP/3 ALPN (“Application-layer Protocol Negotiation”) identifier with HTTP/2 responses advertising a specific version of HTTP/3 to use for future requests. Sending the ALTSVC frame  can be done by http.sys. That can be enabled by setting the “EnableAltSvc” registry key with the command below. To apply the setting, restart http.sys or reboot Windows.

"HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesHTTPParameters" /v EnableAltSvc /t REG_DWORD /d 1 /f

If all goes well, the service will start serving content over HTTP/3. To ensure this is happening, use Edge to verify the protocol used to serve the web request. Right click on the page, select “Inspect”, then select the “” tab. If only “h2” is being used in the “Protocol” column instead of “h3”, try refreshing the page to ensure the ALPN is being honored (the first request will use HTTP/2 which will then advertise HTTP/3 support to Edge for future requests).

I tried this on a freshly installed instance, but I got no QUIC response, although I do see TLS 1.3 being used. I added both registry keys and restarted the server. I also cleared the browser cache and reloaded my IIS website multiple times. Any idea, this?

Also, on another machine I did an in-place update from 2019 auf 2022 and on this server I don't even get a TLS 1.3 connection. The browser is stuck on 1.2. Any idea, why this may happen?


This article was originally published by Microsoft's Core Infrastructure and Security Blog. You can find the original article here.