Żądanie zostało przerwane: nie można utworzyć bezpiecznego kanału SSL / TLS

Nie możemy połączyć się z serwerem HTTPS przy użyciu WebRequesttego komunikatu o błędzie:

The request was aborted: Could not create SSL/TLS secure channel.

Wiemy, że serwer nie ma ważnego certyfikatu HTTPS z użytą ścieżką, ale aby ominąć ten problem, używamy następującego kodu, który pobraliśmy z innego wpisu StackOverflow:

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

Problem polega na tym, że serwer nigdy nie sprawdza poprawności certyfikatu i kończy się niepowodzeniem z powyższym błędem. Czy ktoś ma pojęcie o tym, co powinienem zrobić?

Powinienem wspomnieć, że kolega i ja przeprowadziliśmy testy kilka tygodni temu i działało dobrze z czymś podobnym do tego, co napisałem powyżej. Jedyną „główną różnicą”, którą znaleźliśmy, jest to, że korzystam z systemu Windows 7, a on z Windows XP. Czy to coś zmienia?

W końcu znalazłem odpowiedź (nie zanotowałem swojego źródła, ale pochodziło ono z wyszukiwania);

Chociaż kod działa w systemie Windows XP, w systemie Windows 7 należy dodać go na początku:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

A teraz działa idealnie.

UZUPEŁNIENIE

Jak wspomniano Robin French; jeśli napotykasz ten problem podczas konfigurowania PayPal, pamiętaj, że nie będą one obsługiwać protokołu SSL3 od 3 grudnia 2018 r. Musisz użyć TLS. Oto strona Paypal na ten temat.

Rozwiązaniem tego jest .NET 4.5

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Jeśli nie masz .NET 4.5, użyj

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Upewnij się, że ustawienia ServicePointManager zostały wprowadzone przed utworzeniem HttpWebRequest, w przeciwnym razie nie będzie działać.

Pracuje:

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

Nie działa:

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

Problemem jest to, że użytkownik aspNet nie ma dostępu do certyfikatu. Musisz dać dostęp za pomocą programu winhttpcertcfg.exe

Przykład konfiguracji tego ustawienia znajduje się na stronie: http://support.microsoft.com/kb/901183

W kroku 2 więcej informacji

EDYCJA: W nowszych wersjach IIS ta funkcja jest wbudowana w narzędzie menedżera certyfikatów - i można uzyskać do niej dostęp, klikając prawym przyciskiem myszy certyfikat i korzystając z opcji zarządzania kluczami prywatnymi. Więcej informacji tutaj: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

Błąd jest ogólny i istnieje wiele powodów, dla których negocjacja SSL / TLS może się nie powieść. Najczęstszym z nich jest nieprawidłowy lub wygasły certyfikat serwera, a zadbałeś o to, udostępniając własny haczyk sprawdzania poprawności certyfikatu serwera, ale nie jest to jedyny powód. Serwer może wymagać wzajemnego uwierzytelnienia, może być skonfigurowany z zestawami szyfrów nieobsługiwanych przez klienta, może upłynąć zbyt duży czas, aby uzgadnianie zakończyło się sukcesem i wiele innych powodów.

Najlepszym rozwiązaniem jest użycie zestawu narzędzi do rozwiązywania problemów SChannel. SChannel jest dostawcą SSPI odpowiedzialnym za SSL i TLS, a twój klient użyje go do uzgadniania. Spójrz na Narzędzia i ustawienia TLS / SSL .

Zobacz także Jak włączyć rejestrowanie zdarzeń Schannel .

Miałem ten problem, próbując trafić na https://ct.mob0.com/Styles/Fun.png , który jest obrazem rozpowszechnianym przez CloudFlare na jego CDN, który obsługuje szalone rzeczy, takie jak SPDY i dziwne przekierowujące certyfikaty SSL.

Zamiast określenia Ssl3, jak w odpowiedzi Simonsa, udało mi się to naprawić, przechodząc do Tls12 w następujący sposób:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

Po wielu długich godzinach pracy z tym samym problemem stwierdziłem, że konto ASP.NET, pod którym działała usługa klienta, nie miało dostępu do certyfikatu. Naprawiłem to, wchodząc do puli aplikacji IIS, w której działa aplikacja internetowa, przechodząc do Ustawień zaawansowanych i zmieniając Tożsamość na LocalSystemkonto NetworkService.

