Received an unexpected EOF or 0 bytes from the transport stream.

HttpClient verpackt den Fehler in „The SSL connection could not be established, see inner exception.“ Logs von .NET-Framework-Anwendungen zeigen dieselbe Situation häufig als „Authentication failed because the remote party has closed the transport stream.“

.NET SslStream / HttpClient — IOException: the peer closed the connection during the TLS handshake

Was der Fehler bedeutet

Die Gegenstelle (oder ein Gerät dazwischen) hat die TCP-Verbindung geschlossen, während SslStream mitten im TLS-Handshake war, ohne einen TLS-Alert zu senden. .NET kann als Grund nur den geschlossenen Stream melden. Meist hat der Server den Handshake stillschweigend abgelehnt, oder ein Proxy oder eine Firewall hat ihn verworfen.

Warum der Fehler auftritt

• Der Server bricht Handshakes ab, die er nicht akzeptiert

  häufig

  Keine gemeinsame Protokollversion oder Cipher, ein fehlender oder unbekannter SNI-Name oder ein Server, der etwas verlangt, das der Client nicht angeboten hat – jeweils bei einem Server, der die Verbindung schließt, statt einen Alert zu senden.

• Ein Proxy oder eine Firewall verwirft die Verbindung

  häufig

  Netzwerke mit Proxy-Pflicht, TLS-filternde Firewalls und VPN-Clients beenden blockierte Verbindungen stillschweigend.

• .NET-Framework-Anwendungen, die nur alte TLS-Versionen anbieten

  gelegentlich

  Anwendungen mit dem Zielframework .NET Framework 4.5 oder älter bieten ohne die TLS-Standardeinstellungen des Betriebssystems womöglich nur TLS 1.0 an, das moderne Server verwerfen.

So behebst du den Fehler

1. 1.

   Handshake vom selben Rechner aus testen

   Bricht die Verbindung auch bei openssl s_client ab, liegt das Problem im Netzwerk oder beim Server; gelingt der Handshake dort, vergleiche Protokollversionen und SNI mit dem .NET-Client.

   # Does a plain TLS handshake from the same host work?
   openssl s_client -connect api.example.com:443 -servername api.example.com -brief </dev/null
   openssl s_client -connect api.example.com:443 -servername api.example.com -tls1_2 -brief </dev/null

2. 2.

   Vorgeschriebenen Proxy verwenden

   Konfiguriere den Proxy am Handler (oder unter Linux über HTTPS_PROXY), wenn das Netzwerk keine direkten Verbindungen erlaubt.

   // Use the corporate proxy explicitly (HttpClient also honours HTTPS_PROXY / system settings)
   var handler = new SocketsHttpHandler { Proxy = new WebProxy("http://proxy.example.net:3128"), UseProxy = true };
   using var client = new HttpClient(handler);

3. 3.

   .NET Framework: TLS 1.2 aktivieren

   Stelle das Zielframework auf 4.7 oder neuer um, damit das Betriebssystem das Protokoll wählt, oder füge TLS 1.2 zu ServicePointManager.SecurityProtocol hinzu, bis das möglich ist.

   // .NET Framework 4.x apps compiled for old targets may still offer only TLS 1.0:
   // target 4.7+ (OS defaults) or, as a stop-gap, enable TLS 1.2 explicitly
   System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;

← Gesamte Signaturfehler-Datenbank durchsuchen