Nachdem ich viele Eventlog-Fehler-Einträge mit SChannel auf meinen Webservern (Windows 2012) gefunden habe, habe ich mich mal auf die Suche nach einer Verbesserung der SSL-Konfiguration gemacht.
Der SSL-Check hat auch nicht so gute Werte geliefert:
Über den Artikel „Setup your IIS for SSL Perfect Forward Secrecy and TLS 1.2“ habe ich es dann geschafft:
- Das Tool „HTTP Strict Transport Security IIS Module“ installiert (Workaround für Installationsfehler)
- Das PowerShell-Skript aus dem oben genannten Artikel von Alexander Haß ausgeführt:
Powershell.exe -executionpolicy remotesigned -File <Dateiname> - Server neu gestartet.
Jetzt schaut der SSL-Test so aus:
Das gibt mir ein deutlich sichereres Gefühl.
Auf einem der Webserver gab es, ohne dass ich ein Schema erkennen konnte, bei einigen Nicht-SSL-Websites „Service unavailable 503“-Fehlermeldungen. Andere Nicht-SSL- und andere SSL-Websites auf demselben Server liefen perfekt.
Im Ereignisprotokoll standen Dinge wie
Fehler beim Laden der Modul-DLL C:\windows\System32\inetsrv\HstsIisModule.dll. Die Daten enthalten Fehlerinformationen.
Laut diesem Bug-Report liegt es an Websites, die im 32-Bit-Modus laufen.
Ich habe dann schweren Herzens auf dem Server wieder das Modul deinstalliert und den Server dann komplett neu gestartet.
Ggf. müsst Ihr auch noch die „hsts“-Einträge in der applicationHost.config-Datei entfernen.
Ich habe einen Workaround für das 32-Bit-Issue gefunden:
Das Attribut "preCondition=„bitness64"“ in beiden Modul-Einträgen in der Datei applicationHost.config ergänzen:
<add name="HstsIisModule" preCondition="bitness64" />in der<modules>-Sektion.<add name="HstsIisModule" image="%windir%\System32\inetsrv\HstsIisModule.dll" preCondition="bitness64"/>in der<globalModues>-Sektion.
Das schaltet dann das Modul für alle 32-Bit-AppPools aus und nur für 64-Bit-AppPools an. Logischerweise sind somit nur 64-Bit-SSL-Websites geschützt.