Force the Invoke-RestMethod PowerShell cmdlet to use TLS 1.2

I wrote about some security changes in the FlashArray operating environment (called Purity) version 4.7 a month or so back. This was concerning the deprecation of SSL and TLS version 1.0, forcing all (management) connections to the FlashArray to use TLS 1.1 or 1.2 (read this here).

Our PowerShell SDK was enhanced so it would use the appropriate security connection type so users of that do not need to worry as long as they upgrade our SDK. But what about the few remaining functions that people might use that the PowerShell SDK doesn’t cover? As there are a few REST calls that are not built into the SDK (yet). 

For these few functions to be called from PowerShell, you need to use the handy Invoke-RestMethod cmdlet. This allows you to make direct REST calls from PowerShell to well any REST service, including the FlashArray, Unfortunately, for the most part, this is not going to work out of the box with Purity 4.7 and later. At least from Windows 7 or Windows 2012 R2 (I haven’t tested anything newer yet). You’ll see an error similar to below:

Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a send

error

The issue, as I understand it, is that PowerShell by default uses TLS 1.0 for web requests, which will not work in our case. So this needs to be changed. Thankfully, this is an easy change. Just add the following line to your scripts:

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

This will force the use of TLS 1.2 (you can also make it use 1.1 if you want for some reason).

Note though that this will only change it for that PowerShell session, so it will need to be executed for each script you run.

24 Replies to “Force the Invoke-RestMethod PowerShell cmdlet to use TLS 1.2”

  1. It must be
    [System.Net.ServicePointManager] and [System.Net.SecurityProtocolType]
    The “System” namespace is missing in your code.

    1. It seems to work without, adding system to it does not seem to make a difference. Does it not work for you?

  2. Thank you! It works for me well.
    All firewalls changed TLS version after update and I lost access. Now everything is ok.

  3. I am using a mix of the TLS protocols supported, so that it falls back to earlier versions if not available.
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls10 -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12

    1. You have a typo. To enable TLS1.0 you just need to specify TLS. So your call should be:

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

      1. Hi, your suggestion works properly for powershell version 5.1.15063 but I got an issue for powershell version 2.0.50727. Do you know if your script has to be changed based on powershell version?

        1. Hmm I do not know. Version 2 is pretty old, so it is possible it isn’t even relevant, or potentially possible to force POSH to use a newer version of TLS.

  4. Hi,

    Much appreciated

    Thanks for the help , it really took a lot of time to reach it here.

    My script is working fine when I attempted to run directly from Powershell, but it wasn’t with Task scheduler and with Command Prompt too.

    As we have TLS 1.2 enable on the server

  5. Just wanted to add, if you simply want to add TLS1.2 support without whacking everything else you can do…

    [Net.ServicePointManager]::SecurityProtocol += [Net.SecurityProtocolType]::Tls12

    instead of

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

  6. It works and doesn’t work if that makes sense?

    On my desktop, if i execute the script with the modification, it works fine.

    When i try to run the same script manually from my mgmt server, it does not work. I’ve searched and tried various things to no luck.

    PS 5.1 error:
    Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel.

    Event log:
    A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40.

    Its like finding a needle in a hay stack .. any advice appreciated.

  7. It works well for me. We got tripped up by the slack site reducing support for 1.0 and 1.1, and this added statement fixed it without making any server level changes.

    Pete

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.