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

431

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?

Simon Dugré
źródło
3
Sprawdź to także stackoverflow.com/questions/1600743/…
Oskar Kjellin
51
Jest rok 2018 i pytanie to obejrzano 308 056 razy, ale nadal nie ma odpowiedniej poprawki !! Otrzymuję ten problem losowo i żadna z poprawek wymienionych tutaj ani w żadnym innym wątku nie rozwiązała mojego problemu.
Nigel Fds
3
@NigelFds Błąd The request was aborted: Could not create SSL/TLS secure channeljest bardzo ogólny. Mówi w zasadzie: „Inicjowanie połączenia SSL / TLS / HTTPS nie powiodło się z jednego z wielu możliwych powodów”. Jeśli więc otrzymujesz go regularnie w określonej sytuacji, najlepszym rozwiązaniem jest zadanie konkretnego pytania zawierającego szczegółowe informacje na temat tej sytuacji. I sprawdzanie Podglądu zdarzeń, aby uzyskać więcej informacji. I / lub włącz niektóre debugowanie po stronie klienta .NET, aby uzyskać więcej szczegółów (czy certyfikat serwera nie jest zaufany? Czy istnieje niezgodność szyfru? Niezgodność wersji protokołu SSL / TLS itp.).
MarnixKlooster ReinstateMonica
4
@MarnixKlooster Już to wszystko sprawdziłem, to nie może być problem z certyfikatem, ponieważ gdybym go ponowił, działa. I wątpię, czy byłbym w stanie zadać to pytanie na SO, bez kogoś przychodzącego i oznaczającego go jako duplikat lub coś w tym rodzaju.
Nigel Fds
1
Walczę z tym problemem może po raz czwarty. Ta sama baza kodu, którą prowadzę, działa dobrze w środowisku produkcyjnym, a także w środowisku programistycznym niektórych moich innych programistów. Ostatnim razem polecono mi dodać wartość rejestru Computer \ HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ .NETFramework \ v4.7.02046 \ SchUseStrongCrypto [DWORD] = 1. I to działało przez chwilę. Przez pewien czas zacząłem pracować w innym projekcie, a teraz wracam do tego projektu i żądanie ponownie się nie udaje, nawet z tą poprawką klucza rejestru. Bardzo irytujące.
Miguel

Odpowiedzi:

598

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.

Simon Dugré
źródło
5
Przejście do SecurityProtocolType.Tls12 faktycznie naprawiło ten problem dla mnie. Zobacz moją odpowiedź poniżej.
Bryan Legend
24
SSLv3 ma 18 lat i jest teraz podatny na exploit POODLE - jak @LoneCoder zaleca SecurityProtocolType.Tls12 jest odpowiednim zamiennikiem SecurityProtocolType.Ssl3
gary
4
SecurityProtocolType.Tls może być lepszą alternatywą, dopóki nie zostanie znaleziony exploit (nie wszystkie strony obsługują Tls12 w momencie pisania)
Gary
3
PayPal wyznaczył datę 30 czerwca 2017 r., Aby wyłączyć SSL3 i wdrożyć TLS1.2. Jest już stosowany w środowisku piaskownicy paypal-knowledge.com/infocenter/…
Robin French
11
Zobacz to również. Nie musisz ustawiać go wyłącznie na jeden typ, możesz go po prostu dołączyć. System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;
Nae
153

Rozwiązaniem tego jest .NET 4.5

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

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

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
Andrej Z
źródło
10
Dziękuję Ci! Potrzebuję użyć .net 4.0 i nie wiedziałem, jak to rozwiązać. To wydaje się działać tutaj. :)
Fabiano
Nie działa w systemie Windows Server 2008R2 (i prawdopodobnie również w 2012 r.)
Misam,
@billpg, przeczytaj to, aby uzyskać dokładniejszą odpowiedź
Vikrant
W przypadku typów VB (ponieważ ta odpowiedź pojawia się w Google) równoważny kod toServicePointManager.SecurityProtocol = DirectCast(3072, SecurityProtocolType)
ConfusionTowers
@Andrej Z pracuje nad .NET Framework 4. Dzięki.
az fav
107

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;
hogarth45
źródło
4
Jaka jest różnica między Works a Fails, o których wspomniałeś powyżej?
Chandy Kunhu,
5
Niesamowite. Moja prośba zadziałała dopiero po drugiej próbie, co nie miało sensu, a potem zobaczyłem twój post, przesunąłem protokół bezpieczeństwa przed żądaniem i voilà, naprawione. Dzięki @ hogarth45
deanwilliammills
2
Dokładnie! kiedy umieściłem ServicePointManager tuż przed utworzeniem żądania, zadziałało to dla mnie, Dzięki stary, Uratowałeś mi dzień.
1
Idealnie ... to jest cudowne
Maryam Bagheri,
1
W naszym przypadku żądanie nie powiodło się po raz pierwszy i zadziałało później. Stało się tak właśnie z powodu podanego w tej odpowiedzi!
Mohammad Dehghan
34

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

