Korzystanie z System.Net.WebClient w PowerShell w celu uzyskania dostępu do adresu URL HTTPS z certyfikatem SAN

Question

Nietypowy problem tutaj. Skrypt używamy to:

$username = "itrpo" 
$url = "https://homepages.domain.com/cgi-bin/checkperms.cgi?user=$username" 
$homepagesUser = "REMOVED" 
$homepagesPass = "REMOVED" 
$webclient = New-Object System.Net.WebClient 
$webclient.Credentials = new-object System.Net.NetworkCredential($homepagesUser, $homepagesPass) 
$result = $webclient.DownloadString($url) 

Uruchamiając ten z mojego pulpitu (system Windows 8, PowerShell v3 użyciu .NET v4.0.30319) to działa. Podczas uruchamiania tego z serwera (Windows Server 2008 R2, PowerShell v2 przy użyciu .NET v2.0.50727), nie działa. W końcu zawiesza się i zwraca błąd: Wyjątek wywołujący "DownloadString" z argumentami "1": "Przekroczono limit czasu operacji"

Użycie programu NetMon Udało mi się ustalić, że na serwerze nie udało się wykonać żadnego TLS wymiana klucza klienta.

Certyfikat SSL dla stron głównych.domena.com jest w rzeczywistości certyfikatem SAN, a strony główne są aliasem dla rzeczywistej nazwy serwera (nazwijmy to servera.domena.com). Kiedy zmienił $ url w skrypcie użyć rzeczywistej nazwy serwera jako tak:

$url = "https://servera.domain.com/cgi-bin/checkperms.cgi?user=$username" 

... to działało, ale to nie jest idealne (jeśli usługa zostanie przeniesiony na inną maszynę skrypt przełamania).

Wygląda na to, że PowerShell v2 (.NET v2) ma problemy z certyfikatem SAN? Kolejnym dowodem na poparcie tej tezy jest to, że używamy powyższego skryptu stylu na innym serwerze ze standardowym certyfikatem SSL, który komunikuje się dobrze.

Czy może to wynikać z różnic w używanej klasie WebClient? Oto dokumentacja do niego pod .NET v2: http://msdn.microsoft.com/en-us/library/system.net.webclient%28v=vs.80%29.aspx i dokumentacja do niego pod .NET v4: http://msdn.microsoft.com/en-us/library/system.net.webclient%28v=vs.100%29.aspx

nie tyle o programowaniu naprawdę interpretacji powyższej dokumentacji prawidłowo wiedzieć (lub wiedzieć, czy ja jestem na dobrej drodze).

Idealnie chcemy, aby ten skrypt działał pod PowerShell v2 i .NET v2 bez konieczności ulepszania rzeczy lub wymuszania używania PowerShell .NET v4. Jeśli moje podejrzenie jest prawidłowe, czy istnieje parametr, który możemy określić/sposób modyfikacji skryptu, aby "rozwiązać" ten problem?

Wielkie dzięki za radę.

Answer 1

Moje przeczucie polega na tym, że jest to mniej związane z wersją PowerShell (lub ogólnie z innymi szczegółami platformy) i bardziej związane z certyfikatem i uzgadnianiem HTTPS. To może być nastąpiła poprawa w rozpoznawaniu alternatywne nazwy podlegające osadzone w certyfikacie, ale łatwym sposobem sprawdzenia byłoby dodać tę linię PowerShell w skrypcie:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true } 

To spowoduje, że wszystkie certyfikaty być akceptowane - niezależnie od tego, czy są zaufane, czy nie, wygasły itp. Jest to duży młotek i nie byłoby rozsądnie używać go w ustawieniach produkcyjnych, ale może być pomocny w diagnozowaniu tego, co dzieje się w konfiguracji.

Możesz zobaczyć więcej informacji na temat ServerCertificateValidationCallback na stronie MSDN, w tym parametry, które przekazuje do delegata. Można teoretycznie tylko dodać do białej listy certyfikat, którego używasz na tym serwerze, i zwrócić wartość true dla tego.