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
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 126.96.36.199 –Force'
Quick Fix – TL;DR
If you only want to look at the fix, it is listed below. The issues is that while Azure and Office 365 have moved to TLS 1.2 some other components 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 PowerShell session to use TLS 1.2, you will need to enter:
[Net.ServicePointManager]::SecurityProtocol = [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 packet.
Dirty Deeds Done Quick
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.
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.
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.
In the output 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.
Some folks prefer to work in Fiddler rather than raw network traces. We see the same behaviour here.
HTTP/1.1 200 Connection Established
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.
You may think that because we can brose 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.