Scoping certificate-validation bypass in a PowerShell DNS/TLS triage script that must run on 5.1 and 7

Answer

In PowerShell 5.1 there is no built‑in per‑request switch to skip certificate validation; the only supported way is the process‑global [System.Net.ServicePointManager]::ServerCertificateValidationCallback. You can emulate a request‑scoped bypass by saving the current callback, installing a temporary delegate, making the request, then restoring the original callback. This approach works only when no other .NET HTTP calls happen in the interval and is not thread‑safe.

Confirmed facts

• PowerShell 7’s Invoke‑RestMethod and Invoke‑WebRequest accept -SkipCertificateCheck, which sets an HttpClientHandler.ServerCertificateCustomValidationCallback limited to that cmdlet’s scope.
• In PowerShell 5.1 the ServerCertificateValidationCallback property is process‑global; there is no native per‑request alternative.
• Resolve‑DnsName returns objects with the same core properties (Name, Type, TTL, Section, IPAddress) on Windows, Linux and macOS when run under PowerShell 7; only optional IPv6‑specific fields may differ and do not affect basic parsing.

Steps for the triage script

1. Detect the PowerShell edition: if ($PSVersionTable.PSMajor -ge 7) { … } else { … }.
2. For PowerShell 7: use Invoke‑RestMethod -Uri $uri -SkipCertificateCheck to test connectivity while ignoring validation, then run a second request without the switch to see if validation fails.
3. For PowerShell 5.1:
   1. Store the current callback: $orig = [System.Net.ServicePointManager]::ServerCertificateValidationCallback.
   2. Define a temporary delegate that returns $true (or performs custom chain checks): $temp = { param($sender,$cert,$chain,$sslPolicyErrors) $true }.
   3. Assign it: [System.Net.ServicePointManager]::ServerCertificateValidationCallback = $temp.
   4. Run the request with Invoke‑RestMethod (or [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 if needed).
   5. Restore the original callback: [System.Net.ServicePointManager]::ServerCertificateValidationCallback = $orig.
4. After the TLS test, run Resolve‑DnsName -Name $host -Server -DnsOnly on both the configured resolver and a public resolver (e.g., 8.8.8.8) and compare the IPAddress values to separate DNS failures from TLS failures.
5. Optionally, inspect the certificate chain with [System.Net.Security.SslStream] to report expiry, build status, and hostname match without relying on a bypass.

Missing diagnostic detail

Will the script ever run multiple instances concurrently (e.g., background jobs or parallel runspaces)? If yes, the global‑callback method in 5.1 is not thread‑safe and you would need to isolate each run in its own PowerShell process or use a locking mechanism.