Lepszym rozwiązaniem jest uzyskanie certyfikatu do pracy z NetworkServicekontem domyślnym, ale działa to na szybkie testy funkcjonalne.

Podejście z ustawieniem

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Wydaje się być w porządku, ponieważ Tls1.2 to najnowsza wersja bezpiecznego protokołu. Ale postanowiłem spojrzeć głębiej i odpowiedzieć, czy naprawdę musimy go na stałe zakodować.

Specyfikacja: Windows Server 2012R2 x64.

Z Internetu mówi się, że .NetFramework 4.6+ musi domyślnie używać Tls1.2. Ale kiedy zaktualizowałem swój projekt do 4.6, nic się nie stało. Znalazłem informacje, które mówią, że muszę ręcznie wprowadzić zmiany, aby domyślnie włączyć Tls1.2

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Ale proponowana aktualizacja systemu Windows nie działa w wersji R2

Ale pomogło mi dodanie 2 wartości do rejestru. Możesz użyć następnego skryptu PS, aby zostały dodane automatycznie

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Tego właśnie szukałem. Ale nadal nie mogę odpowiedzieć na pytanie, dlaczego NetFramework 4.6+ nie ustawia tego ... Wartość protokołu automatycznie?

Coś, czego pierwotna odpowiedź nie miała. Dodałem trochę kodu, aby był kuloodporny.

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Inną możliwością jest niewłaściwy import certyfikatu na skrzynkę. Pamiętaj, aby zaznaczyć zaznaczone pole wyboru. Początkowo tego nie zrobiłem, więc upłynął limit czasu lub wyrzucono ten sam wyjątek, ponieważ nie można znaleźć klucza prywatnego.

Wyjątek „Żądanie zostało przerwane: nie można utworzyć bezpiecznego kanału SSL / TLS” może wystąpić, jeśli serwer zwraca nieautoryzowaną odpowiedź HTTP 401 na żądanie HTTP.

Możesz ustalić, czy tak się dzieje, włączając rejestrowanie System.Net na poziomie śledzenia dla aplikacji klienckiej, jak opisano w tej odpowiedzi .

Po skonfigurowaniu rejestrowania uruchom aplikację i odtwórz błąd, a następnie spójrz na dane wyjściowe rejestrowania w taki sposób:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

W mojej sytuacji nie ustawiłem określonego pliku cookie, którego oczekiwał serwer, co spowodowało, że serwer odpowiedział na żądanie z błędem 401, co z kolei doprowadziło do wyjątku „Nie można utworzyć bezpiecznego kanału SSL / TLS”.

Inną możliwą przyczyną The request was aborted: Could not create SSL/TLS secure channelbłędu jest niedopasowanie między wartościami skonfigurowanymi dla komputera klienta a wartościami, które serwer skonfigurował jako chętny i zdolny do zaakceptowania . W takim przypadku, gdy klient wysyła listę wartości cipher_suites, które jest w stanie zaakceptować w początkowym komunikacie „Client Hello” uzgadniania / negocjacji SSL, serwer widzi, że żadna z podanych wartości nie jest akceptowana, i może zwrócić komunikat „Alert” ”zamiast przejść do kroku„ powitanie serwera ”uzgadniania SSL.

