dotnet restore fails

[leecow]

@tristan957 commented on Wed Jun 06 2018

These are the errors I received after running dotnet-sdk.dotnet restore:

/snap/dotnet-sdk/18/sdk/2.1.300/NuGet.targets(114,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/home/tristan957/Projects/full-stack-forum/full-stack-forum.csproj]
/snap/dotnet-sdk/18/sdk/2.1.300/NuGet.targets(114,5): error :   The SSL connection could not be established, see inner exception. [/home/tristan957/Projects/full-stack-forum/full-stack-forum.csproj]
/snap/dotnet-sdk/18/sdk/2.1.300/NuGet.targets(114,5): error :   The remote certificate is invalid according to the validation procedure. [/home/tristan957/Projects/full-stack-forum/full-stack-forum.csproj]

This was after I ran dotnet-sdk.dotnet new reactredux

---

@leecow commented on Thu Jun 07 2018

Hi @tristan957 - This is an issue on a few distros that I haven't gotten to the bottom of yet. Let me shake some bushes around here and figure out what conditions can lead to the errors.

---

@tristan957 commented on Thu Jun 07 2018

Sorry if this is a duplicate. Thanks for the response. Let me know if I can provide you with any information

---

@leecow commented on Thu Jun 07 2018

Don't know yet if it's related but found this - https://github.com/dotnet/corefx/issues/29942

---

@Petermarcu commented on Tue Jun 12 2018

@leecow should we move this to the nuget repo to track it to start?

---

@leecow commented on Wed Jun 20 2018

Chasing another issue has lead me to a possible solution for this one ;-) Looks like this is related to the switch to SocketsHttpHandler (see the 2.1 Preview 2 blog post).

@tristan957 - 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.

---

@tristan957 commented on Thu Jun 21 2018

Interesting. Is there something special about Solus that I should bring up to my distro maintainers, or is this solely a .NET Core issue? Would I experience this issue on other distros?

---

@leecow commented on Thu Jun 21 2018

I think it may have more to do with Ubuntu Core which is the root of the Snap environment where snaps really run. Still need to poke around a bit more.

---

@tristan957 commented on Thu Jun 21 2018

No rush. If you need me to test things on my end, let me know

[tristan957]

In the future is there a method to the madness on where what issues should go to what repositories?

[omajid]

