[English]Seit Windows 11 24H2 und Windows Server 2025 gibt es Probleme (Error 500), wenn Clientzertifikate mit ASP.NET gegen den IIS Express getestet werden. Hintergrund sind Kompatibilitätsprobleme mit TLS 1.3, die erst mit den oben genannten Betriebssystemen auftreten. Von Microsoft wird es voraussichtlich aber keinen Fix geben.
Admin-Passwörter schützen mit Windows LAPS. eBook jetzt herunterladen » (Anzeige)
Error 500 beim IIS Express
Wird eine Web-App (ASP.NET) in IIS Express gestartet, kann dies zu einer Fehlermeldung führen. Während diese mit "can't reach the page …" in Windows 10 oder bis Windows Server 2022 noch halbwegs aussagekräftig ist, gibt es bei Windows 11 24H2 und Windows Server 2025 einen Error 500. Möglicherweise wird der Error-Code 0x80070032 (ERROR_NOT_SUPPORTED) gemeldet.
Microsoft hat das Thema im Techcommunity-Beitrag Addressing TLS 1.3 Compatibility Issues in IIS Express on Windows 11 aufgegriffen – ich bin vor Tagen über diesen neowin.net-Artikel drauf gestoßen.
Microsoft weist darauf hin, dass das obige Probleme mit dem Ende des Windows 10-Supports immer häufiger auftreten dürfte. Denn dieses Problem sei bei Windows 11 schon immer vorhanden gewesen und auch Windows Server 2025 ist davon betroffen.
Ursache sei, dass höchstwahrscheinlich die Datei applicationhost.config (für den von IIS Express) irgendwann in der Vergangenheit manuell geändert wurde und eine XML-Anweisung der folgenden Art enthält.
sslFlags="SslNegotiateCert"
Das gleiche Problem könnte auch bei SslRequireCert auftreten; beide Optionen werden in der Datei nicht gesetzt. Die Optionen (SslNegotiateCert oder SslRequireCert) weisen IIS Express an, zu Beginn der Verarbeitung einer Anfrage nach einem Client-Zertifikat zu suchen.
Leider funktioniert dies derzeit unter Windows 11 (oder Windows Server 2025) ohne einen Workaround nicht. Ursache hierfür ist die standardmäßige Verwendung von TLS 1.3 für eingehenden und ausgehenden Datenverkehr unter Windows 11. TLS 1.3 unterstützt aber ein als "Renegotiation" bekanntes TLS-Konzept nicht.
Microsoft gibt im Techcommunity-Beitrag mehrere Workarounds an, um das Problem zu beheben. Eine Maßnahme ist TLS 1.3 für eingehende/Server-Sitzungen auf der Workstation zu deaktivieren. Vorteil ist, dass dieser Workaround keinen Code oder Änderungen an der App oder am Projekt erfordert und nur den eingehenden TLS-Datenverkehr betrifft (der auf Workstations in der Regel minimal ist). Der ausgehende Datenverkehr von Ihren Browsern oder anderen Clients ist davon nicht betroffen. Der Nachteil ist, dass dies für den gesamten Rechner gilt. Auch dies sollte laut Microsoft kein Problem darstellen, da auf einer Workstation nichts speziell von eingehendem TLS 1.3 abhängig sein sollte. Keine Ahnung, wie viele Leute von diesem Szenario betroffen sind.
MVP: 2013 – 2016
Das es von Microsoft keinen Fix geben wird, ist verständlich.
Was sollte Microsoft da machen?
Ein Feature von TLS 1.2 in TLS 1.3 einbauen, das bei TLS 1.3 aus Sicherheitsgründen entfallen ist?
Damit würde man einen Teil der erhöhten Sicherheit von TLS 1.3 gegenüber 1.2 aufgeben.
Wer in der applicationhost.config herumfummelt, muß auch mit den Konsequenzen leben.
Wer nicht ohne die Anweisungen auskommt, muß eben zurück auf TLS 1.2.