TLS unter IIS 10 absichern

Wer einen Webserver betreibt, sollte darauf achten, dass keine veralteten kryptografischen Protokolle ihr Unwesen treiben. Ein Kandidat hierfür wäre Transport Layer Security (TLS) in den Versionen TLS 1.0 und TLS 1.1. Ich zeige Euch, wie beide Versionen für IIS 10 unter Windows Server 2025, 2022, 2019 und 2016 deaktiviert werden können. Außerdem werden weitere mögliche Optimierungen diskutiert.

Diskussion

Transport Layer Security (TLS) ist ein kryptografisches Protokoll zum Verschlüsseln von Nachrichten. TLS ist wesentlicher Bestandteil des Kommunikationsprotokolls Hypertext Transfer Protocol Secure (HTTPS). Die Versionshistorie von TLS sieht wie folgt aus:

Die Versionen 1.0 und 1.1 sind also schon ziemlich alt. Ein Entwurf der Internet Engineering Task Force (IETF) fordert sogar, die Unterstützung für beiden TLS-Varianten komplett zu verbieten. Die dort aufgeführten Gründe sind:

• Beide Protokollversionen erfordern den Einsatz von veralteten Verschlüsselungsverfahren, die als nicht mehr sicher gelten. TLS 1.0 setzt beispielsweise den Einsatz von TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA als zwingend voraus.

• Es werden keine aktuellen Verschlüsselungsverfahren unterstützt. Die AEAD-Verschlüsselung wird beispielsweise erst ab Version 1.2 unterstützt.

• Die Integrität des Handshake-Algorithmus basiert auf einem SHA-1 Hash. Dieser gilt als unsicher.

• Die Authentifizierung der Gegenseite basiert auf SHA-1 Signaturen. Diese gelten ebenfalls als unsicher.

• Die Unterstützung von insgesamt vier Protokollversionen erhöht die Wahrscheinlichkeit von Fehlkonfiguration.

• Einige Programmierbibliotheken haben angekündigt, die Unterstützung für TLS 1.0 und TLS 1.1 einzustellen. Dies hätte zur Folge, dass für die weiter Bereitstellung dieser Protokollversionen keine Updates dieser Bibliotheken mehr möglich wären.

Alle modernen Browser (Chrome, Firefox, Safari, Edge, Opera, etc.) unterstützen mindestens TLS 1.2.

Ein Webserver sollte daher ausschließlich TLS 1.2 oder höher bereitstellen. Leider sind sowohl unter Windows Server 2016 als auch unter Windows 2019, 2022 und 2025 beide Vorgängerversionen standardmäßig aktiviert. Unterstützung für TLS 1.3 gibt es erst seit Windows Server 2022.

TLS 1.0 und 1.1 deaktivieren

Windows 2025 und 2022

Im IIS-Manager die HTTPS-Bindung aufrufen und dort die Option Disable Legacy TLS ankreuzen.

Windows 2019 und 2016

Die Windows-Registry wie folgt ändern und danach den Server neu starten.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:00000000

Bitte beachte, dass die soeben durchgeführten Änderungen systemweit, also für alle IIS-Webseiten, gelten.

Schwache kryptographische Verfahren deaktivieren

Auch wenn Dein IIS jetzt exklusiv mit TLS 1.2 läuft und im Falle von Windows 2022 bzw. 2025 sogar mit TLS 1.3, so müssen wir uns trotzdem noch anschauen, welche kryptographische Verfahren dabei unterstützt werden.

Ein einfacher Test unter auf der Webseite SSL Labs zeigt auf, wie Dein TLS konfiguriert ist. Tippe dazu den Hostnamen Deiner Webseite ein, die Du testen möchtest.

Windows 2025 und 2022

Ein typisches Ergebnis bei einem frisch installierten Windows Server 2022 sieht wie folgt aus:

Nach Deaktivierung von TLS 1.0 sowie TLS 1.1 sieht das Ergebnis sehr gut aus:

Windows 2019

Ein typisches Ergebnis bei einem frisch installierten Windows Server 2019 sieht wie folgt aus:

