IIS Express experiences compatibility issues on Windows 11 when TLS 1.3 is used, especially when client certificates are involved.
The problem affects developers who use the lightweight web server to test and validate applications locally. Microsoft has acknowledged the bug, but it is unlikely that a structural solution will be found anytime soon.
TLS 1.3 offers better security and performance than its predecessor TLS 1.2, but omits an important feature: renegotiation. This functionality was used by servers such as IIS Express to request a client certificate only after the initial handshake. Because TLS 1.3 does not support this mechanism, IIS Express crashes with mTLS configurations. For Windows 11 versions prior to 24H2 and for Windows Server 2022, this results in a broken connection with the error message ERR_CONNECTION_RESET. On Windows 11 24H2 and Windows Server 2025, this is accompanied by an HTTP 500 error with the code 0x80070032, which simply means “not supported.”
Three temporary solutions
Microsoft points to three temporary solutions that developers can apply. Disabling TLS 1.3 via the Windows registry is the most direct route, although this affects all applications on the system and falls back to TLS 1.2. Another option is to modify the http.sys binding via the netsh command, which requests the client certificate during the initial handshake. Removing the client certificate requirement from the configuration is also an option, but this is mainly suitable for development environments.
According to reports from Neowin, a Microsoft employee has indicated that they do not know whether an official fix will ever be released and, if so, what it would look like. In theory, TLS 1.3 does have an alternative method, namely post-handshake client authentication, but this is not supported by most browsers. In addition, IIS and IIS Express are based on the Windows http.sys kernel driver. This layer handles the TLS negotiation entirely before IIS itself comes into play, which means that the problem actually lies in the architecture of the underlying system.
The likelihood of developers finding a permanent solution in the near future therefore seems slim. For the time being, they will have to rely on workarounds that are more or less suitable depending on the situation. Anyone who wants to continue using TLS 1.3 in combination with IIS Express will therefore have to make compromises.