.NET – Strong Cryptography – Starke Verschlüsselung
In diesem Artikel zeige ich, wie man „Strong Cryptography“ bzw. starke Verschlüsselung (speziell TLS1.2) für .NET Framework bzw. für PowerShell aktiviert (s. Abschnitt „Fix“) und welche Fehlermeldungen bei uns ohne Aktivierung auftraten (z.B. „Error message: The request was aborted: Could not create SSL/TLS secure channel„)
Problem
Error message: The request was aborted: Could not create SSL/TLS secure channel
Error – AD FS Management
An error occurred during an attempt to read the federation metadata. Verify that the specified URL or host name is valid federation metadata endpoint.
Verify your proxy server setting. For more information about how to verify your proxy server setting, see the AD FS Troubleshooting Guide (http://go.microsoft.com/fwlink/?LinkId=182180).
Error message: The request was aborted: Could not create SSL/TLS secure channel.
Fehlermeldung: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden
Fehler – AD FS-Verwaltung
Beim Lesen der Verbundmetadaten ist ein Fehler aufgetreten. Stellen Sie sicher, dass es sich bei der angegebenen URL bzw. dem Hostnamen um einen gültigen Verbundmetadaten-Endpunkt handelt.
Überprüfen Sie Ihre Proxyservereinstellung. Weitere Informationen zur Überprüfung Ihrer Proxyservereinstellung finden Sie im AD FS-Problembehebungshandbuch (http://go.microsoft.com/fwlink/?LinkId=182180).
Fehlermeldung: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
This claims provider trust is out of date
This claims provider trust is out of date due to trust monitoring errors.
Please check the event log for details.
Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel
PowerShell Fehlermeldung:
Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel.
Details – Problem mit dem ADFS-Server und die Fehlermeldung „Could not create SSL/TLS secure channel“
ADFS – The request was aborted: Could not create SSL/TLS secure channel
Die ADFS-Server können die „Clams provider’s federation metadata URL“ nicht mehr fehlerfrei testen.
Es wird die Fehlermeldung angezeigt:
This claims provider trust is out of date due to trust monitoring errors.
Please check the event log for details.
Beim Klicken auf den Button „Test URL“ wird folgende Fehlermeldung angezeigt.
Error – AD FS Management
An error occurred during an attempt to read the federation metadata. Verify that the specified URL or host name is valid federation metadata endpoint.Verify your proxy server setting. For more information about how to verify your proxy server setting, see the AD FS Troubleshooting Guide (http://go.microsoft.com/fwlink/?LinkId=182180).
Error message: The request was aborted: Could not create SSL/TLS secure channel.
Bzw. auf den ADFS-Servern mit deutscher Sprache wird folgende Fehlermeldung angezeigt.
Fehler – AD FS-Verwaltung
Beim Lesen der Verbundmetadaten ist ein Fehler aufgetreten. Stellen Sie sicher, dass es sich bei der angegebenen URL bzw. dem Hostnamen um einen gültigen Verbundmetadaten-Endpunkt handelt.Überprüfen Sie Ihre Proxyservereinstellung. Weitere Informationen zur Überprüfung Ihrer Proxyservereinstellung finden Sie im AD FS-Problembehebungshandbuch (http://go.microsoft.com/fwlink/?LinkId=182180).
Fehlermeldung: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden.
Wird die Claims Provider URL im Browser aufgerufen, funktioniert der Aufruf einwandfrei (es wird eine XML-Datei geladen).
Die Eigenschaften der Seite (rechte Maustaste auf den Inhalt) zeigen, dass in unserem Fall TLS 1.2 für die Verbindung (Connection) benutzt wird.
PowerShell – Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel
Offensichtlich verwendet ADFS die PowerShell für die Prüfung der Claims-Provider-URL, denn auch folgender Aufruf der URL per PowerShell vom ADFS-Server scheitert.
(Invoke-WebRequest https://claims-provider-url.com).Headers
Die Fehlermeldung lautet:
Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel.
. . .
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
SSLLabs Überprüfung
Die Überprüfung der Claims Provider URL bei ssllabs ergibt, dass der Claims Provider bzw. die Gegenseite nur TLS1.2 Protokoll unterstützt bzw. erlaubt (Abschnitt „Configuration“).
Sicherheitstechnisch ist es super und entspricht den neusten Sicherheitsanforderungen. Die Abwärtskompatibilität ist aber bei Aktivierung von nur TLS1.2 nicht gewährleistet.
Fiddler – Win32 (SChannel) Native Error Code: 0x80090302
Mit dem Programm „Telerik Fiddler“ kann man den Traffic (nach dem Aktivieren auch https) analysieren.
In unserem Fall zeigt Fiddler, dass der PowerShell-Aufruf von der o.g. URL, hier scheinbar die Verbindung per SSL 3.1 bzw. TLS 1.0 versucht (was die Gegenstelle berechtigterweise nicht akzeptiert).
Auch wird folgende Fehlermeldung im Fiddler angezeigt.
fiddler.network.https> HTTPS handshake to <claims-provider-url.com> (for #1) failed. System.Security.Authentication.AuthenticationException Fehler bei SSPI-Aufruf, siehe interne Ausnahme. < Die angeforderte Funktion wird nicht unterstützt
Win32 (SChannel) Native Error Code: 0x80090302
Der Fehler „0x80090302“ bedeutet lt. dem Microsoft-Dokument „Schannel Error Codes for TLS and SSL Alerts“ folgendes:
Schannel error code | TLS or SSL alert |
SEC_E_UNSUPPORTED_FUNCTION 0x80090302 |
TLS1_ALERT_PROTOCOL_VERSION 70 |
Wird in den Fiddler-Optionen TLS1.2 aktiviert (tls1.0 mit tls1.2 ersetzen), dann funktioniert der PowerShell-Aufruf der URL (während Fiddler läuft).
Ereignisprotokoll
In der Windows Ereignisanzeige (Event Viewer) sind folgende Event Log Einträte vorhanden:
Event-ID: 168
Protokoll(name) | AD FS/Admin |
---|---|
Quelle | AD FS |
Aufgabenkategorie | None |
Ebene | Warning |
Ereignis-ID | 168 |
Details | . . . The request was aborted: Could not create SSL/TLS secure channel. . . . |
Event-ID: 36874
Protokoll(name) | System |
---|---|
Quelle | Schannel |
Aufgabenkategorie | None |
Ebene | Error |
Ereignis-ID | 36874 |
Details | An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed. |
Event-ID: 36887
Protokoll(name) | System |
---|---|
Quelle | Schannel |
Aufgabenkategorie | None |
Ebene | Error |
Ereignis-ID | 36887 |
Details | A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 70. |
Event-ID: 36888
Protokoll(name) | System |
---|---|
Quelle | Schannel |
Aufgabenkategorie | None |
Ebene | Error |
Ereignis-ID | 36888 |
Details | A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205. |
Fix
Lösung
.NET Framework Update auf Version<=4.6
Die .NET Framework Version 4.6 und größer sollen TLS1.2 standardmäßig unterstützen (das war bei uns zwar nicht die Lösung dafür aber die Voraussetzung).
Die installierte .NET-Version kann man z.B. mit der Software ASoft .NET Version Detector (ohne Installation) überprüfen.
Zur Zeit aktive Protokolle anzeigen
# Zur Zeit aktivierte .NET Verschlüsselungsprotokolle anzeigen
[Net.ServicePointManager]::SecurityProtocol
Falls das Ergebnis: Ssl3, Tls ist, dann wird zur Zeit immer noch kein TLS1.2 verwendet.
„StrongCrypto“ Reg-Key auf Existenz prüfen
Wahrscheinlich sind die Reg-Keys, welche unter anderem das TLS1.2 Protokoll aktivieren sollen, nicht vorhanden.
Die kann mit folgenden Zeilen per PowerShell (oder per manueller suche im Regedit) überprüft werden.
# Ist "SchUseStrongCrypto : 1" vorhanden?
Get-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319
Get-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\v4.0.30319
Strong Cryptography in der Registry aktivieren
Mit Hilfe folgender Zeilen werden die Registry-Einträge per PowerShell erzeugt und somit „Strong Cryptography“ (nach dem Neustart) aktiviert.
# set strong cryptography on 32 bit .Net Framework (version 4 and above)
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
# set strong cryptography on 64 bit .Net Framework (version 4 and above)
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Nun wurden die nötigen Registry-Einträge (DWORD „SchUseStrongCrypto“) erzeugt.
# Ist "SchUseStrongCrypto : 1" vorhanden?
Get-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319
Get-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\v4.0.30319
Rechner Neustart
Erst nachdem die Maschine neu gestartet wurde, werden die starken Verschlüsselungsprotokolle aktiviert.
Neustart kann z.B. mit folgendem Befehl erfolgen:
# Server Neustart (Sofort, ohne zu warten und ohne Benutzer zu warnen)
Shutdown –r –t 0
Test: Nun ist TLS1.2 aktiviert
Der PowerShell Aufruf zeigt, dass nun (unter Anderem auch) TLS1.2 für .NET bzw. PowerShell aktiviert ist.
# Zur Zeit aktivierte .NET Verschlüsselungsprotokolle anzeigen
[Net.ServicePointManager]::SecurityProtocol
Möglicher Workaround 1 (nicht ausprobiert)
Viele Anleitungen im Netz beschreiben, dass man die Eigenschaft von „System.Net.ServicePointManager.SecurityProtocol
“ ändern und das benötigte Protokoll somit hinzufügen kann.
Ein möglicher Nachteil dabei ist, dass die Änderung nur für die aktuelle Session bzw. Skript gilt.
Um die Änderung permanent zu machen, müsste man das Kommando in das PowerShell Profil
$PROFILE
einbinden, um dieses bei jedem PowerShell-Start laden zu lassen.
# Zur Zeit aktive Protokolle anzeigen
[Net.ServicePointManager]::SecurityProtocol
# TLS1.2 aktivieren (und zwar nur Version 1.2)
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
oder
# TLS1.1 und TLS1.1 aktivieren
[Net.ServicePointManager]::SecurityProtocol = ([Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12)
Möglicher Workaround 2 (nicht ausprobiert)
Mit dem Programm „IIS Crypto“ von Nartac Software soll es möglich sein, alle Verschlüsselungsprotokolle zu deaktivieren bzw. zu aktivieren.
Zitat:
IIS Crypto is a free tool that gives administrators the ability to enable or disable protocols, ciphers, hashes and key exchange algorithms on Windows Server 2008, 2012 and 2016. …
Dieser Lösungsweg wurde von uns nicht ausprobiert.
Links
- johnlouros.com: Enabling strong cryptography for all .Net applications
- stackoverflow.com: Default SecurityProtocol in .NET 4.5
- serverfault.com: On IIS, how do I patch the SSL 3.0 POODLE vulnerability (CVE-2014-3566)?
- powershell.org: Is it possible to enable TLS 1.2 as default in Powershell
- www.nartac.com: IIS Crypto is a free tool that gives administrators the ability to enable or disable protocols, ciphers, hashes…
Wow!
Great troubleshooting
Great article
Great Work
This was exaclty my issue and fixed it.
Thx!!
Besten Dank. Das hat mir viele graue Haare erspart!!!
Thanks
Freut mich, dass ich helfen konnte.
Vielen Dank für das Feedback!
Vielen Dank,
ein sehr guter Artikel.