PowerShell Gallery TLS Support
To provide the best-in-class encryption to our customers, the PowerShell Gallery has deprecated Transport Layer Security (TLS) versions 1.0 and 1.1 as of April 2020.
The Microsoft TLS 1.0 implementation has no known security vulnerabilities. But because of the potential for future protocol downgrade attacks and other TLS vulnerabilities, we are discontinuing support for TLS 1.0 and 1.1 in the PowerShell Gallery.
For information about how to remove TLS 1.0 and 1.1 dependencies, see the whitepaper Solving the TLS 1.0 problem.
As of April 2020, TLS 1.2 is set to be the default for the PowerShell Gallery.
Please note that TLS 1.0 and 1.1 was already unsupported, but the actual deprecation when PowerShell Gallery will now stop accepting any connections using TLS 1.0 and 1.1 has occurred.
We recommend that all client-server combinations use TLS 1.2 (or a later version) to maintain connection to the PowerShell Gallery.
To mitigate this chance we have released a minor update to PowerShellGet which will allow you to continue to interact with the PowerShell Gallery. To install this run:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Install-Module PowerShellGet -RequiredVersion 2.2.4 -SkipPublisherCheck
This in this version of PowerShellGet when a call is made to the PowerShell Gallery, PowerShellGet will save the user’s current security protocol setting, then it it’ll change the security protocol to TLS 1.2 (by specifying [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12), after the action is taken by the cmdlet it will change the user’s security protocol back to what it was before the cmdlet was run.
Errors I Might See
If you are running an older version of TLS and try to interact with the PowerShell Gallery you may see error messages like:
+ ... Publish-PSArtifactUtility @PublishPSArtifactUtility_Param ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : FailedToCreateCompressedModule,Publish-PSArtifactUtility
+ ... $null = PackageManagement\Install-Package @PSBoundParameters + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (C:\Users\T-Ncho...anagement.nupkg:String) [Install-Package], Exception + FullyQualifiedErrorId : PackageFailedInstallOrDownload,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage
Concerns and Support
Please open an issue in our GitHub repository or contact our gallery support channel through firstname.lastname@example.org if you have any concerns, challenges, or are unable to upgrade to TLS 1.2 or above.
I suggest to add `Tls12` rather than change other existing and already enabled protocols via:
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Also, just opening any PowerShell Console and running the command does not do the trick because it won’t persist. This issue only affects older operating systems and/or users of Windows PowerShell
Could this be resolved with an updated PackageManagement or PowerShellGet module?
Otherwise this seems a pretty impactful change with a lot of ripples.
The fix is really simple
KeyName – ‘SchUseStrongCrypto’
Value – Dword:00000001
This be done with the following PowerShell command:
# Set strong cryptography on 64-bit .NET Framework (version 4 and above)
Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord
# Set strong cryptography on 32-bit .NET Framework (version 4 and above)
Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord