Closed gtatelive closed 7 years ago
Probably the issue author doesn't need this anymore, but others may stumble upon this problem (like I did). The solution to this problem is to enable TLS 1.1+ for .NET's HTTP client classes (only TLS 1.0 is enabled by default), it can be done like this:
[System.Net.ServicePointManager]::SecurityProtocol = "Tls11,Tls12"
This enables TLS 1.2 along with TLS 1.1 (Tls11 can, of course, be removed if needed.) This command needs to be executed each time the package management system accesses the Internet (well, maybe not each time, but at least Import-PackageProvider
, Install-PackageProvider
, Find-Package
, Install-Package
need it), so it's worth adding it to PowerShell's profile file %windir%\system32\WindowsPowerShell\v1.0\profile.ps1
to make it executed automatically.
I think I did find a work around. I believe I used a registry modification
64Bit Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
32Bit Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
First let me start saying I'm not 100% certian this is the correct place but I'm starting somewhere. I ran across an issue in an environment that requires us to disable SSL 3.0, TLS 1.0, TLS 1.1 along with other weaker chipers and hashes. Through painful trial and error I found 'Install-PackageProvider NuGet' would only work with TLS 1.0 enabled. Are there any plans to remedy this?
If this should be posted elsewhere please let me know.