Connection failed! The SSL connection could not be established
Der Grund liegt zumeist in der fehlenden Unterstützung moderner TLS-Versionen und/oder Verschlüsselungsalgorithmen. Und das liegt wiederum meist an einer zu alten Windows-Version.
Aber der Reihe nach:
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:
| Version | Veröffentlichung |
|---|---|
| TLS 1.0 | Januar 1999 |
| TLS 1.1 | April 2006 |
| TLS 1.2 | August 2008 |
| TLS 1.3 | August 2018 |
Die Versionen 1.0 und 1.1 gelten mittlerweile als unsicher. Unsere Cloud-Instanzen von Enbrea unterstützen daher nur TLS 1.2 und TLS 1.3.
Als erstes gilt es also zu Testen, ob auf dem eigenen Rechner zumindest TLS 1.2 unterstützt wird. Das geht via PowerShell:
Get-ItemProperty `-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" `-ErrorAction SilentlyContinue
Wenn diese Angaben in der Ausgabe auftauchen, dann ist TLS 1.2 vorhanden und aktiviert:
Enabled : 1 DisabledByDefault: 0
(Get-TlsCipherSuite).Name | Sort-Object
Hier sollte wenigstens eines der folgenden Verfahren aufgelistet werden:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519 (eq. 3072 bits RSA) FS 256
Aber Achtung 👉 Das PowerShell-Cmdlet Get-TlsCipherSuite existiert bei sehr alten Windows Server- bzw. PowerShell-Versionen noch nicht. In diesem Fall könnte man alternativ über die lokalen Gruppenrichtlinien (gpedit.msc) und dort unter
- Computerkonfiguration > Administrative Vorlagen > Netzwerk > SSL-Konfigurationseinstellungen
nachschauen.
Wem das alles Spanisch vorkommt, kann folgenden Test via PowerShell durchführen (Hinweis: Es sind zwei separate Befehle):
[Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12Invoke-WebRequest <URL zur eigenen Enbrea-Instanz> -UseBasicParsing
Ein positives Ergebnis sieht wie folgt aus:
StatusCode : 200StatusDescription : OK
Ist das Ergebnis nicht positiv, sollte die Fehlermeldung einen Hinweis darauf geben, wo das Probem liegt.
- Bei "Die zugrundeliegende Verbindung wurde geschlossen: Unbekannter Fehler beim Empfang" liegt es wahrscheinlich an der komplett fehlenden TLS 1.2-Unterstützung.
- Bei "Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden" scheint TLS 1.2 verfügbar zu sein, allerdings werden die erwarteten Verschlüsselungsverfahren (siehe oben) wohl nicht unterstützt.
Mögliche Lösungen:
- Idealerweise: Update auf eine neuere, von Microsoft aktiv unterstützte Windows-Version (siehe Microsoft Lifecycle-Richtlinie)
- Wenn Update keine Option ist, dann nach möglichen Updates und Patches suchen und schauen, wie TLS 1.2 nachträglich aktiviert werden kann. Als Beispiel siehe Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows