What should have been just another quick PowerShell script performing a WebRequest to get some data, turned into a debugging session when both the Invoke-RestMethod and Invoke-WebRequest PowerShell commands were returning; The underlying connection was closed: An unexpected error occurred on a send.
Here is the PowerShell Invoke-RestMethod response that returns: The underlying connection was closed: An unexpected error occurred on a send.
Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a send. At line:1 char:15 + ... postdata2 = Invoke-RestMethod -Uri $post.URL -Method Get -UserAgent $ ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand
Here is the PowerShell Invoke-WebRequest response that returns: The underlying connection was closed: An unexpected error occurred on a send.
Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send. At line:3 char:21 + ... $postdata = Invoke-WebRequest -Uri $post.URL -Method Get -UserAgent $ ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
Due to PowerShell defaults, it’s not unusual to have issues with TLS. The ambiguous nature of this error did however make me jump to the conclusion that I probably just needed to enforce TLS 1.2. This can be done using this PowerShell one-liner:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
However, in this situation that wasn’t the fix. Thinking it was still TLS related I checked out the SSL Certificate for the URI I was making my webrequests against. Looking at the certificate showed it was valid.
After a lot of searching I was able to work around the problem using scenarios from (here and here), however they weren’t ideal.
The resolution and solution I’m using to resolve the problem is to allow TLS, TLS 1.1 and TLS 1.2.
Insert the following line before invoking your PowerShell WebRequest using either Invoke-RestMethod or Invoke-WebRequest.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12
Hopefully this helps others experiencing this error, and allows me to quickly find it again next time I encounter this issue.
Also checkout my PowerShell Snippets Vol 1 and Vol 2 for other simple resolutions to ambiguous errors and tasks.
To resolve the PowerShell “underlying connection was closed” error, in your PowerShell script enable TLS:
Add the following line before your Invoke-RestMethod or Invoke-WebRequest call;
Today, I’m super excited to finally announce the Beta release of EntraPulse Lite – a…
I'm excited to share some significant authentication enhancements I've contributed to the Lokka MCP Server…
Last month I had the pleasure of speaking at the Sydney event for Global Azure.…
Model Context Protocol (MCP) is a powerful framework that extends AI clients like Claude and…
I've just completed participating in the Azure AI Developer Hackathon that was looking to provide…
Updated: July 2025 v1.0.2 Fixes issue setting D365SalesGlobals enabling session management for D365 Sales API…
This website uses cookies.
View Comments