Aspnetcore: ASP.NET Core UseHttpsRedirection() only works locally

[k3davis]

Please forgive/correct if I am posting in the wrong repo. In the end this may be a docs issue?

I have an existing ASP.NET Core 2.0 project (which sadly must target net461) that I've upgraded simply to ASP.NET Core 2.1. When I add app.UseHttpsRedirection() and enable SSL in the project properties, it works perfectly when running locally, but when deployed to an IIS server it has no effect whatsoever.

What could I be overlooking?

[Tratcher]

See https://github.com/aspnet/Announcements/issues/301

[Tratcher]

https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-2.1&tabs=visual-studio

@Rick-Anderson

[Rick-Anderson]

@k3davis can you test this with the following?
dotnet new razor -o aspnetcoreapp

cc @guardrex

[k3davis]

@Rick-Anderson I did as you suggested, to the same result. I created the project as in your last post, built it, ran it locally (successful redirection), web deployed it to an IIS 8 server (successful), opened the site on the server and no redirection.

It seems unlikely this is a problem with the middleware but there is something amiss/missing in IIS configuration in general or the specific app/app pool, though I believe our setup to be pretty straightforward in that regard.

[Tratcher]

This is expected, see https://github.com/aspnet/Announcements/issues/301

[k3davis]

@Tratcher thanks, that's what I was asking. If it's expected I'm not sure what the test that was suggested was intended to prove.

[guardrex]

@k3davis I'm going to ("attempt to" :smile:) surface these details in the Enforcing HTTPS topic. I'll ping u on the PR for feedback.

[davidhenley]

Any update? Https redirection is spotty. Using AWS EB. Also doesn't work in incognito mode.

https://www.mydomain.com works
https://mydomain.com works
http://mydomain.com works (redirects)
mydomain.com works (redirects)
http://www.mydomain.com does not work. Insecure
www.mydomain.com does not work. Insecure

[guardrex]

@davidhenley You set the port and it's failing? ...

services.AddHttpsRedirection(options =>
{
    options.HttpsPort = 443;
});

[Tratcher]

@davidhenley that doesn't sound related to this issue about port detection. Please open a new issue with your setup details.

[guardrex]

That's in ConfigureServices ... then continue to call app.UseHttpsRedirection() in Configure. You'd have to do both.

[davidhenley]

@guardrex I set it in Environment variables and the www.mydomain.com will not redirect but the apex will. Any ideas?

[guardrex]

Take @Tratcher's advice. If he says it looks like something funky is going on .... something funky might be going on. :smile:

You could tho as a quick side-test go with the config I show and just see if the behavior changes. If it works perfectly that way, it would narrow it down to the env var approach (guessing, of course).

[svallis]

Explicitly setting the HTTPS port as per @guardrex's post seems to have fixed this issue for me.

It seems a little unintuitive to require explicitly declaring the default SSL port. Is there a good reason for the requirement? The announcement explains the _what_ but not the _why_.

[Tratcher]

Defaulting to 443 was causing a lot of issues when the site didn't have https enabled, you'd get redirected to a non-active port.

[svallis]

Perhaps the calls to app.UseHsts(); or app.UseHttpsRedirection(); could warn if no port has been set? This was an easy enough fix, but there's a good chance the edge cases that were failing could have gone unnoticed for a much longer period of time. Considering the fail state here is your entire site being served insecurely, and considering using app.UseHsts(); and app.UseHttpsRedirection(); implies a strict and secure access policy, it feels like there's a lot of surface area for "silent failure" to occur here.

[Tratcher]

Yes, there is a warning in your logs. Did you check?

[svallis]

I'm not seeing anything relevant in the dotnet run output. Setting the log levels to Debug gives a message about not being able to find the development HTTPS certificate, but I can't see anything related to the port.

[Tratcher]

Does dotnet run say "Now listening on https...?"

[svallis]

Yeah:

dbug: Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer[2]
      Failed to locate the development https certificate at '(null)'.
dbug: Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer[0]
      Using development certificate: CN=localhost (Thumbprint: <snip>)
dbugHosting environment: Development
: Microsoft.AspNetCore.Hosting.Internal.WebHost[4]
      Hosting started
Content root path: C:\Development\Test
Now listening on: https://localhost:5001
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
dbug: Microsoft.AspNetCore.Hosting.Internal.WebHost[0]
      Loaded hosting startup assembly Test

That's after doing a dotnet new razor and then editing appsettings.Development.json to be Debug for all levels. Sorry if I'm missing something basic here.

[Tratcher]

Running locally it's able to add a default https endpoint using the dev cert. The https port is then discovered from the local server config. Running on IIS this isn't an option, and it can't examine the reverse proxy's configuration so it doesn't know if https is enabled or not. If you enable logs in IIS you'll get a warning about this.

[svallis]

Right, so the warning is contextual. Fair enough. My bad for not keeping a close eye on the live logs. Still feels like a bit of a gotcha, but not really sure what to suggest either. Thank you for taking a look.

[guardrex]

but not really sure what to suggest either

I must surface it in the doc to clarify the behavior. It's coming up on https://github.com/aspnet/Docs/issues/6538. I'm on "vacation" ... sort of ... right now. I'll get on this asap when I'm "back" ... fully back anyway. :smile:

[qwertyuiope]

I explicitly set the ports as @guardrex suggested and now I am getting:

This page isn’t working
... redirected you too many times

[guardrex]

@qwertyuiope ... @Tratcher has remarked on the 'too many redirects' problem ...

This is usually caused by the back-end app not knowing the correct scheme. See https://docs.microsoft.com/aspnet/core/host-and-deploy/proxy-load-balancer

Reference: https://github.com/aspnet/AspNetCore/issues/3086#issuecomment-383692238

If your scenario turns out to be the same and you end up using the Forwarded Headers Middleware, please let me know. I plan to make an update to the Enforcing HTTPS topic to help surface it.

[johmarjac]

I am still having this issue, on my local it works, on my remote machine it does not work. First I was using only app.UseHttpsRedirect(). This didnt work, so I came here and thought I could try to add services.AddHttpsRedirection(options => options.HttpsPort = 443);

Did that, without success, so what now? Calling my site on https://mydomain.net works without problem, but if I call http://mydomain.net I get error 403 iis default page

[Tratcher]

Comments on closed issues are not tracked, please open a new issue with the details for your scenario.

[guardrex]

@johmarjac Open it using the This Page button at the bottom of https://docs.microsoft.com/aspnet/core/security/enforcing-ssl

[yepeekai]

When calling UseHttpsRedirection, this is the kind of call I expect either to work or throw... not fail silently to eventually discover later that the site was in http including the login screen.
It works on the dev machine... but not when deployed... it does sound like a receipe for disaster

[yepeekai]

Also, I don't see how having no default value (in this case) has overall less issues than having one...

[Will-Bill]

if anyone is getting err_too_many_redirects and they are using CloudFlare, make sure SSL is set to Full and not Flexible under Crypto settings.

[ewilansky]

We also ran into the error too many redirects error with a simple .NET Core 2.2 React app. We configured the ASPNETCORE_HTTP_PORT environment variable to port 443 and kept the Startup.cs unchanged (includes UseHttpsRedirection middleware). We also tried adding UseForwardedHeaders middleware, but that didn't make a difference. We were still getting the redirects error.

Our solution was to let Azure handle the redirection. In Azure, go to your app service > tls/ssl settings and enable HTTPS only. We removed the ASPNETCORE_HTTP_PORT environement variable and the UseForwardedHeaders middleware, but left UseHttpsRedirection for local development purposes.