Aby zbadać tę możliwość, możesz pobrać Microsoft Message Analyzer i użyć go do uruchomienia śledzenia negocjacji SSL, które występują, gdy próbujesz nawiązać połączenie HTTPS z serwerem (w aplikacji C #).

Jeśli możesz nawiązać udane połączenie HTTPS z innego środowiska (np. Z komputera z systemem Windows XP, o którym wspomniałeś - lub być może poprzez naciśnięcie adresu URL HTTPS w przeglądarce innej niż Microsoft, która nie korzysta z ustawień pakietu szyfrów systemu operacyjnego, takich jak Chrome lub Firefox), uruchom inne śledzenie Message Analyzer w tym środowisku, aby uchwycić, co się stanie, gdy negocjacja SSL się powiedzie.

Mamy nadzieję, że zauważysz pewną różnicę między dwiema wiadomościami Hello Hello, która pozwoli ci dokładnie wskazać, co w niepowodzeniu negocjacji SSL powoduje niepowodzenie. Następnie powinieneś być w stanie dokonać zmian w konfiguracji systemu Windows, które pozwolą mu odnieść sukces. IISCrypto jest świetnym narzędziem do tego celu (nawet dla komputerów klienckich, pomimo nazwy „IIS”).

Następujące dwa klucze rejestru systemu Windows regulują wartości cipher_suites, których będzie używał komputer:

• HKLM \ SOFTWARE \ Policies \ Microsoft \ Cryptography \ Configuration \ SSL \ 00010002
• HKLM \ SYSTEM \ CurrentControlSet \ Control \ Cryptography \ Configuration \ Local \ SSL \ 00010002

Oto pełny opis tego, jak zbadałem i rozwiązałem wystąpienie tego rodzaju Could not create SSL/TLS secure channelproblemu: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

Źródłem tego wyjątku w moim przypadku było to, że w pewnym momencie kodu wywoływano:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

To jest naprawdę złe. Nie tylko instruuje .NET, aby korzystał z niezabezpieczonego protokołu, ale ma to wpływ na każde nowe żądanie WebClient (i podobne) złożone później w Twojej domenie. (Należy pamiętać, że przychodzące żądania sieciowe nie są zmieniane w aplikacji ASP.NET, ale nowe żądania WebClient, takie jak rozmowa z zewnętrzną usługą internetową, są).

W moim przypadku nie było to tak naprawdę potrzebne, więc mogłem po prostu usunąć oświadczenie, a wszystkie inne moje żądania sieciowe znów działały poprawnie. Na podstawie lektury przeprowadzonej w innym miejscu nauczyłem się kilku rzeczy:

• Jest to ustawienie globalne w Twojej domenie, a jeśli prowadzisz równoczesną aktywność, nie możesz niezawodnie ustawić jednej wartości, wykonać akcji, a następnie ustawić ją z powrotem. Podczas tego małego okna może mieć miejsce kolejna akcja, na którą może mieć wpływ.
• Prawidłowe ustawienie to ustawienie domyślne. Dzięki temu .NET może nadal korzystać z najbezpieczniejszej wartości domyślnej w miarę upływu czasu i aktualizacji ram. Ustawienie go na TLS12 (który jest najbezpieczniejszy od tego pisania) będzie działać teraz, ale za 5 lat może zacząć powodować tajemnicze problemy.
• Jeśli naprawdę potrzebujesz ustawić wartość, powinieneś rozważyć zrobienie tego w oddzielnej specjalistycznej aplikacji lub domenie i znaleźć sposób na rozmowę między nią a główną pulą. Ponieważ jest to jedna globalna wartość, próba zarządzania nią w ramach zajętej puli aplikacji doprowadzi tylko do problemów. Ta odpowiedź: https://stackoverflow.com/a/26754917/7656 zapewnia możliwe rozwiązanie za pomocą niestandardowego serwera proxy. (Uwaga: nie wdrożyłem go osobiście).

Miałem ten problem, ponieważ mój plik web.config miał:

<httpRuntime targetFramework="4.5.2" />

i nie:

<httpRuntime targetFramework="4.6.1" />

Jak widać, istnieje wiele powodów, dla których może się to zdarzyć. Pomyślałem, że dodam przyczynę, z którą się spotkałem ...

Jeśli ustawisz wartość WebRequest.Timeoutna 0, jest to zgłaszany wyjątek. Poniżej znajduje się kod, który miałem ... (Z wyjątkiem zamiast na stałe zakodowanej 0wartości limitu czasu, miałem parametr, który został przypadkowo ustawiony na 0).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

Najczęściej głosowana odpowiedź prawdopodobnie wystarczy dla większości ludzi. Jednak w niektórych okolicznościach możesz nadal wyświetlać błąd „Nie można utworzyć bezpiecznego kanału SSL / TLS”, nawet po wymuszeniu TLS 1.2. Jeśli tak, możesz przeczytać ten pomocny artykułdla dodatkowych kroków rozwiązywania problemów. Podsumowując: niezależnie od wydania wersji TLS / SSL, klient i serwer muszą uzgodnić „pakiet szyfrów”. Podczas fazy uzgadniania połączenia SSL klient wyświetli listę obsługiwanych zestawów szyfrów, aby serwer mógł sprawdzić na swojej liście. Ale na niektórych komputerach z systemem Windows niektóre typowe zestawy szyfrów mogły zostać wyłączone (najwyraźniej z powodu dobrych intencji ograniczenia powierzchni ataku), co zmniejsza prawdopodobieństwo uzgodnienia przez klienta i serwer pakietu szyfrów. Jeśli nie mogą się zgodzić, w przeglądarce zdarzeń może pojawić się „fatal alert code 40” i „Nie można utworzyć bezpiecznego kanału SSL / TLS” w programie .NET.

W powyższym artykule wyjaśniono, jak wyświetlić listę wszystkich potencjalnie obsługiwanych pakietów szyfrów komputera i włączyć dodatkowe pakiety szyfrów za pośrednictwem rejestru systemu Windows. Aby sprawdzić, które zestawy szyfrów są włączone na kliencie, spróbuj odwiedzić tę stronę diagnostyczną w MSIE. (Korzystanie ze śledzenia System.Net może dać bardziej ostateczne wyniki.) Aby sprawdzić, które zestawy szyfrów są obsługiwane przez serwer, wypróbuj to narzędzie online (zakładając, że serwer jest dostępny w Internecie). Nie trzeba dodawać, że zmiany w rejestrze muszą być wykonywane ostrożnie , szczególnie w przypadku sieci. (Czy twoja maszyna jest zdalnie hostowaną maszyną wirtualną? Jeśli miałbyś przerwać pracę w sieci, czy maszyna wirtualna byłaby w ogóle dostępna?)

W przypadku mojej firmy włączyliśmy kilka dodatkowych pakietów „ECDHE_ECDSA” poprzez edycję rejestru, aby naprawić natychmiastowy problem i uchronić się przed przyszłymi problemami. Ale jeśli nie możesz (lub nie będziesz) edytować Rejestru, przychodzą na myśl liczne obejścia (niekoniecznie ładne). Na przykład: Twój program .NET może delegować ruch SSL do osobnego programu w języku Python (który sam może działać, z tego samego powodu, dla którego żądania Chrome mogą się powieść w przypadku niepowodzenia żądań MSIE na zagrożonym komputerze).

Jedną z największych przyczyn tego problemu jest aktywna wersja .NET Framework. Wersja środowiska uruchomieniowego .NET wpływa na to, które protokoły bezpieczeństwa są domyślnie włączone.

Wydaje się, że nie ma żadnej wiarygodnej dokumentacji na temat tego, jak to konkretnie działa w różnych wersjach, ale wydaje się, że wartości domyślne są określone mniej więcej w następujący sposób:

• .NET Framework 4.5 i wcześniejsze - SSL 3.0, TLS 1.0
• .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
• .NET Framework 4.7+ - Domyślne ustawienia systemu (OS)

(W przypadku starszych wersji przebieg może się nieco różnić w zależności od tego, które środowiska uruchomieniowe .NET są zainstalowane w systemie. Na przykład może wystąpić sytuacja, w której używasz bardzo starej struktury i nie jest obsługiwany protokół TLS 1.0 lub 4.6. x i TLS 1.3 nie są obsługiwane)

Dokumentacja Microsoft zdecydowanie zaleca używanie wersji 4.7+, a ustawienia domyślne systemu:

Zalecamy:

• Kieruj na aplikacje .NET Framework 4.7 lub nowsze wersje. Kieruj na .NET Framework 4.7.1 lub nowsze wersje aplikacji WCF.
• Nie określaj wersji TLS. Skonfiguruj kod, aby system operacyjny decydował o wersji TLS.
• Przeprowadź dokładny audyt kodu, aby sprawdzić, czy nie podajesz wersji TLS lub SSL.

W przypadku witryn ASP.NET sprawdź wersję środowiska .NET w swoim <httpRuntime>elemencie, ponieważ określa to, które środowisko wykonawcze jest faktycznie używane przez witrynę:

<httpRuntime targetFramework="4.5" />

Lepszy:

<httpRuntime targetFramework="4.7" />

Ten działa dla mnie w Mcl Webclient

    public string DownloadSite(string RefinedLink)
    {
        try
        {
            Uri address = new Uri(RefinedLink);

            ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

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

            using (WebClient webClient = new WebClient())
            {
                var stream = webClient.OpenRead(address);
                using (StreamReader sr = new StreamReader(stream))
                {
                    var page = sr.ReadToEnd();

                    return page;
                }
            }

        }
        catch (Exception e)
        {
            log.Error("DownloadSite - error Lin = " + RefinedLink, e);
            return null;
        }
    }

W przypadku, gdy klient jest komputerem z systemem Windows, możliwym powodem może być to, że protokół tls lub ssl wymagany przez usługę nie jest aktywowany.

Można to ustawić w:

Panel sterowania -> Sieć i Internet -> Opcje internetowe -> Zaawansowane

Przewiń ustawienia w dół do „Bezpieczeństwo” i wybierz pomiędzy

• Użyj protokołu SSL 2.0
• Użyj SSL 3.0
• Użyj TLS 1.0
• Użyj TLS 1.1
• Użyj TLS 1.2

W moim przypadku konto usługi z uruchomioną aplikacją nie miało uprawnień dostępu do klucza prywatnego. Gdy dałem pozwolenie, błąd zniknął

1. mmc
2. certyfikaty
3. Rozwiń do osobistego
4. wybierz certyfikat
5. kliknij prawym przyciskiem myszy
6. Wszystkie zadania
7. Zarządzaj kluczami prywatnymi
8. Dodaj

Jeśli uruchamiasz swój kod z Visual Studio, spróbuj uruchomić Visual Studio jako administrator. Naprawiono problem dla mnie.

Walczyłem z tym problemem przez cały dzień.

Kiedy stworzyłem nowy projekt .NET 4.5, w końcu udało mi się go uruchomić.

Ale jeśli obniżyłem wersję do 4.0, znów miałem ten sam problem i było to nieodwracalne dla tego projektu (nawet gdy próbowałem ponownie zaktualizować do wersji 4.5).

Nie dziwny żaden inny komunikat o błędzie, ale „Żądanie zostało przerwane: nie można utworzyć bezpiecznego kanału SSL / TLS”. wymyślił ten błąd

System.Net.WebException: Żądanie zostało przerwane: Nie można utworzyć bezpiecznego kanału SSL / TLS.

W naszym przypadku korzystaliśmy z dostawcy oprogramowania, więc nie mieliśmy dostępu do modyfikowania kodu .NET. Najwyraźniej .NET 4 nie będzie używać TLS v 1.2, chyba że nastąpi zmiana.

Rozwiązaniem dla nas było dodanie klucza SchUseStrongCrypto do rejestru. Możesz skopiować / wkleić poniższy kod do pliku tekstowego z rozszerzeniem .reg i go wykonać. Służył jako nasza „łatka” do problemu.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Spróbuj tego:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

To naprawiło dla mnie, dodaj usługę sieciową do uprawnień. Kliknij prawym przyciskiem myszy certyfikat> Wszystkie zadania> Zarządzaj kluczami prywatnymi ...> Dodaj ...> Dodaj „Usługa sieciowa”.

Problem polegał na tym, że próbowałem wdrożyć na IIS jako usługę internetową, zainstalowałem certyfikat na serwerze, ale użytkownik, który uruchamia IIS, nie miał odpowiednich uprawnień do certyfikatu.

Jak przyznać ASP.NET dostęp do klucza prywatnego w certyfikacie w magazynie certyfikatów?

Miałem ten sam problem i stwierdziłem, że ta odpowiedź działała poprawnie dla mnie. Klucz to 3072. Ten link zawiera szczegółowe informacje na temat poprawki „3072”.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

W moim przypadku poprawka wymagała dwóch kanałów:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss

To pytanie może zawierać wiele odpowiedzi, ponieważ dotyczy ogólnego komunikatu o błędzie. Ten problem wystąpił na niektórych naszych serwerach, ale nie na naszych komputerach programistycznych. Po wyciągnięciu większości naszych włosów stwierdziliśmy, że był to błąd firmy Microsoft.

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

Zasadniczo MS zakłada, że ​​chcesz słabszego szyfrowania, ale system operacyjny jest załatany tak, aby zezwalał tylko na TLS 1.2, więc otrzymujesz przerażające „Żądanie zostało przerwane: Nie można utworzyć bezpiecznego kanału SSL / TLS”.

Istnieją trzy poprawki.

1) Popraw system operacyjny za pomocą odpowiedniej aktualizacji: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Dodaj ustawienie do pliku app.config / web.config.

3) Dodaj ustawienie rejestru, które zostało już wspomniane w innej odpowiedzi.

Wszystkie te są wymienione w artykule bazy wiedzy, który zamieściłem.

Inną możliwością jest to, że wykonywany kod nie ma wymaganych założeń.

W moim przypadku wystąpił ten błąd podczas używania debugera programu Visual Studio do testowania połączenia z usługą internetową. Program Visual Studio nie działał jako administrator, co spowodowało ten wyjątek.

Działo się to dla mnie tylko na jednej stronie i okazało się, że miał tylko dostępny szyfr RC4. Wcześniej próbując zahartować serwer, wyłączyłem szyfr RC4, kiedy ponownie włączyłem ten problem, problem został rozwiązany.