title: Ignoring Self-Signed Certificates from Powershell Invoke-RestMethod doesn't work (it's changed again...)
body: <p>After using standard solutions for ignoring certificate verification, <code>Invoke-RestMethod</code> is returning:</p>
  
  <pre><code>Invoke-RestMethod : A system error occurred and has been logged.  Please try again later or contact your administrator.
  </code></pre>
  
  <p>I just noticed this failure today, so I think it has something to do with a Powershell update.  By "standard solutions" I mean:</p>
  
  <pre><code>[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }
  </code></pre>
  
  <p>which stopped working a few months ago, and setting the callback properly in a C# type added to Powershell (description below in <strong>History</strong>). </p>
  
  <p>Here is my environment:</p>
  
  <pre><code>&gt; $PSVersionTable
  
  Name                           Value
  ----                           -----
  PSVersion                      5.1.15063.674
  PSEdition                      Desktop
  PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
  BuildVersion                   10.0.15063.674
  CLRVersion                     4.0.30319.42000
  WSManStackVersion              3.0
  PSRemotingProtocolVersion      2.3
  SerializationVersion           1.1.0.1
  </code></pre>
  
  <p>Here is a little history so this question doesn't just get closed as a duplicate.</p>
  
  <h2>History</h2>
  
  <p>If you Google around or search StackOverflow you can find this question coming up with a few canned responses.  However, today I noticed that all of the standard solutions aren't working anymore.</p>
  
  <p>The standard error Powershell gives is:</p>
  
  <pre><code>Invoke-RestMethod : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
  </code></pre>
  
  <p>The standard answer given on forums everywhere is to use this command before you call <code>Invoke-RestMethod</code>:</p>
  
  <pre><code>[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }
  </code></pre>
  
  <p>But if you're using an up to date version of Windows 10 / 2016 and Powershell, then your call to <code>Invoke-RestMethod</code> will return:</p>
  
  <pre><code>Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a send.
  </code></pre>
  
  <p>The explanation for why that happens is found <a href="http://huddledmasses.org/blog/validating-self-signed-certificates-properly-from-powershell/" rel="noreferrer">on Huddled Masses blog</a>. It can be summarized as:</p>
  
  <blockquote>
    <p>Setting the ServerCertificateValidationCallback to a scriptblock won't work for an asynchronous callback (one that happens on a task thread), because the other thread won't have a runspace to execute the script on.</p>
  </blockquote>
  
  <p>Originally, I had been solving that problem with this code:</p>
  
  <pre><code>if (-not ([System.Management.Automation.PSTypeName]"TrustAllCertsPolicy").Type)
  {
      Add-Type -TypeDefinition  @"
  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;
      }
  }
  "@
  }
  
  if ([System.Net.ServicePointManager]::CertificatePolicy.ToString() -ne "TrustAllCertsPolicy")
  {
      [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
  }
  </code></pre>
  
  <p>But, that didn't work on Windows Server 2016, even though it was working fine on Windows 10.  So, based on <a href="http://huddledmasses.org/blog/validating-self-signed-certificates-properly-from-powershell/" rel="noreferrer">Huddled Masses</a> I wrote this up to handle certificate validation callbacks in C# rather than a script block:</p>
  
  <pre><code>function Disable-SslVerification
  {
      if (-not ([System.Management.Automation.PSTypeName]"TrustEverything").Type)
      {
          Add-Type -TypeDefinition  @"
  using System.Net.Security;
  using System.Security.Cryptography.X509Certificates;
  public static class TrustEverything
  {
      private static bool ValidationCallback(object sender, X509Certificate certificate, X509Chain chain,
          SslPolicyErrors sslPolicyErrors) { return true; }
      public static void SetCallback() { System.Net.ServicePointManager.ServerCertificateValidationCallback = ValidationCallback; }
      public static void UnsetCallback() { System.Net.ServicePointManager.ServerCertificateValidationCallback = null; }
  }
  "@
      }
      [TrustEverything]::SetCallback()
  }
  function Enable-SslVerification
  {
      if (([System.Management.Automation.PSTypeName]"TrustEverything").Type)
      {
          [TrustEverything]::UnsetCallback()
      }
  }
  </code></pre>
  
  <p>That worked really well for a long time, but just recently I started getting the following error back when I call <code>Invoke-RestMethod</code>:</p>
  
  <pre><code>Invoke-RestMethod : A system error occurred and has been logged.  Please try again later or contact your administrator.
  </code></pre>
  
  <p>I understand that a proper solution is just to deploy certificates, but often you just want to test things out without having to set up a proper PKIX.</p>