Powershell: Install or Update-Module no longer works with 6.10

[iyoumans]

Updating from 6.0.4 to 6.10 breaks Install-Module and Update-Module for me as it cannot connect to PowerShell Gallery.

Steps to reproduce

Tried to run Update-Module in version 6.10.

Expected behavior

Expect it to connect to PowerShell Gallery and update the module

Actual behavior

See errors below. Reverting to version 6.0.4 fixes the issue.

# Update-Module AzureRM.Netcore
Get-PSGalleryApiAvailability : PowerShell Gallery is currently unavailable.  Please try again later.
At C:\program files\powershell\6\Modules\PowerShellGet\PSModule.psm1:12941 char:13
+             Get-PSGalleryApiAvailability -Repository (Get-SourceName  ...
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (:) [Get-PSGalleryApiAvailability], InvalidOperationException
+ FullyQualifiedErrorId : PowerShellGalleryUnavailable,Get-PSGalleryApiAvailability

WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2/'.
PackageManagement\Install-Package : No match was found for the specified search criteria and module name 'AzureRM.Netcore'. Try Get-PSRepository to see all available registered module repositories.
At C:\program files\powershell\6\Modules\PowerShellGet\PSModule.psm1:12955 char:20
+ ...           $sid = PackageManagement\Install-Package @PSBoundParameters
+                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Exception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

Environment data

$PSVersionTable

Name Value
---- -----
PSVersion 6.1.0
PSEdition Core
GitCommitId 6.1.0
OS Microsoft Windows 10.0.14393
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

[mklement0]

PowerShell Gallery is currently unavailable suggests a temporary, server-side issue, so the gallery may simply have been down while you tried.

I just tried, and didn't see the problem.

[iyoumans]

I just retried this: I installed 6.1.0, got the error. I uninstalled it, installed 6.0.4, worked fine. Then I re-installed 6.1.0 and got the problem. So it's repeatable (for me anyway).

[mklement0]

I should have read _both_ error/warning messages :)

The only obvious difference between your setup and mine is the specific Windows 10 version (mine is 10.0.17134).

A few more things to try (just guesses - I'll leave it to someone more knowledgeable in this area to take over from here):

• I found this re Unable to resolve package source 'https://www.powershellgallery.com/api/v2/': https://vanbrenk.blogspot.com/2017/09/install-module-unable-to-resolve.html

• If you open https://www.powershellgallery.com/api/v2/ in a browser, does it work? Does
  Invoke-WebRequest https://www.powershellgallery.com/api/v2/ work? Does Get-PSRepository return what you'd expect?

[edyoung]

What do you see if you run Get-PSRepository? Does Unregister-PSRepository Psgallery ; Register-PSRepository -Default make any difference?

[iyoumans]

The Get looks good. Unregister/Register didn't work either.

PS C:\Users\iyoumans> Get-PSRepository

Name                      InstallationPolicy   SourceLocation
----                      ------------------   --------------
PSGallery                 Untrusted            https://www.powershellgallery.com/api/v2

Tried to install Azure module and got this error:

PS C:\Users\iyoumans> Install-Module -Name AzureRM
WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.
PackageManagement\Install-Package : No match was found for the specified search criteria and module name 'AzureRM'. Try Get-PSRepository to see all available registered module repositories.
At C:\program files\powershell\6\Modules\PowerShellGet\PSModule.psm1:9491 char:21
+ ...          $null = PackageManagement\Install-Package @PSBoundParameters
+                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Exception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

[RichardSiddaway]

I've successfully run install-module azurerm on Windows 10 build 17134 with PowerShell v6.1. As build 14393 is 3 updates back could you consider updating your Windows machine/

[thezim]

@iyoumans You also might look at your TLS setting. Your OS might have some of them disabled by default. Not sure if the default protocol under 6.1 has changed since 6.0.x /cc @markekraus. .Net Core version did change between these versions which PowerShell Core is build against.

You can try each of these so see if all protocols are working.

Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslProtocol Tls
Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslProtocol Tls1
Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslProtocol Tls12

[iyoumans]

See my results below:

PS C:\Users\iyoumans> Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslProtocol Tls
Invoke-WebRequest : The requested name is valid, but no data of the requested type was found
At line:1 char:1
+ Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslP ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (Method: GET, Re...rShell/6.1.0
}:HttpRequestMessage) [Invoke-WebRequest], HttpRequestException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
PS C:\Users\iyoumans> Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslProtocol Tls1
Invoke-WebRequest : Cannot bind parameter 'SslProtocol'. Cannot convert value "Tls1" to type "Microsoft.PowerShell.Commands.WebSslProtocol". Error: "The identifier name Tls1 cannot be processed because it is either too similar or identical to the following enumerator names: Tls11, Tls12. Use a more specific identifier name."
At line:1 char:78
+ ... quest -Uri https://www.powershellgallery.com/api/v2 -SslProtocol Tls1
+                                                                      ~~~~
+ CategoryInfo          : InvalidArgument: (:) [Invoke-WebRequest], ParameterBindingException
+ FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

