Uwierzytelnianie nie powiodło się, ponieważ strona zdalna zamknęła strumień transportu

Rozwijam klienta TCP do połączenia serwera OpenSSL z uwierzytelnianiem za pomocą certyfikatu. Używam plików .crt i .key udostępnionych przez zespół serwera. Te certyfikaty są generowane przez polecenia OpenSSL.

Używam SslStreamobiekt do uwierzytelnienia klienta TCP poprzez wywołanie SslStream.AuthenticateAsClientmetody przekazując serwer IP, SslProtocols.Ssl3i X509CertificateCollection.

Otrzymuję następujący błąd:

Uwierzytelnianie nie powiodło się, ponieważ strona zdalna zamknęła strumień transportu

Odradzałbym ograniczanie SecurityProtocol do TLS 1.1.

Zalecanym rozwiązaniem jest użycie

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

Inną opcją jest dodanie następującego klucza rejestru:

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

Warto zauważyć, że .NET 4.6 będzie domyślnie używać poprawnego protokołu i nie wymaga żadnego rozwiązania.

Jeśli chcesz użyć starszej wersji .net, utwórz własną flagę i rzuć ją.

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

Dodanie poniższego kodu pomogło mi rozwiązać problem.

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

To zadziałało dla mnie

Napotkałem ten sam komunikat o błędzie podczas używania ChargifyNET.dll do komunikacji z interfejsem API ładowania. Dodanie chargify.ProtocolType = SecurityProtocolType.Tls12;do konfiguracji rozwiązało problem za mnie.

Oto pełny fragment kodu:

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

W przypadku VB.NET możesz umieścić następujące informacje przed żądaniem sieci Web:

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

To rozwiązało mój problem z bezpieczeństwem w .NET 3.5.

Zdarzyło mi się to, gdy punkt końcowy żądania internetowego został przełączony na inny serwer, który akceptował tylko żądania TLS1.2. Wypróbowałem tak wiele prób, które można znaleźć głównie w Stackoverflow, takich jak

1. Klucze rejestru,
2. Dodano:
   System.Net.ServicePointManager.SecurityProtocol | = System.Net.SecurityProtocolType.Tls12; do Global.ASX OnStart,
3. Dodano w Web.config.
4. Zaktualizowany .Net framework do 4.7.2 Nadal otrzymuję ten sam wyjątek.

Otrzymany wyjątek nie oddał rzeczywistego problemu, z którym miałem do czynienia, i nie znalazłem żadnej pomocy od operatora usługi.

Aby rozwiązać ten problem, muszę dodać nowy pakiet szyfrowania TLS_DHE_RSA_WITH_AES_256_GCM_SHA384. Użyłem narzędzia IIS Crypto 2.0 stąd, jak pokazano poniżej.