Nach Deaktivierung von TLS 1.0 sowie TLS 1.1 sieht das Ergebnis etwas besser aus:

Die verbliebenden als WEAK (zu Deutsch: schwach) gekennzeichneten Einträge wollen wir ebenfalls deaktivieren.

Das Deaktivieren geht am elegantesten per PowerShell (PowerShell-Konsole bitte als Administrator starten) und dem Cmdlt Disable-TlsCipherSuite.

Das folgende Powershell-Skript deaktiviert alle als WEAK gekennzeichneten kryptografischen Verfahren:

Disable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
Disable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
Disable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
Disable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_AES_256_GCM_SHA384"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_AES_128_GCM_SHA256"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_AES_256_CBC_SHA256"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_AES_128_CBC_SHA256"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_AES_256_CBC_SHA"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_AES_128_CBC_SHA"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_3DES_EDE_CBC_SHA"

Kleiner Tipp: Mit

Get-TlsCipherSuite | Format-Table Name 

kann man sich alle unter Windows Server aktivierten kryptografischen Verfahren für TLS anzeigen lassen.

Ein abschließender Test unter SSL Labs ergibt nun folgendes Bild:

Das sieht gut aus. Bitte beachte, dass die soeben durchgeführten Änderungen systemweit, also für alle IIS-Webseiten, gelten.

Windows 2016

Windows 2016 unterscheidet sich von Windows 2019 in einem wichtigen Punkt: Der Verschlüsselungsalgorithmus Rivest Cipher 4 (RC4) ist standardmäßig aktiviert. Dieser gilt seit 2013 als unsicher und sollte seit 2015 in keiner TLS-Implementierung mehr eingesetzt werden (siehe RFC 7465). SSL Labs zeigt RC4 deshalb auch als INSECURE und nicht als WEAK an.

Du musst also auf alle Fälle RC4 unter Windows 2016 deaktivieren:

Disable-TlsCipherSuite -Name "TLS_RSA_WITH_RC4_128_SHA"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_RC4_128_MD5"

Weitere Optimierungen

HSTS

HTTP Strict Transport Security (HSTS) ist ein Sicherheitsmechanismus, mit dem eine Webseite einem Browser mitteilt, dass sie ausschließlich über HTTPS aufgerufen werden darf. Der Server sendet dazu folgenden HTTP-Header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Damit merkt sich der Browser, dass zukünftige Aufrufe automatisch auf HTTPS umgeleitet werden, auch wenn der Nutzer http:// eintippt oder auf einen unsicheren Link klickt. Ziel ist die Verhinderung von Man-in-the-Middle-Angriffen.

Die Parameter bedeuten:

HSTS wird ab Windows Server 2019 direkt im IIS-Manager als Option angeboten:

Standardmäßig ist diese Option deaktiviert. Für Windows Server 2016 kann HSTS via Custom HTTP Response Header konfiguriert werden.

OCSP-Stapling

OCSP-Stapling ist ein Mechanismus, mit dem ein Webserver die Gültigkeit seines TLS-Zertifikats nachweisen kann, ohne dass der Browser selbst beim Aussteller (Certificate Authority, CA) nachfragen muss. Normalerweise prüft der Browser per OCSP-Anfrage beim CA-Server, ob ein Zertifikat gesperrt wurde. Das verursacht zusätzliche Latenz und verrät, welche Webseite der Nutzer aufruft. Beim Stapling ruft der Server diese OCSP-Antwort regelmäßig selbst ab, heftet (Englisch: staples) sie an die TLS-Verbindung und liefert sie dem Browser direkt mit.

Soweit zur Theorie. Let’s Encrypt hat angekündigt, OCSP und damit auch OCSP-Stapling 2025 vollständig abzuschalten. Gründe sind Datenschutz (OCSP-Abfragen verraten Surfverhalten), technische Komplexität, Kosten und die Tatsache, dass aktuelle Browser Revocations (Widerrrufe) ohnehin anders handhaben. Tatsächlich sind bei Let’s Encrypt aktuell keine Abfragen via OCSP mehr möglich.

