Как работает эта политика Powershell Cert?

Question

Чтобы исправить проблему с тестовым скриптом PowerShell для нашего веб-сайта, мы добавили следующий код перед вызовом Invoke-WebRequest (для this и this :

add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
    public bool CheckValidationResult(
        ServicePoint srvPoint, X509Certificate certificate,
        WebRequest request, int certificateProblem) {
            return true;
        }
 }
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

$login = Invoke-WebRequest "https://...."

А затем, чтобы добавить действительные политики TLS, которые мы недавно добавили:

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Tls12'

Мой вопрос прост: как этот код влияет на Invoke-webrequest? Насколько я вижу, он не связанк вызову прямым способом. Ничего не применимо к переменной сеанса (очевидным образом).
Я видел одну ссылку на функцию обратного вызова, но я все еще не вижу, как CheckValidationResult передается в качестве обратного вызова.И все же это работает.

Answer 1

PowerShell - это приложение .NET..NET приложения имеют AppDomain (только одно; именно поэтому вам необходимо перезапустить powershell.exe, чтобы очистить сеанс).Как часть этого, у вас есть System.Net.ServicePointManager класс для управления HTTP-соединениями (я настоятельно рекомендую прочитать эту статью для более полного понимания).

---

Причина вашего первого битакода с объектом TrustAllCertsPolicy происходит из-за ненадежной природы самозаверяющих сертификатов, что говорит мне либо

1. Ваша служба использует самоподписанный сертификат
2. Ваша служба имееткакой-то специфический для компании сертификат, который ваша рабочая станция не импортировала

Так что все, что он делает, это позволяет Invoke-WebRequest принимать любой сертификат (что опасно, если вы не знаете, к чему подключаетесь).

---

Причина вашего второго бита с SecurityProtocol заключается в том, что Win7 / W2K8 не поддерживает TLS1.2 по умолчанию.Обычно это выполняется с помощью ключей реестра SCHANNEL ( дополнительное чтение ), но по умолчанию они не существуют на этих платформах (возможно, я неправильно запомнил этот фрагмент), так чтоAppDomain по умолчанию использует SSL3.0 / TLS1.0.Я бы порекомендовал использовать -bor при установке SecurityProtocol, чтобы не нарушать обратную или прямую совместимость:

[System.Net.ServicePointManager]::SecurityProtocol =
    [System.Net.ServicePointManager]::SecurityProtocol -bor [System.Net.SecurityProtocolType]::Tls12

Answer 2

Прежде всего, давайте проясним, что этот PowerShell эффективно отключает TLS и делает все ваши https-запросы небезопасными, поскольку проверка сертификата абсолютно не выполняется (он все время возвращает true).

Как это работает так:

1. Вы создаете новый класс проверки сертификата, который вслепую говорит «да» всякий раз, когда вы спрашиваете «это безопасно?»
2. Вы назначаете политикув статическом ServicePointManager вашего сеанса.
3. Вы создаете новый веб-запрос, который внутренне ссылается на статический ServicePointManager, чтобы создать экземпляр политики сертификата и вслепую сказать «да» любой проверке сертификата.

Я не уверен, какую проблему вы пытаетесь решить с помощью этого подхода, но я бы не рекомендовал этот подход.