
Changes in Windows 11 Affecting TLS 1.3 and Client Certificate Requests
Recent statements from Microsoft employee Matt Hamrick highlight significant adjustments in Windows 11’s implementation of Transport Layer Security (TLS) 1.3, particularly in how Internet Information Services (IIS) and IIS Express manage client certificate requests. The lack of support for a process called “renegotiation”in TLS 1.3 is a central issue here. Microsoft introduced this modification to enhance security and efficiency, noting that it will help maintain confidentiality in client authentication while also minimizing round trips and reducing CPU overhead.
The Trade-off Between Security and Compatibility
This shift indicates that while Microsoft aims to bolster security and performance, certain compatibility issues have emerged as a consequence, particularly for specific functionalities within the operating system.
Understanding TLS Renegotiation
To provide context, TLS renegotiation was a feature available in TLS 1.2 and earlier protocols, allowing a server to initiate an additional handshake within an already encrypted session to request a client certificate. In Windows, this renegotiation process is facilitated by the HTTP stack (referred to as http.sys
) and the Schannel security package, which allows IIS or IIS Express to take control only after the initial handshake has concluded.
Behavior Changes in Latest Windows Versions
For installations running versions earlier than Windows 11 24H2 or Windows Server 2022, http.sys
would terminate connections if a client certificate was needed but was not included in the initial setup, particularly when the client does not support post-handshake authentication. However, starting with Windows 11 24H2 and Windows Server 2025, http.sys
now returns a “not supported”error when a client certificate is requested post-handshake. This error triggers IIS to respond with an HTTP 500 status and error code 0x80070032, indicating “ERROR_NOT_SUPPORTED.”
Limitations of Post-HandShake Authentication
Microsoft has clarified that TLS 1.3 prohibits renegotiation. Although the protocol introduces an alternative known as post-handshake client authentication, most users, including major web browsers, have yet to implement it. This limitation means client certificates must be requested during the initial handshake process; otherwise, they cannot be requested later in the session. Due to the architecture of IIS and IIS Express, which operate after http.sys
completes the handshake, advance configuration is necessary to ensure that client certificates are requested at the outset.
Future Fixes and Current Status
As of late August 2025, Microsoft has not proposed a solution for IIS Express, leading Hamrick to express uncertainty about whether a fix will ever be released. He conveyed his indecision, stating, “honestly not sure if there will be a fix and what it will look like if there is.”
About Internet Information Services (IIS)
For context, Internet Information Services is Microsoft’s robust and extensible web server designed for hosting websites and applications on Windows operating systems.IIS
relies on the Windows HTTP.sys
kernel driver for managing TLS/SSL encryption. When configuring an HTTPS binding, IIS records this binding in applicationHost.config
and leverages HTTP.sys
to handle the TLS negotiation with clients, subsequently passing decrypted HTTP requests to IIS for further processing.
What is IIS Express?
In contrast, IIS Express is a lightweight, self-contained version of IIS (starting from version 7) optimized for development and testing purposes. Unlike the full IIS, which requires the Windows Process Activation Service to manage web applications and is intended for production use, IIS Express can operate without administrative privileges for various functions and features simplified configurations.
For more detailed information, you can access the official blog post here on Microsoft’s Tech Community.
Leave a Reply