Als Alternativen gelten:

• CRL (Certificate Revocation List), also klassische Sperrlisten, die regelmäßig verteilt werden.
• Browser-eigene Mechanismen wie Googles CRLSets oder Mozillas OneCRL
• Kurzlebige Zertifikate (90 Tage bei Let’s Encrypt), welche die Notwendigkeit von Revocations weitgehend überflüssig machen.

OCSP-Stapling ist automtisch aktiviert und kann seit Windows Server 2019 in den Optionen der HTTPS-Bindung kontrolliert werden.

CAA

Certification Authority Authorization (CAA) ist ein DNS-Eintrag vom Typ “CAA”, mit dem ein Domaininhaber festlegt, welche Zertifizierungsstellen (CAs) für seine Domain TLS-Zertifikate ausstellen dürfen.

Beispiel:

beispiel.de.  CAA 0 issue "letsencrypt.org"

Dieser Eintrag hätte zur Folge, dass nur Let’s Encrypt ein Zertifikat für beispiel.de ausstellen darf. Würde jemand versuchen, bei einer anderen CA (z. B. DigiCert) ein Zertifikat zu beantragen, lehnt diese den Antrag gemäß RFC-Standard ab.

CAA ist eine Ergänzung zu Maßnahmen wie HSTS und OCSP-Stapling und soll vor ungewollter oder betrügerischer Zertifikatsausstellung schützen. Es handelt sich dabei um eine Konfigurationseinstellung bei Deinem DNS-Provider, nicht direkt bei Windows Server 2025.

DH

Diffie-Hellman (DH) ist ein kryptografisches Verfahren zum sicheren Schlüsselaustausch über unsichere Netzwerke. Dabei können zwei Parteien (z.B. ein Browser und ein Webserver) einen gemeinsamen geheimen Schlüssel berechnen, ohne dass dieser jemals direkt übertragen wird.

Das funkioniert wie folgt:

• Server und Client einigen sich zunächst auf gemeinsame öffentliche Parameter: eine große Primzahl und eine Basis (Generator).
• Danach erzeugt jede Seite einen privaten Schlüssel und berechnet daraus einen öffentlichen Schlüssel, der auf diesen gemeinsamen Parametern basiert.
• Die öffentlichen Schlüssel werden ausgetauscht, sodass beide Parteien nun den öffentlichen Schlüssel des jeweils anderen kennen.
• Mit dem eigenen privaten und dem empfangenen öffentlichen Schlüssel kann jede Seite dasselbe gemeinsame Geheimnis berechnen.

Moduli erhöhen

Der Modulus bezeichnet in TLS die Schlüssellänge des mathematischen Moduls, der beim Schlüsselaustausch verwendet wird. Die Größe des DH-Modulus bestimmt dabei maßgeblich die Kryptostärke:

• Früher wurden oft nur 1024 Bit verwendet – heute gilt das als unsicher.
• Empfohlen sind mindestens 2048 Bit, besser 3072 Bit oder mehr.

Der Standardwert für Windows Server 2016 und 2019 ist 1024 Bit, ab Windows Server 2022 sind es 2048 Bit.

Du kannst den Wert wie folgt erhöhen (00000c00 = Hexadezimal für 3072):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
"ServerMinKeyBitLength"=dword:00000c00

Danach den Server neu starten.

ECDH

Elliptic Curve Diffie-Hellman (ECDH) ist eine moderne Variante des klassischen Diffie-Hellman-Schlüsselaustauschs. Anstatt große Primzahlen und modulare Arithmetik zu verwenden (wie beim ursprünglichen DH-Verfahren), basiert ECDH auf den mathematischen Eigenschaften elliptischer Kurven über endliche Körper.

Aktuelle TLS-Implementierungen nutzen immer mehr das ECDH-Verfahren als Standard.

Ephemeral Key Reuse