PS C:\Users\iyoumans> Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslProtocol Tls12
Invoke-WebRequest : The requested name is valid, but no data of the requested type was found
At line:1 char:1
+ Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslP ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (Method: GET, Re...rShell/6.1.0
}:HttpRequestMessage) [Invoke-WebRequest], HttpRequestException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

There must be some machine or enterprise configuration that is messing me up, because it is affecting my co-workers as well. Thanks for your help.

[mklement0]

@iyoumans:

It may be a DNS issue; possibly relevant information in this SO answer

To narrow the problem down, see if you can get a normal response by using the IP address in the URL (40.87.85.101 is what I get for ping www.powershellgallery.com):

Invoke-WebRequest -Uri https://40.87.85.101/api/v2 -SslProtocol Tls -SkipCertificateCheck

[iyoumans]

Here's with the IP. Keep in mind that on my same machine, Windows PowerShell functions just fine, so I don't see how it could be a DNS issue?

PS C:\Users\iyoumans> Invoke-WebRequest -Uri https://40.87.85.101/api/v2 -SslProtocol Tls -SkipCertificateCheck
Invoke-WebRequest : No connection could be made because the target machine actively refused it
At line:1 char:1
+ Invoke-WebRequest -Uri https://40.87.85.101/api/v2 -SslProtocol Tls - ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (Method: GET, Re...rShell/6.1.0
}:HttpRequestMessage) [Invoke-WebRequest], HttpRequestException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

[mklement0]

I'm out of my depth here, but my guess is that your / your organization's firewall configuration / DNS configuration / proxy-server configuration may be the problem - all of which are not directly related to PowerShell.

[iyoumans]

Thanks for your suggestions anyway - it's a place to start.

[megamorf]

I'm affected by this as well.

Setup

PS /home/megamorf> $PSVersionTable                                                                          

Name                           Value
----                           -----
PSVersion                      6.1.0
PSEdition                      Core
GitCommitId                    6.1.0
OS                             Linux 4.18.11-93.current #1 SMP PREEMPT Tue Oct 2 00:24:40 UTC 2018
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Installed as snap:

PS /home/megamorf> snap list powershell
Name        Version  Rev  Tracking  Publisher              Notes
powershell  6.1.0    11   stable    microsoft-powershell✓  classic

Troubleshooting

The Gallery is not available and cannot be registered:

PS /home/megamorf> Get-PSRepository
WARNING: Unable to find module repositories.
PS /home/megamorf> Register-PSRepository -Default -Verbose
VERBOSE: Performing the operation "Register Module Repository." on target "Module Repository 'PSGallery' () in provider 'PowerShellGet'.".
PS /home/megamorf> Get-PSRepository
WARNING: Unable to find module repositories.

I tried the PowerShellGet version that ships with PS as well as the latest stable release from Github:

PS /home/megamorf> Get-Module PowerShellGet -ListAvailable


    Directory: /home/megamorf/.local/share/powershell/Modules


ModuleType Version    Name                                PSEdition ExportedCommands
---------- -------    ----                                --------- ----------------
Script     2.0.1      PowerShellGet                       Desk      {Find-Command, Find-DSCResource, Find-Module, Find-RoleCapability...}


    Directory: /snap/powershell/11/opt/powershell/Modules


ModuleType Version    Name                                PSEdition ExportedCommands
---------- -------    ----                                --------- ----------------
Script     1.6.7      PowerShellGet                       Desk      {Find-Command, Find-DSCResource, Find-Module, Find-RoleCapability...}

Apparently something is wrong with the certificate store/trust. Querying the v2 endpoint of the Gallery by IP works:

PS /home/megamorf> Invoke-WebRequest -Uri https://40.87.85.101/api/v2 -SslProtocol Tls12 -SkipCertificateCheck

StatusCode        : 200                                                                                                                                                  StatusDescription : OK                                                                                                                                                   
Content           : <?xml version="1.0" encoding="utf-8"?><service xml:base="https://40.87.85.101/api/v2" xmlns="http://www.w3.org/2007/app" 
                    xmlns:atom="http://www.w3.org/2005/Atom"><workspace><atom:title type="text">Def...
