A Microsoft employee, Matt Hamrick, has confirmed that changes in Windows 11’s default use of Transport Layer Security (TLS) 1.3 affect how Internet Information Services (IIS) and IIS Express handle client certificate requests. The issue stems from TLS 1.3’s lack of support for a feature known as “renegotiation,” as the tech giant says that this drop was to "ensure client authentication is always confidential" and that it also "reduces round trips and CPU costs".
So it looks like Microsoft made things quicker and more secure at the cost of compatibility, at least in the case of certain aspects of the OS.
For those wondering, TLS renegotiation, available in TLS 1.2 and earlier, allows a server to initiate a second handshake within an existing encrypted session to request a client certificate. In Windows, this process is managed by the kernel-mode device driver called the HTTP stack (or http.sys) in combination with the Schannel security package, with IIS or IIS Express receiving control only after the handshake is complete.
On versions prior to Windows 11 24H2 and on Windows Server 2022, http.sys terminates the connection if a client certificate is requested but not negotiated initially, when the client does not support post‑handshake authentication. From Windows 11 24H2 and Windows Server 2025 onward, http.sys instead returns a “not supported” error, allowing IIS to send an HTTP 500 response with error code 0x80070032 which technically means "ERROR_NOT_SUPPORTED".
Microsoft has explained that under TLS 1.3, renegotiation is not permitted. While the protocol defines an alternative called post‑handshake client authentication, Microsoft notes that most clients, including major browsers, have not implemented it.
This limitation means that unless a client certificate is requested during the initial TLS handshake, it cannot be obtained later in the session. For IIS and IIS Express, which operate after http.sys has processed the handshake, this requires advance configuration to request certificates up front.
As of late August 2025, Microsoft has not announced a fix for IIS Express and Hamrick wonders if there will ever be one as he writes that he is "honestly not sure if there will be a fix and what it will look like if there is."
Thankfully, some workarounds have been provided by him which include disabling TLS 1.3 for inbound sessions, modifying http.sys bindings via netsh to request certificates during the initial handshake, or removing client certificate requirements from application configurations.
For those who may not be familiar, Internet Information Services (IIS) is Microsoft’s full‑featured, extensible web server for hosting websites and applications on Windows. IIS relies on the Windows HTTP.sys kernel driver to handle TLS/SSL encryption and decryption. When an HTTPS binding is configured, IIS stores the binding in applicationHost.config and passes it to HTTP.sys, which uses the associated certificate to negotiate TLS with clients before passing decrypted HTTP requests to IIS for processing.
Meanwhile IIS Express is a lightweight, self‑contained version based on IIS 7 and later, that is optimized for development and testing. Unlike IIS though, which uses the Windows Process Activation Service to manage sites and is intended for production, IIS Express runs without requiring administrator rights for various tasks and offers simplified configuration.
You can find the official blog post here on Microsoft"s Tech Community website.