Autenticazione non riuscita perché il party remoto ha chiuso il flusso di trasporto

Sto sviluppando un client TCP per connettere il server OpenSSL con l'autenticazione del certificato. Ho usato i file .crt e .key condivisi dal team del server. Questi certificati sono generati dai comandi OpenSSL.Autenticazione non riuscita perché il party remoto ha chiuso il flusso di trasporto

Sto usando SslStream oggetto di autenticare il client TCP chiamando SslStream.AuthenticateAsClient metodo passando server di IP, SslProtocols.Ssl3 e X509CertificateCollection.

Sto ottenendo il seguente errore:

Authentication failed because the remote party has closed the transport stream

Aiutateci su questo tema e grazie in anticipo.

fonte

2015-06-05 Odelu

Questo sembra un problema nei giorni post POODLE: 'SslProtocols.Ssl3'. Forse dovresti provare 'SslProtocols.Tls'. In .Net 4.5 e versioni successive, puoi anche usare 'Tls11' o' Tls12'. Vedere [Enumerazione SslProtocols] (https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols%28v=vs.85%29.aspx). Potresti avere altri problemi. – jww

Vedere anche [Autenticazione socket e autenticazione non riuscita perché l'entità remota ha chiuso l'eccezione del flusso di trasporto in WPF] (http://stackoverflow.com/q/27840644). – jww

Grazie. Il mio problema si risolve collegando il certificato dal percorso fisico del certificato e della password anziché cercare il nome del soggetto del certificato dall'archivio dei certificati di Windows. – Odelu

L'aggiunta del codice seguente mi ha aiutato a risolvere il problema.

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11;

fonte

2015-09-05 18:53:51 muruge

Si sconsiglia di limitare il SecurityProtocol a TLS 1.1.

La soluzione consigliata è quella di utilizzare

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

Un'altra opzione è aggiungere la seguente chiave di registro:

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

Vale la pena notare che .NET 4.6 utilizzerà il protocollo corretto per impostazione predefinita e fa non richiede alcuna soluzione.

fonte

2016-02-10 16:43:27 GuiSim

wow, hai appena risolto il mio problema - stavo provando ogni sorta di cose - e poi sono finito qui vedendo la nota sul framework. È appena passato a 4.6.1 (stava usando 4.5), sperando che il problema fosse il framework potrebbe usare il protocollo di sicurezza sbagliato - e il bingo, le mie connessioni non vengono rifiutate, e sto ricevendo i miei dati! – Veverke

Ho eseguito lo stesso messaggio di errore durante l'utilizzo di ChargifyNET.dll per comunicare con l'API Chargify. L'aggiunta di chargify.ProtocolType = SecurityProtocolType.Tls12; alla configurazione ha risolto il problema per me.

Ecco il frammento di codice completo:

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; 
}

fonte

2016-03-11 16:34:45

Se si desidera utilizzare una versione precedente di .NET, creare la propria bandiera e lanciarlo.

// 
    // 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); 
    }

fonte

2016-04-15 15:38:55 Iguanaware

Non è necessario utilizzare la propria classe, è possibile eseguire il cast diretto degli interi su SecurityProtocolType 'ServicePointManager.SecurityProtocol = (SecurityProtocolType) 48 | (SecurityProtocolType) 192 | (SecurityProtocolType) 768 | (SecurityProtocolType) 3072; ' –

per VB.NET, è possibile inserire il seguente prima della richiesta web:

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

Questo risolto il problema di sicurezza in .NET 3.5.

fonte

2017-11-27 17:56:49 user1477388

Autenticazione non riuscita perché il party remoto ha chiuso il flusso di trasporto

risposta

Problemi correlati