RawContent        : HTTP/1.1 200 OK
                    Cache-Control: no-cache
                    Pragma: no-cache
                    Server: Microsoft-IIS/10.0
                    X-CorrelationId: 80007c2b-0007-e000-b63f-84710c7967bb
                    DataServiceVersion: 3.0
                    Content-Security-Policy: frame-ancesto...
Headers           : {[Cache-Control, System.String[]], [Pragma, System.String[]], [Server, System.String[]], [X-CorrelationId, System.String[]]...}
Images            : {}
InputFields       : {}
Links             : {}
RawContentLength  : 325
RelationLink      : {}

But with TLS1.2 it does not work:

PS /home/megamorf> Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslProtocol Tls12
Invoke-WebRequest : The remote certificate is invalid according to the validation procedure.
At line:1 char:1
+ Invoke-WebRequest -Uri https://www.powershellgallery.com/api/v2 -SslP ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (Method: GET, Re...rShell/6.1.0
}:HttpRequestMessage) [Invoke-WebRequest], HttpRequestException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

I assume the ca-certificates provided by the snap environment are not up to date/missing certificates to complete the ca chain of trust.

[SteveL-MSFT]

These are PowerShellGet issues. You may find support in the https://github.com/powershell/powershellget repo where that team hangs out.

[edyoung]

Happy to try and help, wherever the issue goes ;-)

I do think this seems more like an environmental issue than something specifically in PowerShellGet. The cert issue above seems similar to https://github.com/PowerShell/PowerShell-Docker/issues/46 but may not be the same problem @iyoumans is hitting earlier in the thread. @megamorf, you could try running curl as suggested in that issue - if that complains about the cert, it seems likely to be the same issue. We did update the cert on the gallery around the time of our update in September, which might be related. The current cert is valid as far as I'm aware and uses the Baltimore root cert.

[MartinSGill]

I'm seeing the same behaviour from update-module after I upgraded to 6.1. What's strange is that install-module and uninstall-module actually work.

I can therefore update my modules the long-way around.

[nxsharma]

$webclient=New-Object System.Net.WebClient
$webclient.Proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

run this and then try to reinstall. Most likely it's being blocked by your some internal security mechanism

[mashwanimq]

$webclient=New-Object System.Net.WebClient
$webclient.Proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

run this and then try to reinstall

This has no effect, I am experiencing the same issue on 6.0.4 and 6.1.0 in my environment. The aforementioned code is in my "Current User - All Hosts" profile for powershell 6. The latest version of nuget and powershell get are installed.

This is most likely an environmental issue having to do with network policy. I will investigate further in my environment and update here if a solution or verifiable cause is found.

[iyoumans]

I had already tried that to no effect. I have also tried setting $env:HTTP_PROXY and $env:HTTPS_PROXY to no effect either. Meanwhile, my Windows PowerShell (5.0) environment works fine on the same PC which means it's not a network or proxy issue as far as I can tell.

[iyoumans]

I somewhat solved this issue for myself. The problem was indeed my proxy. In Windows PowerShell, I set the HTTP_PROXY and HTTPS_PROXY environment variables to my proxy URI and that solves my issue. In PowerShell Core this doesn't appear to work. Instead, I passed the -Proxy tag on the Install-Module with the URI of my proxy and that worked. Kind of a pain - does anyone know how I can set and forget the proxy in PowerShell Core?

[mklement0]

@iyoumans: See #3112, which offers a workaround - sounds like support for these variables may come in the future, though note that on Unix-like platforms, where case matters, these variables are commonly _lowercase_ (http_proxy, https_proxy).

[markekraus]

CoreFX supports the following Environment Variables for proxies on Linux and macOS:

all_proxy
ALL_PROXY
http_proxy
https_proxy
HTTPS_PROXY
no_proxy

https://github.com/dotnet/corefx/blob/56d177d8ed94096c13ac14894945899783b1a3df/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpEnvironmentProxy.cs#L93

Note that it does not support HTTP_PROXY or NO_PROXY. Protocol specific trumps all. Lower case trumps upper.

[thezim]

Thanks @markekraus. We should get this info into the docs. I do see that Invoke-RestMethod has fallen behind in some of its parameters as well.

https://github.com/PowerShell/PowerShell-Docs/issues/1665

[iyoumans]

Changing the case of the environment variables didn't do anything for me (I'm on Windows though) - I still have to use the -Proxy switch. It seems the community is aware of the issue, so I'll close this thread.

[mklement0]

@iyoumans:

Sorry, I didn't mean to imply that the case would make a difference. On Windows, it never does, because accessing environment variables is always case-insensitive.

My understanding of the underlying issues is superficial, but based on what @markekraus said above and the information in #3112, the short of it is:

• On Unix-like platforms, Invoke-Webrequest and Invoke-RestMethod - which I _presume_ underlie PowerShell's package management - do not (yet) honor these environment variables, in any case variation, but support may be coming in 6.2.0.
  (I'm unclear on who honors them on Windows.)

• The safe case to use for these environment variables is _all-lowercase_, on all supported platforms.

@markekraus, is that a fair summary?

[megamorf]

@iyoumans Could you reopen this issue, since I'm facing the exact issue but none of the mentioned solutions have worked for me so far. I'd like to troubleshoot this more thoroughly this weekend and post my results afterwards. If they're conclusive we can close this issue, otherwise investigate further.

Thanks 👍

[iyoumans]

Re-opening on request...

[megamorf]

Okay, I seem to have narrowed down the issue. Among the people affected seem to be some Solus users as well.

Issue description

PowerShell Core is installed as classic snap. The web cmdlets and webclient related actions all fail with the following error message when attempting to connect to TLS protected resources while host OS binaries like curl can connect just fine:

The remote certificate is invalid according to the validation procedure.

There are two possible workarounds:

Option 1

I was able to get restore working on my Solus box by first running export DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0. Once I did that, dotnet restore worked.

Source: https://github.com/dotnet/core/issues/1668#issuecomment-398960685

Option 2

There's a bit of openssl which has been dormant forever which we are tripping over in some scenarios and we're working through the best fix. In the meantime, you can workaround this by setting the SSL_CERT_FILE to the host OS cert. Setting it to the Snap subsystem also works but that feels funny to me.

export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
export SSL_CERT_DIR=/dev/null

Source: https://github.com/dotnet/core-setup/issues/4295#issuecomment-422208914

I suggest documenting the workaround until the underlying issue has been identified and remediated (could be dotnet core or snapd according to the linked issues above).

[iyoumans]

Option 1 above worked for me. Thanks for all your help!

[godeater]

I'm trying to troubleshoot this on my work Windows 7 machine, which has currently got 6.2.0-preview.1 on it.

Specifying -Proxy to any of the *-Module commands (e.g. Find-Module or Install-Module) seems to be being entirely ignored. I've got Fiddler4 running at the moment, and have tried setting the value for -Proxy to "http://localhost:8888", but I see no traffic and fiddler, and thus I'm left with OP's original problem of:

Unable to resolve package source 'https://www.powershellgallery.com/api/v2/'

Since http access from any machine where I work has to go via our http proxies.

[iyoumans]

Did you try:

$env:DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0

[godeater]

I've just tried it this morning - didn't make any difference. As far as I can tell, the cmdlet is making no attempt to connect via a proxy.

[godeater]

Ok - I've been doing some more fiddling with the profile.ps1 that my PowerShell core environment is loading (which I'd been mostly copying over from my working profile for Windows PowerShell). I've not stripped out all the stuff I had in that original profile to do with proxies, and just set this:

$PSDefaultParameterValues["*:proxy"]=$env:http_proxy

and for whatever reason this has caused the install-module cmdlet to start working.

I realise this is functionally equivalent to calling the cmdlet with -proxy manually, but I'm assuming that it's something to do with all the other bits of .NET code I've taken out, rather than it having to be in the variable.

FWIW, things I've removed from the Pwsh profile: (for reference, localhost:3128 is a locally running instance of CNTLM, so I don't need to faff with authentication on our corporate proxies).

# This used to work under PowerShell for Windows
#$global:wc                   = New-Object Net.WebClient
#$global:wc.Proxy.Credentials = [Net.CredentialCache]::DefaultNetworkCredentials

# Weird environment variable sourced from https://github.com/PowerShell/PowerShell/issues/7827
# According to https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-2-1 this is
# used to disable use of the new "SocketsHttpHandler" in .NET Core 2.1, and allows the code
# to fall back to the older HttpClientHandler
#$env:DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=$false

# Possible new values required for PowerShell core?
#[System.Net.WebRequest]::DefaultWebProxy = New-Object System.Net.WebProxy('http://localhost:3128')
#[System.Net.WebRequest]::DefaultWebProxy.BypassProxyOnLocal = $true

[mashwanimq]

@godeater

I tried the following with no luck.

$env:http_proxy = 'http://<user>:<pass>@<server>:<port>/'
$PSDefaultParameterValues["*:proxy"]=$env:http_proxy`

Still getting:

WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2/'.

[godeater]

$env:http_proxy = 'http://<user>:<pass>@<server>:<port>/'
$PSDefaultParameterValues["*:proxy"]=$env:http_proxy`

