Unable To Install PowerShell Modules – Unable To Download From URI Error

When you try to install a PowerShell module or connect to the PowerShell Repository you may get the below error messages:

WARNING: Unable to download from URI 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''.
WARNING: Unable to download the list of available providers. Check your internet connection.

For make most glorious benefit engine of search:

PackageManagement\Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'.

The package provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.

Even if we try to run the individual command it still will fail to download and install the module.

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 –Force'

Quick Fix - TL;DR

If you only want to look at the fix, it is listed below.  The issue is that while Azure and Office 365 have moved to TLS 1.2 some other older components (typically) do not use TLS 1.2 by default.

This is one of those cases where PowerShell is using the wrong TLS configuration.

To change the current PowerShell session to use TLS 1.2, you will need to enter:

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

Update 29-11-2021 Interestingly, the Docs page for PowerShellGet has updated this command. This was the original announcement with the command noted above.  See the end of this post for a comment on the -BOR operator.

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

Then simply re-attempt the command and it should work.  Note that some HIDS and AV products can also intercept and break the TLS connection and cause the same message.

Check with your network/security team to see how they are sniffing your packets.

Dirty Deeds Done Quick

<Tenuous link to AC/DC>

Now that we know the above command can change PowerShell to use TLS 1.2, why did we need to do this?

After restarting PowerShell so that it reverts back to defaults, we can check what SSL/TLS options this shell has enabled by default.

[Net.ServicePointManager]::SecurityProtocol

The results are simply underwhelming. Seriously???

Compared to after  running the command to enable TLS 1.2 - now that looks much better!

View the documentation on SecurityProtocolType for additional details.  Note that the setting will depend on the version of .NET Framework you have installed and how it is configured.  You can read more on this in the main Docs page - the below is copied from there:

Starting with the .NET Framework 4.7, the default value of this property is SecurityProtocolType.SystemDefault. This allows .NET Framework networking APIs based on SslStream (such as FTP, HTTP, and SMTP) to inherit the default security protocols from the operating system or from any custom configurations performed by a system administrator. For information about which SSL/TLS protocols are enabled by default on each version of the Windows operating system, see Protocols in TLS/SSL (Schannel SSP).

Interestingly the Invoke-WebRequest cmdlet has been updated to allow the TLS version to be specified, but that was only done recently and at the time of writing TLS 1.3 is not supported.

Well, to be honest that can be said for many other entities as TLS 1.3 is not a widely adopted standard at this time.

Wireshark

Let's have a look at the connection by sniffing the packets using Wireshark.   Note that in frame 263 there is a fatal alert.  The connection is then terminated with the FIN TCP option.

The contents of frame 263 is shown below - note we only see TLSv1 and is this expanded as TLS 1.0 in the frame details.

After enabling TLS 1.2 in the PowerShell session things look better as we see TLSv1.2 and the Client and Server Hello completes and there are many data frames after the correct TLS and ciphers have been negotiated.

Fiddler

Some folks prefer to work in Fiddler rather than raw network traces.  We see the same behaviour here.

HTTP/1.1 200 Connection Established
FiddlerGateway: Direct
StartTime: 16:40:07.635
Connection: close

fiddler.network.https> HTTPS handshake to onegetcdn.azureedge.net (for #3) failed. System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception.

The function requested is not supported Win32 (SChannel) Native Error Code: 0x80090302

0x80090302 is listed as SEC_E_UNSUPPORTED_FUNCTION.

After TLS 1.2 has been enabled, the connections are made and the module can be downloaded.

Browser Configuration

You may think that because we can browse the Internet using IE 11 or Edge and negotiate TLS 1.2 all other aspects on the server will be OK.  This is not the case.

Note that this is the .NET TLS configuration.  The browser picked up the OS configuration from Schannel and enabled TLS 1.2 – this can be seen by running one of the online browser tests such www.ssllabs.com

However, PowerShell has it's own configuration and in this case it was not using SystemDefaults. The below are sample output screens from the same machine that was not able to download the module.

PowerShell BOR Operator

The -Bor operator listed previously in the post is probably not one that you often see.  It its one of the Arithmetic Operators, specifically one of the standard bitwise operators.  Bor is a Bitwise OR (inclusive) operator where the resulting bit is set to 1 when either or both input bits are 1. The resulting bit is set to 0 only when both input bits are set to 0.

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

 

Cheers,

Rhoderick