Scroll Top
Evotec Services sp. z o.o., ul. Drozdów 6, Mikołów, 43-190, Poland

PowerShellGallery disables support for TLS 1.0 breaking Install-Module


A few days ago, I tried to use Install-Module on the old Windows 2008R2 system that I use for specific tasks.

install-module adessentials -Scope CurrentUser -Force

Unfortunately, it failed with a weird message saying:

WARNING: Source Location ‘' is not valid.
PackageManagement\Install-Package : Package ‘PSEventViewer' failed to download.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\\PSModule.psm1:1772 char:21
+ … $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (C:\Users\adm_jz…entViewer.nupkg:String) [Install-Package], Exception
+ FullyQualifiedErrorId : PackageFailedInstallOrDownload,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

At first, I thought that PowerShellGallery is just blocked or broken, so I gave up retrying. However, today Justin Grote mentioned in a tweet that it's because PowerShellGallery disabled support for TLS 1.0 and is now requiring TLS 1.2. A simple change, but for older systems a breaking change. You can read about this change on the official PowerShell Team blog.

TLS 1.0 to TLS 1.2 workaround

If you check SecurityProtocol that is used by PowerShell, it reports SystemDefault.


But SystemDefault is different on every system. So while my up to date Windows 10 didn't notice any change, my work servers did. The error you saw above comes from TLS 1.2 requirement where servers I use are set to default TLS 1.0. The workaround for this issue is simple

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

But the problem with that approach is that you need to run it every time you open a new PowerShell session and want to use Install-Module, Update-Module, or any other command that interacts with PowerShellGallery. In case you want to fix this permanently you could use registry entries forcing  all .NET processes targeting .NET 4.5 to use strong crypto.

Set-ItemProperty `
    -Path "HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319" `
    -Name "SchUseStrongCrypto" `
    -Value "1" `
    -Type DWord `

Set-ItemProperty `
    -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319" `
    -Name "SchUseStrongCrypto" `
    -Value "1" `
    -Type DWord `

So if you're using any automated scripts that use Install-Module or Update-Module to configure things, you may want to update registry or add additional code to prevent any issues. For details you can read Transport Layer Security (TLS) best practices with the .NET Framework. Make sure to backup registry before making changes.

TLS 1.0 to TLS 1.2 - Final Solution

PowerShell Team (on 17th of April 2020) has released a new PowerShellGet, which solves the issue with TLS 1.2 requirement.

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
install-module powershellget -force -SkipPublisherCheck -Scope CurrentUser -AllowClobber

I've tested this on Windows 2008R2 without administrative rights, and it solves the issue.

Related Posts