@tristan957 I believe we try and look at where the code that causes the issue lives and move the issue into that repo. If this is an issue in networking code, it probably belongs in corefx (eg, dupe of https://github.com/dotnet/corefx/issues/29942). But as @leecow says, this might be an issue in snaps. The packaging code for snaps live in this repo (core-setup). Sometimes it's hard to know where an issue belongs when we are filing it.

[leecow]

@tristan957 - We've finally gotten to the bottom of this (thanks to @bartonjs ). 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

[JohanLarsson]

I'm getting this on Win 10 behind proxy.

[mclang]

I am running Solus on two machines.

I tried to use snap package but it gave following error:

/snap/dotnet-sdk/25/sdk/2.2.100/NuGet.targets(114,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/home/<user>/Projects/dotnet-core-test/dotnet-core-test.fsproj]
/snap/dotnet-sdk/25/sdk/2.2.100/NuGet.targets(114,5): error :   The SSL connection could not be established, see inner exception. [/home/<user>/Projects/dotnet-core-test/dotnet-core-test.fsproj]
/snap/dotnet-sdk/25/sdk/2.2.100/NuGet.targets(114,5): error :   The remote certificate is invalid according to the validation procedure. [/home/<user>/Projects/dotnet-core-test/dotnet-core-test.fsproj]

I did manual installation using .NET Core 2.2.0 SDK Binary and got dotnet new and dotnet restore working on my Solus Budgie PC, but not on the Solus Plasma laptop.

After doing export DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0 on the laptop, dotnet restore started to work also in that computer.

Maybe this helps you to solve the issue. I can provide more information if needed, provided you tell me how to get it.

[omajid]

Sounds almost like https://github.com/dotnet/corefx/issues/32224. I can't tell if the fix was backported to 2.2 or not.

[bartonjs]

@omajid Should be, the commit was dotnet/corefx@d3d3336, which was brought to release/2.2 via dotnet/corefx@d3d3336 (not that the GitHub UI shows that, because it's showing what changes were in release/2.2 that made it different from release/2.1 at that point).

The 2.2.100 tgz for portable linux has the fix; but I don't know enough about the dotnet command to know if maybe it would have picked up a 2.1.x (or older) runtime.

@mclang Does your laptop also have a .NET Core 2.1 on it? If so, is it 2.1.6, or something older?

[mclang]

No, I don't have anything else than 2.2.100 installed now.

I tried snap version before, but it didn't work b/c SSL errors so I removed it to keep the system clean. This is my dotnet --info:

.NET Core SDK (reflecting any global.json):
 Version:   2.2.100
 Commit:    b9f2fa0ca8

Runtime Environment:
 OS Name:     solus
 OS Version:  3.9999
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /opt/dotnet/sdk/2.2.100/

Host (useful for support):
  Version: 2.2.0
  Commit:  1249f08fed

.NET Core SDKs installed:
  2.2.100 [/opt/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.0 [/opt/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.0 [/opt/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.0 [/opt/dotnet/shared/Microsoft.NETCore.App]

[berlstone]

I have the same issue in Windows 10 machine with .Net Core 2.2.102

When I use dotnet restore command, the packages are not restoring but the same same URL mentioned in the error message works through the browser. I have also checked the proxy settings and nothing is set in the system. I have also tried in multiple machines and the issue is still same.

[leecow]

@mclang - setting a couple environment variables as noted up in the thread should get you unblocked. We thought we had this one fixed but apparently not. For anyone else reading along, the cert location is distro-specific. The below value is good for Solus.

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

[leecow]

@berlstone - are you running under Windows (cmd or powershell) or in WSL?

[433845]

I'm getting the same error in Windows 10 when I try "dotnet restore" as part of a docker build. But from the exact same folder, "dotnet restore" on the command-line works fine.
Behind a corporate proxy, I send the HTTP_PROXY as a build-arg to Docker

dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.1.403
Commit: 04e1549

Runtime Environment:
OS Name: Windows
OS Version: 10.0.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.403\

Host (useful for support):
Version: 2.1.5
Commit: 290303f510

.NET Core SDKs installed:
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.103 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

[mclang]

@mclang - setting a couple environment variables as noted up in the thread should get you unblocked. We thought we had this one fixed but apparently not. For anyone else reading along, the cert location is distro-specific. The below value is good for Solus.

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

Thanks for the info.

I tried again with dotnet SDK 2.2.104 on both the Solus pcs and find out that creating new F# console project and running dotnet restore works without both DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLERand those SSL_CERT things. I really don't know what has happened, I have to test again later after removing all additions for good.

[mclang]

Hello

I tried again without DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER and SSL_CERT_ definitions and all worked as they sould:

$ dotnet new console --language F#
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on /home/.../Projects/dotnet-sdk-2.2.104-test/dotnet-sdk-2.2.104-test.fsproj...
  Restoring packages for /home/.../Projects/dotnet-sdk-2.2.104-test/dotnet-sdk-2.2.104-test.fsproj...
  Generating MSBuild file /home/.../Projects/dotnet-sdk-2.2.104-test/obj/dotnet-sdk-2.2.104-test.fsproj.nuget.g.props.
  Generating MSBuild file /home/.../Projects/dotnet-sdk-2.2.104-test/obj/dotnet-sdk-2.2.104-test.fsproj.nuget.g.targets.
  Restore completed in 163.48 ms for /home/mclang/Projects/dotnet-sdk-2.2.104-test/dotnet-sdk-2.2.104-test.fsproj.

Restore succeeded.

$ dotnet run
Hello World from F#

This issue can, as far as I am concerned, be closed.

[leecow]

Confirmed on a few different distros that restore works without setting SSL_CERT_FILE and SSL_CERT_DIR.

[osagga]

if anyone facing this problem on Linux (with openssl 1.1), this fix (NuGet/Home#8169 (comment)) worked for me

[8bg]

@tristan957 - We've finally gotten to the bottom of this (thanks to @bartonjs ). 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

I am just now encountering these certificate errors on a new install of .NET 2.2 SDK on Ubuntu 19.04. The above resolved my issues - thank you!