Avitus
źródło
Próbowałem uruchomić program winhttpcertcfg.exe ... zauważ, że korzystam z systemu Windows 7. Czy to może coś zmienić?
Simon Dugré
Nie jestem pewien, czy jest to powiązane, ale ten post dał mi pomysł, aby uruchomić VS jako administrator podczas wykonywania tego połączenia z VS i to rozwiązało problem.
PFranchise
2
W systemie Windows 7 i nowszych certyfikat musi znajdować się w sklepie dla komputera lokalnego, a nie bieżącego użytkownika, aby „Zarządzać
kluczami
1
Tak, to był mój problem. użyj mmc.exe, dodaj przystawkę certyfikatów (dla mnie wybrałem „komputer lokalny”). Kliknij prawym przyciskiem myszy certyfikat, wszystkie zadania, zarządzaj kluczami prywatnymi. Dodaj „wszystkich” (dla lokalnego dewelopera jest to najłatwiejsze - prod oczywiście potrzebuje twojej wyraźnej puli aplikacji / użytkownika na stronie IIS)
Ian Yates
@ Ian Yates, to rozwiązanie działało tylko dla mnie (y)
Usman Younas
31

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 .

Remus Rusanu
źródło
Gdzie jest droga do Schannel event loggingw systemie Windows 7-8-10 ?
PreguntonCojoneroCabrón
rozwiązywać problemy programowo TLS / SSL w C #?
Kiquenet,
27

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");
Bryan Legend
źródło
Dzięki Lone ... to szalone, że wydaje się, że istnieje wiele różnych możliwości problemów w zależności od sytuacji ... I, jak widzę, nie ma prawdziwej dokumentacji tego. Cóż, dziękuję za wskazanie kogoś, kto może doświadczyć tego samego problemu.
Simon Dugré
To zadziałało dla mnie. Wystąpił błąd podczas przełączania z biurowej sieci LAN na sieć domową. Ten sam kod, ten sam laptop!
Amal
Czy błąd występuje zawsze (we wszystkich żądaniach), czy czasem ?
PreguntonCojoneroCabrón
24

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.

Nick Gotch
źródło
3
Ta odpowiedź powinna mieć więcej głosów pozytywnych. Po tygodniu badań było to jedyne rozwiązanie, które działało dla mnie. Dzięki!!
user224567893,
To zadziałało dla mnie. perfekcyjnie, dzięki.
Emy Stats
18

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?

po prostu dobrze
źródło
17

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;
SpoiledTechie.com
źródło
8
Nie poleciłbym dodanego protokołu SSL3.
Peter de Bruijn
SSL3 ma poważny problem bezpieczeństwa o nazwie „Pudel”.
Peter de Bruijn,
@PeterdeBruijn Tls and Tls11przestarzałe ?
Kiquenet,
1
@Kiquenet - tak. Od czerwca 2018 r. PCI (Payment Card Industries) nie zezwala na protokoły niższe niż TLS 1.2. (To było pierwotnie planowane na 06/2017, ale zostało przełożone na rok)
GlennG
W rodzinie SSL / TLS istnieje pięć protokołów : SSL v2, SSL v3, TLS v1.0, TLS v1.1 i TLS v1.2 : github.com/ssllabs/research/wiki/… Czy SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsoletes będzie dostępna tylko prawidłowa opcja ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12?
Kiquenet,
14

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.

okno dialogowe importu certyfikatu

Sherlock
źródło
Klient musiał ponownie instalować certyfikat, aby móc korzystać z programu klienckiego. W kółko musieliby ponownie zainstalować certyfikat przed użyciem programu. Mam nadzieję, że ta odpowiedź rozwiązuje ten problem.
Pangamma,
11

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”.

Jon Schneider
źródło
1
Mój harmonogram zadań jest wykonywany codziennie (nie w weekend). Otrzymuję ten sam błąd, ale czasami ( 2 errors in 2 months). Kiedy pojawia się błąd, później kilka minut próbuję ponownie ręcznie i wszystko jest w porządku.
Kiquenet,
10

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

