1. 问题缘起：当PowerShell脚本撞上自签名证书
在自动化运维、CI/CD流水线或者日常的API调用脚本里，Invoke-RestMethod和Invoke-WebRequest绝对是PowerShell用户最得力的两个“网络信使”。前者帮你轻松处理JSON或XML格式的API响应，后者则提供了更底层的HTTP请求控制能力。然而，当你兴冲冲地写好了脚本，准备从本地开发环境、测试服务器或者某个内部系统拉取数据时，却常常会迎面撞上这样一条令人沮丧的错误信息：
Invoke-RestMethod : 基础连接已经关闭: 未能为 SSL/TLS 安全通道建立信任关系。或者更直白一点：
Invoke-RestMethod : 请求被中止: 未能创建 SSL/TLS 安全通道。问题的根源，十有八九指向了那个“不受信任”的自签名证书。无论是你本机IIS搭建的测试站点，还是公司内网里那些没有购买商业CA证书的服务，它们使用的自签名证书在PowerShell的默认安全策略下，都被视为“可疑分子”。PowerShell严格遵循系统的证书信任链验证机制，对于无法被根证书机构（CA）验证的证书，它会毫不犹豫地拒绝连接，以确保通信安全。
这本身是一个极好的安全特性，但在开发和测试场景下，它就成了拦路虎。你不可能为了一个临时的测试环境去购买一个域名和SSL证书，而手动将自签名证书导入到“受信任的根证书颁发机构”存储区虽然可行，但过程繁琐，且在自动化脚本或临时容器环境中几乎无法实施。我们需要一种方法，让脚本在执行时能够“选择性失明”，暂时忽略对特定证书的验证，从而让工作流顺畅跑通。
2. 核心原理：.NET的证书验证回调机制
要理解如何让PowerShell忽略证书验证，我们必须深入到它依赖的底层——.NET Framework。Invoke-RestMethod和Invoke-WebRequest这两个cmdlet本质上是对.NET中HttpClient或HttpWebRequest类的高级封装。而控制SSL/TLS证书验证行为的核心，就在于一个名为ServicePointManager.ServerCertificateValidationCallback的静态委托。
这个委托允许开发者提供一个自定义的回调方法，来替代.NET默认的证书验证逻辑。每当发起一个HTTPS请求时，.NET在完成基础的SSL握手、拿到服务器证书后，会调用这个回调方法，并将证书、主机名等信息作为参数传入。你的回调方法返回一个布尔值：$true表示接受该证书，连接继续；$false表示拒绝，抛出安全异常。
默认情况下，这个回调是null，.NET会执行其内置的严格验证流程，包括检查证书是否由受信CA签发、是否在有效期内、主机名是否匹配等。我们解决问题的关键，就是临时将这个回调替换成一个永远返回$true的方法，从而绕过所有验证。
注意：这是一个极其危险的操作。它完全禁用了SSL/TLS的证书验证，让你的连接暴露在中间人攻击（MitM）的风险之下。任何攻击者都可以伪装成你的目标服务器与你通信。因此，这个技巧绝对、永远只能用于以下场景：
- 访问你完全可控的、隔离的本地或内部测试环境。
- 在自动化脚本中，作为临时的、明确的调试手段。
- 在确信没有网络嗅探风险的封闭网络（如物理隔离的实验室）中。严禁在生产环境、公共网络或处理敏感数据（密码、密钥、个人信息）的脚本中使用此方法。
3. 全局忽略：一次性解决所有请求的证书问题
如果你的脚本需要在一段时间内，频繁调用多个使用自签名证书的端点，或者你希望一劳永逸地解决当前PowerShell会话中的所有证书问题，可以采用全局设置的方法。这种方法通过修改ServicePointManager的静态属性，影响该PowerShell进程内发起的所有后续HTTPS请求。
3.1 最简实现：永远信任所有证书
这是最粗暴但也最直接的方法。在脚本的开头添加如下代码：
# 方法一：使用内联脚本块 [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true } # 或者，方法二：定义一个返回true的函数 function Ignore-CertificateValidation { param($sender, $cert, $chain, $errors) return $true } [System.Net.ServicePointManager]::ServerCertificateValidationCallback = Ignore-CertificateValidation执行完这行代码后，当前PowerShell会话中所有通过Invoke-RestMethod或Invoke-WebRequest（以及任何其他基于.NETHttpWebRequest/HttpClient的调用）发起的HTTPS请求，都将不再验证服务器证书。
实操心得与陷阱：
- 作用域：这个设置是进程级的。它只对设置它的那个PowerShell窗口（进程）有效。关闭这个窗口，新开的窗口又会恢复默认的严格验证。
- 并发安全：
ServicePointManager.ServerCertificateValidationCallback是一个静态属性，在多线程脚本中修改它需要小心。虽然简单脚本中不常见，但如果你在并行作业（ForEach-Object -Parallel）或运行空间（Runspace）中修改它，可能会引发不可预知的行为。最佳实践是在主线程、脚本最开始处设置一次。 - 无法“撤销”：一旦设置为
{ $true }，在这个会话中就无法简单地恢复默认验证。除非你明确地将回调设置为$null：[System.Net.ServicePointManager]::ServerCertificateValidationCallback = $null。因此，更推荐下面这种作用域受限的方法。
3.2 更安全的方式：使用可还原的临时设置
为了避免污染整个会话，我们可以利用PowerShell的try/catch/finally块或&调用操作符来创建一个临时的、可恢复的上下文。
# 保存当前的回调设置 $oldCallback = [System.Net.ServicePointManager]::ServerCertificateValidationCallback try { # 临时设置为忽略验证 [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true } # 在这里执行你的网络请求 $response = Invoke-RestMethod -Uri "https://my-test-server.local/api/data" -Method Get # ... 更多请求 } catch { Write-Error "请求失败: $_" } finally { # 无论成功与否，最终都恢复原来的验证设置 [System.Net.ServicePointManager]::ServerCertificateValidationCallback = $oldCallback }这种方法确保了即使在请求过程中发生错误，证书验证策略也会被恢复，不会影响脚本其他部分或后续的手动操作。
4. 请求级忽略：精准控制单个调用的安全性
全局修改影响范围太大，不够优雅。更精细的做法是只为特定的请求禁用证书验证。这需要我们对Invoke-RestMethod和Invoke-WebRequest的底层对象进行操作，因为这两个cmdlet本身并没有提供-SkipCertificateCheck这样的参数（注：在PowerShell Core 6.0+ 和 PowerShell 7+ 中，已经原生支持-SkipCertificateCheck开关，但Windows PowerShell 5.1 没有）。
4.1 为单个WebRequest设置回调
我们可以通过访问Invoke-WebRequest返回的原始HttpWebRequest对象，或者通过System.Net.HttpWebRequest类创建请求并为其单独设置回调。但更常用的技巧是利用一个“代理”式的全局回调，在回调内部根据请求的URL或其他特征来决定是否验证。
不过，更直接的方法是创建一个辅助函数，它封装了设置临时回调、执行请求、恢复回调的整个过程：
function Invoke-UnsafeRestMethod { [CmdletBinding()] param( [Parameter(Mandatory=$true)] [string]$Uri, [Microsoft.PowerShell.Commands.WebRequestMethod]$Method = 'Get', [object]$Body, [System.Collections.IDictionary]$Headers, [System.Management.Automation.PSCredential]$Credential ) $oldCallback = [System.Net.ServicePointManager]::ServerCertificateValidationCallback [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true } try { $params = @{ Uri = $Uri Method = $Method } if ($Body) { $params.Body = $Body } if ($Headers) { $params.Headers = $Headers } if ($Credential) { $params.Credential = $Credential } Invoke-RestMethod @params } catch { Write-Error "请求 '$Uri' 失败: $_" throw } finally { [System.Net.ServicePointManager]::ServerCertificateValidationCallback = $oldCallback } } # 使用自定义函数调用自签名证书端点 $data = Invoke-UnsafeRestMethod -Uri "https://internal-api.company.test/v1/users" -Method Get这个函数Invoke-UnsafeRestMethod只影响通过它发起的请求，函数执行完毕后，全局验证回调立即恢复，对其他代码无影响。
4.2 深入探究：.NET Core与PowerShell 7+的进化
如果你使用的是跨平台的PowerShell Core 6.0、7.0或更高版本，那么恭喜你，事情变得简单多了。这些新版本引入了原生的-SkipCertificateCheck开关。
# 仅在 PowerShell Core 6.0+ / PowerShell 7+ 中可用 $response = Invoke-RestMethod -Uri "https://self-signed.local" -SkipCertificateCheck这个开关的实现原理与上述的全局回调不同。在.NET Core/.NET 5+中，它通常是通过为单个HttpClientHandler实例设置ServerCertificateCustomValidationCallback来实现的，其作用范围仅限于该次请求或该HttpClient实例，更加安全可控。这是现代PowerShell中的首选方法。
版本兼容性排查要点： 在编写需要兼容不同环境的脚本时，务必进行版本检测。
if ($PSVersionTable.PSVersion.Major -ge 6) { # 使用 -SkipCertificateCheck $response = Invoke-RestMethod -Uri $uri -SkipCertificateCheck @otherParams } else { # 回退到Windows PowerShell的临时回调方法 # ... 调用上述的 Invoke-UnsafeRestMethod 或类似逻辑 }5. 进阶方案：实现有条件的证书信任
永远返回$true是“核弹”选项。一个更安全、更专业的做法是实现一个智能的回调，只信任你预期的特定自签名证书，而不是全部。这需要你获取到目标服务器证书的“指纹”（Thumbprint）或“公钥”。
5.1 基于证书指纹的验证
每个X.509证书都有一个唯一的SHA1哈希值，称为指纹。我们可以先在浏览器或通过其他工具（如openssl）安全地获取到测试服务器证书的指纹，然后在回调中只接受该指纹的证书。
# 假设你已知的、可信的自签名证书指纹 $trustedThumbprint = "A1B2C3D4E5F67890123456789012345678901234".ToUpper() # 指纹通常大写比较 [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { param($sender, $certificate, $chain, $sslPolicyErrors) # 如果系统验证已经通过，直接返回true if ($sslPolicyErrors -eq [System.Net.Security.SslPolicyErrors]::None) { return $true } # 检查证书指纹是否匹配我们信任的指纹 if ($certificate.GetCertHashString() -eq $trustedThumbprint) { Write-Warning "接受了已知的自签名证书: $trustedThumbprint" return $true } # 其他所有情况，拒绝连接 Write-Error "证书验证失败或指纹不匹配。指纹: $($certificate.GetCertHashString())" return $false }如何获取证书指纹？
- 通过浏览器：用浏览器访问该HTTPS网址（尽管会显示不安全），点击地址栏的锁图标 -> “证书” -> “详细信息” -> “指纹”。
- 通过PowerShell（需要一次初始信任）：你可以先用全局忽略的方法获取一次证书，然后从响应或异常中提取。
# 临时忽略所有证书，获取连接对象以查看证书 $oldCallback = [System.Net.ServicePointManager]::ServerCertificateValidationCallback [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true } try { $request = [System.Net.HttpWebRequest]::Create("https://your-server") $request.GetResponse().Close() # 触发SSL握手 $cert = $request.ServicePoint.Certificate Write-Host "证书指纹: $($cert.GetCertHashString())" } finally { [System.Net.ServicePointManager]::ServerCertificateValidationCallback = $oldCallback }
5.2 验证特定主机名或颁发者
你还可以在回调中检查证书的主题（Subject）或颁发者（Issuer），来匹配你内部CA颁发的证书。
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { param($sender, $certificate, $chain, $sslPolicyErrors) $expectedIssuer = "CN=My Internal CA, O=My Company" $expectedSubject = "CN=*.internal.company.com" # 检查颁发者是否匹配 if ($certificate.Issuer -eq $expectedIssuer) { return $true } # 或者检查主题是否匹配（支持通配符，这里简单用 -like） if ($certificate.Subject -like $expectedSubject) { return $true } # 默认返回false，拒绝连接 return $false }这种方法比完全禁用验证安全得多，因为它建立了一个基于已知标识的白名单。但请注意，字符串匹配可能不够精确，且证书主题/颁发者信息可以被伪造（尽管在内部网络风险较低）。
6. 实战踩坑与疑难排查
即使设置了忽略证书，在实际操作中你可能还会遇到一些意想不到的问题。
6.1 错误依旧：“请求被中止: 未能创建 SSL/TLS 安全通道。”
设置了回调仍然报这个错？这可能不仅仅是证书信任问题，还可能与协议版本有关。旧版本的服务器可能只支持老旧的、不安全的SSL协议，而.NET/Windows默认可能已禁用它们。
解决方案：强制允许使用不安全的协议（再次强调，仅用于测试！）。
# 在设置证书回调之前或同时，设置安全协议类型 # 允许 SSL3, TLS1.0, TLS1.1, TLS1.2。TLS1.3由系统自动处理。 [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Ssl3 -bor [System.Net.SecurityProtocolType]::Tls -bor [System.Net.SecurityProtocolType]::Tls11 -bor [System.Net.SecurityProtocolType]::Tls12 # 更激进的做法：使用系统默认值加上所有已知协议（不推荐，仅作了解） # [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.Enum]::GetValues([System.Net.SecurityProtocolType])最佳实践：尽量将服务器配置为支持TLS 1.2或更高版本，这是目前安全与兼容性的平衡点。在脚本中，可以只设置TLS 1.2：[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12
6.2 代理环境下的证书问题
如果你的网络需要通过企业代理服务器，并且代理服务器使用了自签名证书进行SSL拦截，那么你可能会遇到双重证书问题：首先需要信任代理的证书，然后才是目标服务器的证书。
在这种情况下，仅仅设置ServerCertificateValidationCallback可能不够。你需要确保代理的证书也被系统或你的回调所信任。更可靠的方法是将代理的根证书导入到当前用户的“受信任的根证书颁发机构”存储区中。这超出了脚本临时忽略的范畴，通常需要系统管理员的配合。
在脚本中，如果你知道代理证书的指纹，可以在上述的智能回调函数中，同时加入对代理证书指纹的检查。
6.3 与-UseBasicParsing参数的关系
Invoke-WebRequest在Windows PowerShell中默认会尝试解析返回的HTML，并创建一个包含图像、链接等DOM元素的复杂对象。在某些无GUI的环境（如Server Core）或特定配置下，这会失败。-UseBasicParsing参数可以禁用这个解析行为，返回一个更简单的响应对象。
重要提示：-UseBasicParsing参数与SSL证书验证完全无关。它只影响响应内容的解析方式。不要混淆两者。无论是否使用-UseBasicParsing，证书验证都会发生。
6.4 PowerShell Core 中-SkipCertificateCheck的局限性
在PowerShell 7+中，-SkipCertificateCheck非常方便，但需要注意：
- 它只对当前命令有效。
- 它不能用于
-WebSession中的持久连接。如果你使用-Session创建了一个可复用会话，需要在创建会话的Invoke-WebRequest命令中就使用-SkipCertificateCheck，后续使用该会话的命令才会继承这一设置。 - 它可能无法绕过某些非常严格的、操作系统层面的SSL策略（这种情况极少见）。
7. 企业级与生产环境替代方案
对于超越临时测试的场景，尤其是团队协作或准生产环境，上述“忽略”方法都是不合适的。以下是更规范、更安全的做法：
7.1 正确安装自签名证书这是最根本的解决方案。将你的测试服务器或内部CA的根证书，通过组策略或部署脚本，安装到所有需要访问它的客户端机器的“受信任的根证书颁发机构”存储区。这样，所有应用程序（包括PowerShell）都会天然信任该证书。虽然初始设置麻烦，但一劳永逸，且安全合规。
7.2 使用内部私有CA搭建一个内部的私有证书颁发机构（如使用Windows Server的AD CS，或开源的Easy-RSA、step-ca）。为所有内部服务器颁发由该私有CA签名的证书。客户端只需要信任这一个私有CA的根证书，即可自动信任所有它签发的服务器证书。这是中大型企业内网的标准做法。
7.3 在代码/脚本中显式加载证书对于高度可控的自动化场景，可以将服务器的公钥证书（.cer文件）作为资源嵌入脚本或放在安全位置。在发起请求前，通过代码将证书加载到X509Certificate2对象，并在自定义验证回调中与接收到的证书进行比对。这结合了“条件信任”的安全性和可移植性。
$trustedCertPath = ".\server.cer" $trustedCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($trustedCertPath) [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { param($sender, $receivedCert, $chain, $sslPolicyErrors) # 直接比较两个证书对象是否相同（比较原始数据） return $receivedCert.GetRawCertData() -eq $trustedCert.GetRawCertData() }这种方法要求你能安全地分发和保管这个.cer文件。
7.4 环境隔离最彻底的办法是将开发和测试环境与证书验证严格的环境隔离开。例如，在测试环境中直接使用HTTP（如果网络本身是隔离的），或者使用主机文件（hosts）解析到本地，并配置开发服务器使用有效的本地证书（如localhost证书，某些系统是默认信任的）。
绕过PowerShell的证书验证是一把锋利的双刃剑，它是在特定开发阶段为了打通流程而不得不使用的“临时通行证”。我的经验是，永远在脚本的最顶部用醒目的注释标明使用了此方法，并说明原因和风险。一旦测试通过，应立刻着手规划真正的证书解决方案——无论是部署内部CA还是为测试域名申请一个免费的DV证书（如Let‘s Encrypt）。让脚本在安全与功能之间取得平衡，是每个运维和开发者的责任。在PowerShell 7+成为主流后，尽量使用-SkipCertificateCheck这个显式、作用域清晰的开关，并做好版本判断，这能让你的脚本更健壮、更易读。
