先说一个对开发者不太友好的消息：微软最近承认了Windows 11系统里一个颇为棘手的Bug——默认启用的TLS 1.3协议，把IIS Express处理客户端证书的能力给搞砸了。这个问题可不是小事，它直接影响到依赖双向TLS（mTLS）的本地测试环境，让许多开发者的调试流程受阻。
关键问题出在哪儿？根源在于TLS 1.3协议移除了老版本中支持的“重协商”机制。这个机制原本允许服务器在加密会话进行到一半时，再向客户端索要证书。现在倒好，IIS Express只能在初始TLS握手阶段完成证书验证，一旦错过这个窗口，认证流程就彻底卡壳。简单说，Windows 11 TLS 1.3的变更打破了IIS Express原有的证书请求流程。
更深层的原因在于，IIS Express是通过Windows系统的http.sys驱动来处理TLS通信的，而http.sys的控制时机偏晚，压根没法干预证书请求的时序。换句话说，系统本身就把可操作的窗口堵死了，导致IIS Express在TLS 1.3环境下无法正常完成mTLS身份验证。
具体症状也分情况：在旧版Windows 11和Server 2022上，浏览器会直接重置连接；到了24H2版本和Server 2025上，IIS则返回500.0内部错误，附带错误代码0x80070032——翻译过来就是“此操作不受支持”。两种表现，同一个病因，都是TLS 1.3协议与IIS Express不兼容导致的验证故障。
微软目前还没有给出永久修复方案，倒是工程师Matt Hamrick提了三条临时措施，虽然不算完美，但至少能应急。以下是针对Windows 11 TLS 1.3导致IIS Express证书验证问题的临时解决办法：
- 第一条：通过注册表编辑，强制禁用入站TLS 1.3，让系统回退到TLS 1.2。简单粗暴，但能直接绕过问题，适合需要快速恢复本地测试环境的开发者。
- 第二条：用netsh工具修改http.sys的绑定配置，把证书请求挪到初始握手阶段完成。这样能配合IIS Express的现有逻辑，避免因缺少重协商而失败。这条操作相对灵活。
- 第三条：如果上面两条都不好使，干脆从配置文件中移除客户端证书要求——当然这等于绕开了mTLS验证，测试场景下可能需要权宜处理，但能保证开发流程继续运行。
需要提醒的是，这些操作通常需要管理员权限，而且可能在Visual Studio更新后被重置，所以不是一劳永逸的办法。说到这，可能有些朋友对几个术语还不太熟悉，简单交代一下：TLS 1.3全称“传输层安全协议1.3”，是目前主流的加密通信协议，比旧版握手更简洁、安全性更强；IIS Express则是微软IIS服务器的轻量版，专门用于本地开发和测试环境。这两者撞在一起出问题，开发者首当其冲受影响，了解这些临时解决办法有助于尽快恢复工作。
