Ошибка аутентификации, поскольку удаленная сторона закрыла транспортный поток

Я разрабатываю TCP-клиент для подключения сервера OpenSSL с проверкой подлинности сертификата. Я использую файлы .crt и .key, общие для серверной команды. Эти сертификаты генерируются командами OpenSSL.

Я использую SslStreamобъект для аутентификации клиента Tcp, вызывая SslStream.AuthenticateAsClientметод, передавая сервер IP, SslProtocols.Ssl3и X509CertificateCollection.

Я получаю следующую ошибку:

Ошибка аутентификации, поскольку удаленная сторона закрыла транспортный поток

Я бы не советовал ограничивать SecurityProtocol до TLS 1.1.

Рекомендуемое решение - использовать

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

Другой вариант - добавить следующий ключ реестра:

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

Стоит отметить, что .NET 4.6 по умолчанию использует правильный протокол и не требует ни одного решения.

Если вы хотите использовать старую версию .net, создайте свой собственный флаг и примените его.

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

Добавление приведенного ниже кода помогло мне решить проблему.

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11;

using (var client = new HttpClient(handler))
            {
                ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
                var response = await client.SendAsync(new HttpRequestMessage(HttpMethod.Get, apiEndPoint)).ConfigureAwait(false);
                await response.Content.ReadAsStringAsync().ConfigureAwait(false);
            }

Это сработало для меня

Я столкнулся с тем же сообщением об ошибке при использовании ChargifyNET.dll для связи с Chargify API. Добавление chargify.ProtocolType = SecurityProtocolType.Tls12;в конфигурацию решило проблему для меня.

Вот полный фрагмент кода:

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

Для VB.NET вы можете разместить следующее перед своим веб-запросом:

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

Это решило мою проблему безопасности в .NET 3.5.

Это случилось со мной, когда конечная точка веб-запроса была переключена на другой сервер, который принимал только запросы TLS1.2. Пробовал так много попыток, которые в основном можно найти в Stackoverflow, например

1. Ключи реестра,
2. Добавлено:
   System.Net.ServicePointManager.SecurityProtocol | = System.Net.SecurityProtocolType.Tls12; в Global.ASX OnStart,
3. Добавлен в Web.config.
4. Обновлен .Net framework до 4.7.2. По-прежнему возникает такое же исключение.

Полученное исключение не отражало реальную проблему, с которой я столкнулся, и не нашел помощи со стороны оператора службы.

Чтобы решить эту проблему, мне нужно добавить новый Cipher Suite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384. Я использовал IIS Crypto 2.0 Tool отсюда, как показано ниже.