How do I disable HTTPS in ASP.NET Core 2.1 + Kestrel?

Question

So it appears with the advent of ASP.NET Core 2.1, Kestrel now automatically creates an HTTPS endpoint along side the HTTP one, and default project templates are setup to redirect from HTTP to HTTPS (which is easy enough to undo).

However my question is... how can I disable HTTPS entirely for my project. I've read through the docs and played with a variety of config settings for HTTPS but nothing I do seems to allow me to turn it off and just run an HTTP project.

Am I crazy or just missing something. I would expect this to be super easy to do.

Answer 1

In the Startup.cs, remove the middleware

app.UseHttpsRedirection();

Answer 2

If you are using Visual Studio 2017, then you can do the following:

1. Go to your project properties. (Right-click > Properties)
2. Click on the Debug tab.
3. Under Web Server Settings, deselect Enable SSL.
4. Save, build, and try again.

This will update the iisExpress settings in the launchSettings.json file.

Answer 3

In the file Properties/launchSettings.json of your project, look of the key applicationUrl. You will find something like:

...
"applicationUrl": "https://localhost:5001;http://localhost:5000",
...

Remove the https endpoint and it's done.

Edit

As noted by @Xorcist the file launchSettings.json is not published. So, the solution above will only work in a development environment. To disable https and, in general, to configure the urls you want to listen to, both in production and in development, you can also do one of the following:

• Use --urls parameters of dotnet run, will have the same effect as the applicationUrl in launchSettings.json. For instance: dotnet run --urls=http://0.0.0.0:5000,https://0.0.0.0:5001. Again, remove the one you don't want to use.

• The same can be achieved with the ASPNETCORE_URLS enviroment variable.

• As mentioned in the answer by @Konstantin to this question, in ASP Net Core 2.1 you can also configure Kestrel endpoints in the appsettings.json (it seems this cannot be done in 2.0).

• Finally, the same can also be achieved with the useUrls extension method WebHost.CreateDefaultBuilder(args).UseUrls("http://0.0.0.0:5000"). I prefer the other solution because this ones hardcodes you're application endpoints, and can't be changed without recompiling the application.

All the possible options are explained in detail in the Microsoft Docs on this.

Update (09 Dec 2020): these options are still valid for Net Core 3.1, as per Microsoft Docs, except for the appsettings one. Maybe it still works but I am not sure.

Update (19 May 2021): these options are still valid for Net 5, as per Microsoft Docs, except for the appsettings one. Maybe it still works but I am not sure.

Answer 4

Turns out the proper way to achieve what I wanted to do, was to specifically configure Kestrel with .UseKestrel() and simply specify a single address, like this:

  WebHost.CreateDefaultBuilder(args)
    .UseKestrel(options => {
      if (context.Configuration[WebHostDefaults.EnvironmentKey] == Environments.Development) {
        options.Listen(IPAddress.Loopback, 5080); //HTTP port
      }
    })
    .UseStartup<Startup>();

in effect overriding the default setup, and displaying this warning when Kestel starts:

warn: Microsoft.AspNetCore.Server.Kestrel[0]
  Overriding address(es) 'https://localhost:5001, http://localhost:5000'. Binding to endpoints defined in UseKestrel() instead.

Note the check for development environment; in production the default ports are different (80) and without HTTPS.

if a second address is specified it will assume that address is to be secured with the built-in developer cert, as such:

  WebHost.CreateDefaultBuilder(args)
    .UseKestrel(options => {
      options.Listen(IPAddress.Loopback, 5080); //HTTP port
      options.Listen(IPAddress.Loopback, 5443); //HTTPS port
    })
    .UseStartup<Startup>();

you may of course specifically secure your SSL address as described here:

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.1&tabs=aspnetcore2x

which is necessary for production setups.

Answer 5

In the Program.cs, Add UseUrls as following:

WebHost.CreateDefaultBuilder(args)
.UseUrls("http://localhost:5000")
.UseStartup<Startup>();

And In The Startup.cs remove/comment the following:

app.UseHttpsRedirection();

Answer 6

The dotnet CLI now has a template for this.

dotnet new webapi --no-https

Answer 7

Turning off https lies in these 3 changes...

Properties/launchSettings.json

• set sslPort to 0
• remove the https url from the applicationUrl

Startup.cs

• Remove or comment-out app.UseHttpsRedirection()

Answer 8

With ASPNET CORE 2.2, I simply set the web server URL to http not https and it picks it up on its own. I run it as a self hosted process.

1. Go to your project properties.
2. Click on the Debug tab.
3. Under Web Server Settings, set the URL to http://xxx
4. Try again :)

Answer 9

For Development & not in production:

in project properties disable Enable SSL

Answer 10

One more way for disabling https epecially is handy when docker is used. Set enviroment variable in Dockerfile with only one HTTP url in value.

#https + http
ENV ASPNETCORE_URLS=http://+:5001;http://+:5000 

#http only
ENV ASPNETCORE_URLS=http://+:5000 

Answer 11

@joanlofe answer is excellent one, but there is also "stupid" way how one can reintroduce HTTPS on 5001 port. If you call Clear on your config sources (for proper layering of config sources for example) it means that one implicit source is gone -- "launchSettings.json" template. So if you rely on this file instead of "appsettings.json" (and by default you probably are) your app will enable HTTPS on port 5001.

Answer 12

My local k8s deployment was failing due to the existence of

"Kestrel": {
  "Certificates": {
    "Default": {
      ...
    }
  }
}

in an appsettings.json override, even after following the other steps here. If you're trying to strip a server of SSL (for example, if SSL is now terminated upstream), make sure to get rid of this configuration as well.

This seems pretty obvious now that I found it, but it still tripped us up for a few hours.