The request was aborted: Could not create SSL/TLS secure channel

.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.

AD FS - Trust Relationsships - Claims Provider Trusts - This claims provider trust is out of date due to trust monitoring errors

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.

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
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.

Fehlermeldung: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden. 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

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“).

ssllabs - tls1.2 yes

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).

Fiddler - SSL Version 3.1 - TLS 1.0
Fiddler – SSL Version 3.1 – TLS 1.0

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

Fiddler - Win32 (SChannel) Native Error Code 0x80090302
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).

Fiddler - HTTPS Protocols - tls1.0 to tls1.2

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.

PowerShell - Net.ServicePointManager::SecurityProtocol - Ssl3, Tls
PowerShell – [Net.ServicePointManager]::SecurityProtocol – Ssl3, Tls Es werden Protokolle SSl3 und TLS 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

PowerShell Registry - RegKey DWORD "SchUseStrongCrypto" - nicht vorhanden
RegKey DWORD „SchUseStrongCrypto“ nicht vorhanden

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

PowerShell - Registry - RegKey DWORD "SchUseStrongCrypto" - vorhanden
PowerShell – Registry – RegKey DWORD „SchUseStrongCrypto“ – vorhanden
Regedit - Registry - RegKey DWORD "SchUseStrongCrypto" - vorhanden
Regedit – RegKey DWORD „SchUseStrongCrypto“ vorhanden

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

PowerShell - Net.ServicePointManager::SecurityProtocol - Tls, Tls11, Tls12
PowerShell – [Net.ServicePointManager]::SecurityProtocol – Tls, Tls11, Tls12

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

PowerShell - Net.ServicePointManager::SecurityProtocol - Ssl3, Tls
PowerShell – [Net.ServicePointManager]::SecurityProtocol – Ssl3, Tls Es werden Protokolle SSl3 und TLS verwendet
# 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

  1. johnlouros.com: Enabling strong cryptography for all .Net applications
  2. stackoverflow.com: Default SecurityProtocol in .NET 4.5
  3. serverfault.com: On IIS, how do I patch the SSL 3.0 POODLE vulnerability (CVE­-2014­-3566)?
  4. powershell.org: Is it possible to enable TLS 1.2 as default in Powershell
  5. www.nartac.com: IIS Crypto is a free tool that gives administrators the ability to enable or disable protocols, ciphers, hashes…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.