Jon Schneider
źródło
1
W moim przypadku ta odpowiedź jest pomocna. Ponadto, ponieważ podejrzewałem, że mój komputer kliencki przegapił kilka pakietów szyfrów, skorzystałem ze skrótu i ​​zainstalowałem tę aktualizację Windows bezpośrednio, aby spróbować szczęścia ( support.microsoft.com/en-hk/help/3161639 , wymaga ponownego uruchomienia systemu Windows), zanim naprawdę uruchomię Przeszukiwanie wiadomości za pomocą analizatora wiadomości i okazało się, że miałem szczęście i rozwiązało to mój problem, oszczędzając sobie wyszukiwania.
sken130
1
Pamiętaj, że podczas testowania łącza HTTPS w przeglądarkach, takich jak Firefox, nawet jeśli otrzymujesz inny szyfr niż te zapewniane przez daną aktualizację Windows Update, Windows Update wciąż warto wypróbować, ponieważ instalacja nowych szyfrów wpłynie na negocjacje szyfru między komputerem klienckim a serwerem, zwiększając w ten sposób nadzieję na znalezienie dopasowania.
sken130
Do rzeczy odpowiedź na mój problem. Dwie rzeczy, które pomogły mi znaleźć zmiany do wprowadzenia. 1. Pakiety szyfrów obsługiwane przez serwer WWW: ssllabs.com/ssltest 2. Pakiety szyfrów obsługiwane przez różne wersje systemu Windows: docs.microsoft.com/en-us/windows/win32/secauthn/...
Paul B.
10

Ź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).
Tyler Forsythe
źródło
2
W przeciwieństwie do ogólnej zasady dodam, że istnieje wyjątek, kiedy MUSISZ ustawić go na TLS 1.2, zamiast pozwolić domyślnemu działaniu. Jeśli korzystasz ze środowiska starszego niż .NET 4.6 i wyłączysz niebezpieczne protokoły na swoim serwerze (SSL lub TLS 1.0 / 1.1), nie możesz wysyłać żądań, dopóki nie zmusisz programu do TLS 1.2.
Paul
10

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

<httpRuntime targetFramework="4.5.2" />

i nie:

<httpRuntime targetFramework="4.6.1" />
Terje Solem
źródło
Miałem ten sam problem i dodałem poniżej bardziej szczegółową odpowiedź , która opisuje więcej szczegółów tego problemu.
JLRishe,
9

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 ...
TCC
źródło
2
Łał! Dzięki, że o tym wspomniałeś. Po pierwsze, nie mogłem w to uwierzyć, a najpierw wypróbowałem mnóstwo różnych rzeczy. Następnie ustaw limit czasu na 10 sekund i wyjątek zniknął! To jest dla mnie rozwiązanie. (y)
derFunk
9

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).

APW
źródło
9

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" />
JLRishe
źródło
8

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;
        }
    }
Arun Prasad ES
źródło
2
Czy zastąpienie ServerCertificateValidationCallback wprowadzi nową lukę w zabezpieczeniach?
7

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

wprowadź opis zdjęcia tutaj

Cnom
źródło
jakiś problem z zaznaczeniem ich wszystkich?
Nigel Fds,
żadnych problemów, o ile wiem ... poza tym, że ssl nie są już zalecane ... nie są uważane za wystarczająco bezpieczne.
cnom
jak to zrobić programowo w PowerShell?
Kiquenet,
Jest to coś, co wpływa na starsze wersje systemu Windows. Przeprowadź badania, dowiedz się, jakie opcje zabezpieczeń są obecnie w użyciu. Na dzień dzisiejszy zobacz ten link: tecadmin.net/enable-tls-on-windows-server-and-iis
Tod
7

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
Dinesh Rajan
źródło
7

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

bplus
źródło
Niestety nie dla mnie!
benedict_w
To jedyny, który pomógł w moim przypadku! Dzięki!!!
Alexander Ostrikov
6

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

duch
źródło
5
Przyczyną tego może być fakt, że różne wersje .NET obsługują różne wersje protokołu SSL / TLS. Więcej informacji: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support
Jon Schneider
4

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
capdragon
źródło
3
Tutaj PS do szybkiej edycji: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo
2
Tutaj PS do szybkiej edycji2: New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo
4

Spróbuj tego:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Muhammad Awais
źródło
Dodałem ten wiersz. Czasami zawodzi i pojawia się ten sam błądSystem.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
Joseph Katzman
4

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”.

jayasurya_j
źródło
3

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?

Danny Cullen
źródło
Tak, to samo. Aby to naprawić, zrobiłem odpowiedź Nicka Gotcha: zmieniłem tożsamość puli aplikacji na LocalSystem. To rozwiązało dla mnie.
Judah Gabriel Himango,
1
Dzięki za to
Denis Pitcher
3

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
joeydood
źródło
3

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.

Michael Silver
źródło
Upewnij się również, że ustawiasz ServicePointManager.SecurityProtocol tylko raz w aplikacji. Odkryliśmy drugie wywołanie w naszej aplikacji (które jest dość skomplikowane z ładowaniem opcjonalnych zestawów w czasie wykonywania), które ustawiało to na SSL3, a następnie rzuciło ten sam komunikat o błędzie.
Michael Silver
3

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.

Hej, Jude
źródło
2

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.

Mark Reid
źródło
1
Nie używaj linków w odpowiedzi, ponieważ mogą one nie działać w przyszłości, wskaż najbardziej istotne aspekty w odpowiedzi
Rodrigo López