Authentifizierung fehlgeschlagen, weil die Gegenstelle den Transportstream geschlossen hat

Ich entwickle einen TCP-Client, um den OpenSSL-Server mit der Zertifikatauthentifizierung zu verbinden. Ich benutze .crt und .key Dateien, die vom Server-Team geteilt werden. Diese Zertifikate werden von OpenSSL-Befehlen generiert.Authentifizierung fehlgeschlagen, weil die Gegenstelle den Transportstream geschlossen hat

Ich verwende SslStream Objekt das TCP-Client zu authentifizieren durch den Aufruf SslStream.AuthenticateAsClient Verfahren nach Server IP, SslProtocols.Ssl3 und X509CertificateCollection vorbei.

Ich erhalte die folgende Fehlermeldung:

Authentication failed because the remote party has closed the transport stream

helfen Bitte zu diesem Thema und Dank im Voraus.

Quelle

2015-06-05 Odelu

Das sieht wie ein Problem in den Post-POODLE Tagen aus: 'SslProtocols.Ssl3'. Vielleicht solltest du 'SslProtocols.Tls' ausprobieren. In .Net 4.5 und höher können Sie auch 'Tls11' oder' Tls12' verwenden. Siehe [SslProtocols Enumeration] (https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols%28v=vs.85%29.aspx). Sie haben möglicherweise andere Probleme. – jww

Siehe auch [Socket und Authentifizierung fehlgeschlagen, da die Remote-Partei die Transportstream-Ausnahme in WPF geschlossen hat] (http://stackoverflow.com/q/27840644). – jww

Danke. Mein Problem wird gelöst, indem das Zertifikat vom physischen Pfad des Zertifikats und des Kennworts angehängt wird, anstatt den Zertifikatsantragstellernamen aus dem Windows-Zertifikatsspeicher zu suchen. – Odelu

Das Hinzufügen des untenstehenden Codes hat mir geholfen, das Problem zu lösen.

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11;

Quelle

2015-09-05 18:53:51 muruge

Ich würde davon abraten, das SecurityProtocol auf TLS 1.1 zu beschränken.

Die empfohlene Lösung ist

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls

Eine weitere Option verwenden, um den folgenden Registrierungsschlüssel hinzu:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 
Value: SchUseStrongCrypto

Es ist erwähnenswert, dass .NET 4.6 wird das richtige Protokoll verwenden standardmäßig und tut keine Lösung erforderlich.

Quelle

2016-02-10 16:43:27 GuiSim

wow, du hast gerade mein Problem gelöst - ich habe alle möglichen Dinge versucht - und bin dann hier gelandet, um den Hinweis auf das Framework zu sehen. Habe es einfach auf 4.6 gestellt.1 (war mit 4,5), in der Hoffnung, das Problem wäre der Rahmen könnte das falsche Sicherheitsprotokoll verwenden - und Bingo, meine Verbindungen werden nicht abgelehnt, und ich bekomme meine Daten! – Veverke

Ich lief die gleiche Fehlermeldung bei der Verwendung der ChargifyNET.dll für die Kommunikation mit der Chargify-API. Hinzufügen von chargify.ProtocolType = SecurityProtocolType.Tls12; zu der Konfiguration löste das Problem für mich.

Dies ist der komplette Code-Schnipsel:

public ChargifyConnect GetChargifyConnect() 
{ 
    var chargify = new ChargifyConnect(); 
    chargify.apiKey = ConfigurationManager.AppSettings["Chargify.apiKey"]; 
    chargify.Password = ConfigurationManager.AppSettings["Chargify.apiPassword"]; 
    chargify.URL = ConfigurationManager.AppSettings["Chargify.url"]; 

    // Without this an error will be thrown. 
    chargify.ProtocolType = SecurityProtocolType.Tls12; 

    return chargify; 
}

Quelle

2016-03-11 16:34:45

Wenn Sie eine ältere Version von .net verwenden mögen, Ihre eigene Flagge erstellen und werfen.

// 
    // Summary: 
    //  Specifies the security protocols that are supported by the Schannel security 
    //  package. 
    [Flags] 
    private enum MySecurityProtocolType 
    { 
     // 
     // Summary: 
     //  Specifies the Secure Socket Layer (SSL) 3.0 security protocol. 
     Ssl3 = 48, 
     // 
     // Summary: 
     //  Specifies the Transport Layer Security (TLS) 1.0 security protocol. 
     Tls = 192, 
     // 
     // Summary: 
     //  Specifies the Transport Layer Security (TLS) 1.1 security protocol. 
     Tls11 = 768, 
     // 
     // Summary: 
     //  Specifies the Transport Layer Security (TLS) 1.2 security protocol. 
     Tls12 = 3072 
    } 
    public Session() 
    { 
     System.Net.ServicePointManager.SecurityProtocol = (SecurityProtocolType)(MySecurityProtocolType.Tls12 | MySecurityProtocolType.Tls11 | MySecurityProtocolType.Tls); 
    }

Quelle

2016-04-15 15:38:55 Iguanaware

Sie müssen keine eigene Klasse verwenden. Sie können Ganzzahlen direkt in SecurityProtocolType 'ServicePointManager.SecurityProtocol = (SecurityProtocolType) 48 | umwandeln (SecurityProtocolType) 192 | (SecurityProtocolType) 768 | (SecurityProtocolType) 3072; ' –

Für VB.NET, können Sie die folgenden Punkte, bevor Sie Ihre Web-Anfrage stellen:

Const _Tls12 As SslProtocols = DirectCast(&HC00, SslProtocols) 
Const Tls12 As SecurityProtocolType = DirectCast(_Tls12, SecurityProtocolType) 
ServicePointManager.SecurityProtocol = Tls12

Dies löste meine Sicherheitsproblem auf .NET 3.5.

Quelle

2017-11-27 17:56:49 user1477388

Authentifizierung fehlgeschlagen, weil die Gegenstelle den Transportstream geschlossen hat

Antwort

Verwandte Themen