I presume you have actual values in your http_proxy environment variable?

Have you tried doing what I did previously: running Fiddler4 and setting that variable to point to the fiddler instance, and see if you see any evidence of the proxy being hit?

[mashwanimq]

$env:http_proxy = 'http://<user>:<pass>@<server>:<port>/'
$PSDefaultParameterValues["*:proxy"]=$env:http_proxy`

I presume you have actual values in your http_proxy environment variable?

Have you tried doing what I did previously: running Fiddler4 and setting that variable to point to the fiddler instance, and see if you see any evidence of the proxy being hit?

I will try that and update

[jbirley]

Are others still having this problem? I am running Windows PowerShell 5.1 on Windows 2008 R2 (Win 7) along side of PowerShell Core 6.1.0 on the same system. PowerShellGet cmdlets work in 5.1, but not in 6.1.0. Same PSGallery SourceLocation (https://www.powershellgallery.com/api/v2), same versions of PowerShellGet (2.0.4). Could this be related to TLS 1.2?

[gluons]

I face the similar problem. But not in PS 6.10.
My PS is 5.1

Unable to find repository 'https://www.powershellgallery.com/api/v2/'. Use Get-PSRepository to see all available repositories.

But I already have PSGallery repository.

> Get-PSRepository
Name                      InstallationPolicy   SourceLocation
----                      ------------------   --------------
PSGallery                 Trusted              https://www.powershellgallery.com/api/v2

[gluons]

Nope.

https://evotec.xyz/update-module-packagemanagementinstall-package-unable-to-find-repository/ solves my problem. ❤️

[CollinChaffin]

Official answer here where I opened this issue about the same time as this OP:

https://github.com/PowerShell/PowerShellGet/issues/349

A PR was created that fixed this: https://github.com/PowerShell/PowerShellGet/pull/407

Also, I have determined and am testing a full automated workflow to correct any affected machines and normalize all stored repo URLs to the correct syntax. Once I test, I will post it and update my issue #349.

[amccool]

I am seeing this failure as well, after using IIS Crypto and disabling all Server and Client Protocols except for TLS1.2

PS C:temp> $oldSM = [Net.ServicePointManager]::SecurityProtocol
PS C:temp> $oldSM
Ssl3, Tls
PS C:temp> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
PS C:temp> Invoke-RestMethod -Uri "https://www.powershellgallery.com/api/v2"
Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a receive.
At line:1 char:1

• Invoke-RestMethod -Uri "https://www.powershellgallery.com/api/v2"
• ~~~~~~~~~~~~~
  
  
  
  • CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
  
  
  • FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand
  
  

[SteveL-MSFT]

Please continue discussion in https://github.com/PowerShell/PowerShellGet/issues/349

[mrlonis]

For those getting the following error message in PowerShell Core 6:

WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.

Run the following command in PowerShell:

[System.AppContext]::SetSwitch("System.Net.Http.UseSocketsHttpHandler", $false)

[shivakumarg06]

@mrlonis ,

Thanks Buddy, it worked

[Shiv-Shekhawat]

Try following, worked for me:

1. [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
2. Set-ExecutionPolicy RemoteSigned

First try option 1, if resolved be happy or use both 1 and 2 to be awesome.

[KonTheCat]

@Shiv-Shekhawat - what you said worked, thank you!

[c3rberus]

The first option worked for me as well. Why is this required to get Install/Update module to work? This is ran on up to date Windows 2016 box.

[vexx32]

/cc @SteveL-MSFT @SydneyhSmith

Did we get the TSL 1.0/1.1 turned back on for PSGallery? Seems like some folks are still having issues with that.

[Shiv-Shekhawat]

@Shiv-Shekhawat - what you said worked, thank you!

Glad to hear that, happy to help.

[Shiv-Shekhawat]

The first option worked for me as well. Why is this required to get Install/Update module to work? This is ran on up to date Windows 2016 box.

It seems like the latest Powershell version has dropped many functionality including support for TLS 1.0 and 1.1, thus the error.

[Shiv-Shekhawat]

/cc @SteveL-MSFT @SydneyhSmith

Did we get the TSL 1.0/1.1 turned back on for PSGallery? Seems like some folks are still having issues with that.

Its better to move forwards as TSL 1.0/1.1 are now discarded almost everywhere. Or those who has legacy applications may take a U turn and apply the options provided by the fellow contributors.

[FadJee]

the error disappeared on my side when I updated the "PowerShellGet" to the version "2.2.5". Also make sure that when u run "Get-Module PowerShellGet -ListAvailable" Only the 2.2.5 version is displayed , otherwise the same issue will be faced .. hope this helps