Web API template doesn't run in WSL

[analogrelay]

From @mfish0005 on Tuesday, June 11, 2019 9:14:26 PM

Web API template won't run from WSL(Ubuntu) shell

Environment

.NET Core SDK (reflecting any global.json): Version: 2.2.300 Commit: 73efd5bd87

Runtime Environment: OS Name: ubuntu OS Version: 18.04 OS Platform: Linux RID: ubuntu.18.04-x64 Base Path: /usr/share/dotnet/sdk/2.2.300/

Host (useful for support): Version: 2.2.5 Commit: 0a3c9209c0

.NET Core SDKs installed: 2.2.300 [/usr/share/dotnet/sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.All 2.2.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.2.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.2.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

How to Replicate

Run these commands dotnet new webapi -o ExampleAPI cd ExampleAPI dotnet run

Open browser at localhost:5000 or localhost:5001

Error Details

Browser: "This site can't provide a secure connection" or not found or NET::ERR_CERT_AUTHORITY_INVALID

Terminal Errors: I run mfish0005@DESKTOP-1QIJO18:/mnt/d/projects/ExampleAPI$ dotnet run I visit localhost:5001 and then this is logged to the terminal:

: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
      User profile is available. Using '/home/mfish0005/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
Hosting environment: Development
Content root path: /mnt/d/projects/ExampleAPI
Now listening on: https://localhost:5001
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
info: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[14]
      Connection id "0HLNEM2BBOILP" communication error.
System.Net.Sockets.SocketException (22): Invalid argument
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.<GetResult>g__ThrowSocketException|7_0(SocketError e)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.ProcessReceives()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.DoReceive()
info: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[14]
      Connection id "0HLNEM2BBOILQ" communication error.
System.Net.Sockets.SocketException (22): Invalid argument
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.<GetResult>g__ThrowSocketException|7_0(SocketError e)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.ProcessReceives()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.DoReceive()
info: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[14]
      Connection id "0HLNEM2BBOILR" communication error.
System.Net.Sockets.SocketException (22): Invalid argument
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.<GetResult>g__ThrowSocketException|7_0(SocketError e)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.ProcessReceives()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.DoReceive()
info: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[14]
      Connection id "0HLNEM2BBOILS" communication error.
System.Net.Sockets.SocketException (22): Invalid argument
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.<GetResult>g__ThrowSocketException|7_0(SocketError e)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.ProcessReceives()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.DoReceive()

Summary

This likely seems to be caused by SSL certs. I'm new to netcore and I've tried for a whole day to fix it with no luck. I imagine others like me also have this issue. It's worth noting that dotnet new mvc and dotnet run yields a successful result with no errors.

Copied from original issue: dotnet/core#2852

[analogrelay]

From @mfish0005 on Tuesday, June 25, 2019 10:03:29 PM

It's been a couple weeks and I was working on other stuff but I'm back to this. I've discovered a couple things. The Kestrel error never happens if you don't use the "Enable HTTPS" option when generating the project.

When you run the project from bash and navigate to localhost:5001 you get the same result though: `localhost refuses to connect'.

Only it's a silent error so I can't give you much to go on if that matters. If this is even the right place to post bug reports?

[analogrelay]

From @carlossanlop on Tuesday, July 9, 2019 5:01:21 PM

@Pilchie is this something the ASP.NET team can assist with?

[analogrelay]

From @Pilchie on Tuesday, July 9, 2019 5:07:00 PM

@anurse move to AspNetCore?

[analogrelay]

@mfish0005 the issue here is that your WSL instance is basically a separate "machine" from your Windows machine. ASP.NET Core uses SSL by default (to encourage the use of SSL as much as possible). We handle this relatively well when you're on the same machine. On Windows we automatically install a Self-Signed SSL Certificate and mark it as trusted. We do the same on macOS.

What's happened is that on WSL, we've installed a dev certificate for you, but it's in the WSL file system. When you access the site on Windows, we send the certificate, but it's not trusted by your Windows machine.

You can fix this by exporting the certificate from your WSL instance and then importing it into the Windows Certificate Store as trusted. I haven't been able to set up to test these steps yet, but you'd need to do something like this:

1. Export the certificate from WSL: dotnet dev-certs https -ep ~/aspnetcore_dev_cert.pfx
2. Copy this .pfx file to Windows.
3. Import this certificate on Windows as trusted.

(@javiercn does this look right or am I off-track somewhere here?)

[javiercn]

except for the -p piece. You only need the public piece. Theoretically you could use the same cert on windows and WSL, but it will be a bit cumbersome to setup and we can't do it for you.

If you wanted to do so, what andrew suggested is the right thing to do. (you would need to run dotnet dev-certs --clean first on windows).

That way you end up with the same localhost cert on windows and WSL and should work in both places.

[analogrelay]

@javiercn there may be some tricks we could do here that could be interesting to explore sometime. I'll file an issue (https://github.com/aspnet/AspNetCore/issues/12011). At a minimum we could write a useful doc or something and print a warning when running on WSL (which we can detect).

[mfish0005]

@anurse @javiercn Thanks for getting back to me on this guys. So let me get it straight.

1. Run dotnet dev-certs https --clean from windows shell
2. Run dotnet dev-certs https -ep ~/aspnetcore_dev_cert.pfx from linux shell
3. Locate cert in WSL.
4. Copy it and import to Windows

Questions(mainly to give perspective on what to include in #12011 docs):

1. Do I need to delete the old https cert on WSL and generate a new one?
2. Where is the default location for the cert on WSL? ~/aspnetcore_dev_cert.pfx?

[mfish0005]

Well I think I have it figured out but just using MMC is difficult enough. I'm assuming I need to add the cert to the Personal > Certificates directory so I'm trying that now. Might want to include MMC instructions in the docs

[analogrelay]

1. Do I need to delete the old https cert on WSL and generate a new one?

No.

2. Where is the default location for the cert on WSL? ~/aspnetcore_dev_cert.pfx?

The --export-path (or -ep for short) argument is just specifying where you want to export the certificate TO. The certificate is stored in whatever OS-specific store makes sense. The certificate store (MMC) in Windows, Keychain on macOS, and I believe in /etc/pki on Linux...

I'm assuming I need to add the cert to the Personal > Certificates directory so I'm trying that now

Yeah, it's not the best interface :). You need to put it there and copy it to the Trusted Root store.

[mfish0005]

@anurse Thanks I added it to the Trusted Root store. Question: Visual Studio will automatically know to apply this cert to all targets? E.G. IIS, Docker, etc.

So far it isn't working but I'm going to try restarting real quick to see if that fixes it.

[analogrelay]

Visual Studio will automatically know to apply this cert to all targets

Well, it should, as long as you only have one ASP.NET Core Dev Cert on the Windows side, and it's the same one as in WSL. You can tell which are the dev certs by their friendly name in MMC:

Are you running apps in both Windows and WSL? You mentioned Visual Studio/IIS/etc. which is why I ask. That should be fine but you'll definitely want to ensure you a) have only one dev cert on Windows and b) that it's the same cert as on WSL (easiest to achieve by generating a cert on WSL and exporting it to Windows).

[mfish0005]

Yes I'm using Visual Studio to develop the application. I wanted to do everything from WSL but I couldn't figure out how to get it working so I just went back to VS.

Anyways I removed the old Windows cert, added the new one to the Trusted Root Store, restarted, and ended up getting the same error.

I tried to run the project from Visual Studio using various web servers/build targets. Docker: Project built properly but browser had https error IIS: Same as Docker Building the solution itself( e.g. clicking the play button next to SolutionName.sln) it prompted me to create a new certificate.

[analogrelay]

Docker: Project built properly but browser had https error

Docker is going to be a similar situation. The dev cert needs to be present in the docker container. I'm not sure what, if any, guidance we have for that aside from just disabling dev-time SSL for that scenario (not ideal, but it would avoid the problem...).

Building the solution itself( e.g. clicking the play button next to SolutionName.sln) it prompted me to create a new certificate.

Hrm, that indicates that the dev certs tool isn't seeing the cert you imported into Windows as a valid dev cert.

Perhaps it's good to do a full clean-up at this point. Run dotnet dev-certs https --clean on both Windows and WSL and start again.

[javiercn]

Docker is going to be a similar situation.

Docker is handled by the tool and VS. They export the cert from the local machine and map it into the container at the right place.

[mfish0005]

Guys I really don't have time to solve this one right now. Finished up a long term project and looking for work, landlord wants to sell my house so I have to move, etc. etc.

If you want to leave it open I'll get to it when I can so we can try to improve the docs.

Thanks for the help everyone

[mkArtakMSFT]

Closing as a dupe of https://github.com/dotnet/aspnetcore/issues/12011