2016-03-28 13 views
11

Kiedy próbuję użyć Invoke-WebRequest Dostaję trochę dziwny błąd:Invoke-WebRequest SSL nie działa?

Invoke-WebRequest -Uri "https://idp.safenames.com/" 

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send. 

Nie jestem pewien, co jest przyczyną tego, jak strony zdaje sobie dobrze.

Nawet przy wszystkich funkcjach "ignore ssl errors" wokół stackoverflow, nadal nie działa, co powoduje, że zastanawiam się, czy w ogóle jest związany z SSL.

+0

Spróbuj ustawić swojego agenta użytkownika do normalnej przeglądarki z '-UserAgent' równi metr. Może strona blokuje połączenia od "botów". – briantist

+0

@briantist Pomyślałem o tym, ale nie, nawet przy odpowiednim useragencie to się nie udaje. – iTayb

Odpowiedz

20

Jako wersja BaconBits notes, .NET wersja> 4.5 używa domyślnie SSLv3 i TLS 1.0.

Można to zmienić poprzez ustawienie polityki SecurityProtocol z klasą ServicePointManager:

PS C:\> $AllProtocols = [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12' 
PS C:\> [System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols 
PS C:\> (Invoke-WebRequest -Uri "https://idp.safenames.com/").StatusCode 
200 

ten będzie miał zastosowanie do wszystkich wniosków w AppDomain (tak to ma zastosowanie wyłącznie do bieżącej instancji aplikacji hosta)

+0

Co robię źle? Naprawdę nie mogę powiedzieć ... http://imgur.com/FgHqF1o –

+0

Powershell 4.0 lub 4 0 -1 -1 przy użyciu zapytania psversiontable.psversion –

+0

Reparacja zachowania na 2 okienkach okien diff, win8.1 i 10 –

5

Na podstawie this scan nie wygląda na to, że identyfikator URI obsługuje wszystko, co jest niższe niż TLS 1.1.

W jakiej wersji systemu Windows jesteś? Jeśli korzystasz z PowerShell w wersji 4.0 lub niższej, nie będziesz w stanie negocjować połączenia TLS 1.1 lub 1.2, ponieważ .Net Framework nie obsługuje TLS 1.1 ani 1.2 do .Net Framework 4.5. PowerShell v4.0 to .Net 4.0. Oznacza to, że podstawowe klasy System.Net.WebRequest nie mogą negocjować połączenia. Wierzę, że PowerShell v5.0 jest .Net 4.5 lub .Net 4.6, ale nie mam klienta Win 10, aby teraz sprawdzić $PSVersionTable.

Być może uda się go uruchomić poprzez ręczne kodowanie wywołań do WebRequest i określenie protokołu jako [System.Net.SecurityProtocolType]::Tls12 lub [System.Net.SecurityProtocolType]::Tls11, ale nie jestem pewien, czy to możliwe. To powinno działać, jeśli zainstalowano .Net 4.5 z tego, co widzę, ale nigdy tego nie próbowałem.

Dla porównania, otrzymuję dokładnie takie same wyniki jak w Windows 7 x64/Powershell v4.0 i mam zainstalowany .Net 4.5, ale nigdy nie próbowałem ręcznie kodować WebRequest. Otrzymuję również błąd, jeśli używam wget dla Windows 1.11.4 z here (OpenSSL 0.9.8b, na długo przed TLS 1.1 i 1.2), ale działa dobrze, jeśli używam wget dla Windows 1.17.1 z here (aktualny, więcej lub mniej).

+0

Przydatne, ale ... Pierwotne pytanie brzmiało: "Nie jestem pewien, co to powoduje" Naucz kogoś łowić ... Jak * wiemy *, że jest to problem związany z TLS? Miałem taką sytuację i nie mogłem, dla mojego życia, uzyskać niczego z wyjątku WebException, który powiedział "błąd podczas negocjacji TLS". Co gorsza, problem pojawił się tylko podczas testów automatycznych, a nie testów manualnych. W jaki sposób po stronie klienta mógłbym otrzymać komunikat, który mówi: "Klient próbował negocjować z TLS 1.0, a serwer go odrzucił". Lub NIEKTÓRE rodzaju pseudo-angielskie wyjaśnienie błędu, poza "Nieoczekiwany błąd wystąpił podczas wysyłania". – Cheeso

+0

@Cheeso Często nie dostaniesz tutaj użytecznego błędu, ponieważ serwer nie zwraca błędu klientowi. Po prostu przerywa połączenie. Wszystkie klient wie, że połączenie zostało zakończone lub odmówiono. Będziesz musiał obserwować komunikację z Wireshark, co nie jest zabawne z TLS. –

2

To może być trwale zmieniła także

# set strong cryptography on 32 bit .Net Framework (version 4 and above) 
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord 
# set strong cryptography on 64 bit .Net Framework (version 4 and above) 
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord 
Powiązane problemy