Wird der private Schlüssel des Servers für jede Sitzung neu erzeugt (Englisch: ephemer), so bleiben alle bisherigen Verbindungen selbst dann sicher, wenn der langfristige Server-Schlüssel später kompromittiert wird. Dieses Prinzip nennt man Perfect Forward Secrecy (PFS).

Wird dagegen derselbe ECDH-Schlüssel über mehrere Verbindungen hinweg wiederverwendet (Englisch: reuse), spricht man von ECDH Ephemeral Key Reuse, denn PFS ist nicht mehr gegeben.

Unter Windows Server 2025 wird der ECDH-Schlüssel standardmäßig für eine gewisse Zeit wiederverwendet, um CPU-Ressourcen zu sparen. Das ist gut für die Performanz, schwächt jedoch die kryptografische Sicherheit, da mehrere TLS-Sitzungen denselben ephemeren Schlüssel verwenden könnten.

Es ist daher überlegenswert, diese Wiederverwendung zu deaktivieren. Das geht durch Ändern der Windows-Registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\ECDH]
"EphemKeyReuseTime"=dword:00000000

Danach den Server neu starten.

Elliptische Kurven

Die technische Richtlinie BSI TR-03116-4 Kryptographische Vorgaben für Projekte der Bundesregierung Teil 4 Stand 2025 des Bundesamts für Sicherheit in der Informationstechnik gibt vor, mindestens folgende elliptische Kurven zu unterstützen:

• secp256r1 (für TLS 1.2 und 1.3)
• brainpoolP256r1 (für TLS 1.2)
• brainpoolP256r1tls13 (für TLS 1.3)

Schauen wir uns mal an, was Windows Server 2025 zu bieten hat:

Get-TlsEccCurve

Das liefert uns:

curve25519
NistP256
NistP384

Die Kurve NistP256 entspricht secp256r1. Ein Blick in die Microsoft-Dokumentation liefert uns eine Liste der unterstützten elliptischen Kurven.

Um brainpoolP256r1 zu aktivieren, musst Du folgenden PowerShell-Befehl ausführen:

Enable-TlsEccCurve -Name "brainpoolP256r1" -Position 0

Der Positionsparameter ist optional und definiert die Priorität des Eintrags. Die Zahl 0 bedeutet hier “An erster Stelle”.

Nachtrag: WebDeploy

Wer noch WebDeploy zum Publizieren von Web-Applikationen unter IIS 10 nutzt, wird schnell feststellen, dass dies nach Abschalten von TLS 1.0 und TLS 1.1 nicht mehr funktioniert. Der Grund: WebDeploy nutzt standardmäßig TLS 1.0. Daher kommt es zum Verbindungsabbruch. Man kann jedoch WebDeploy (genauer gesagt das von WebDeploy genutzte .NET-Framework) auf TLS 1.2 umstellen.

Vorgehensweise: Die Windows-Registry auf dem Rechner, der WebDeploy ausführen möchte, wie folgt ändern.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001   

Anmerkungen

Es gibt noch eine Reihe weiterer TLS-Einstellungen in der Windows-Registry, die in der Microsoft Server-Dokumentation unter Transport Layer Security (TLS) registry settings beschrieben sind.

Die bereits erwähnte technische Richtlinie BSI TR-03116-4 Kryptographische Vorgaben für Projekte der Bundesregierung Teil 4 Stand 2025 des Bundesamts für Sicherheit in der Informationstechnik enthält ein ganzes Kaptitel “Vorgaben für SSL/TLS”.

Auch wenn der Funktionsumfang von IIS 10 in den letzen Jahren nicht gerade explodiert ist, so lohnt sich dennoch fast immer ein Update auf eine neuere Windows Server-Version, da viele sicherheitsrelevante Änderungen im Detail stecken. Ein Beispiel wäre die Unterstützung von TLS 1.3 ab Windows Server 2022.

Artikelhistorie

• 30.10.2019
  • Erstveröffentlichung
• 25.09.2025
  • Update für Windows Server 2022 und 2025
  • Neue Abschnitte zu HSTS, OCSP-Stapling, CAA, DH und ECDH