Deploy asp.net Kern mvc hinter NGINX die SSL-Termination tut - Leitet auf nicht sichere Login-Seite

Question

Wenn die Website über SSL Anforderung und nicht https://example.com

ich http://example.com/Account/Login

weitergeleitet authentifiziert Ich habe NGINX läuft an Die Kante als Load Balancer, die das SSL beendet und die Anforderung als HTTP an IIS weiterleitet.

NGINX Config

server { 
    server_name example.com; 
    listen 443 ssl; 

    location/{ 
     proxy_pass http://cluster1; 
     proxy_set_header Host $host; 
     proxy_set_header X-Real-IP $remote_addr; 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
     #proxy_set_header X-Forwarded-Proto $scheme; 
    } 

}

wie man sehen kann ich die X-Forwarded-For und X-Forwarded-Proto Header

In meiner MVC-app Starteinstellung ich habe dies in Konfigurieren

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) 
    { 

     app.UseForwardedHeaders(new ForwardedHeadersOptions 
     { 
      ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto, 
      ForwardLimit = null, 
      RequireHeaderSymmetry = false 
     }); 

Ich habe [RequireHttps] Attribut auf meinen Controllern.

Was fehlt mir?

Answer 1

aktualisieren .NETCore 1.0.1, 1.0.2, 1.1.0:

Neues Update .NETCore 1.0.1, 1.0.2, scheint 1.1.0

Update, um das Problem behoben Abhilfe:

die Ursache von Antwort root verstehen https://serverfault.com/a/516382/379823

Es funktioniert für uns auf Ubuntu 16.04 LTS/Nginx/1.10.0

hinzufügen Karte:

map $http_x_forwarded_proto $thescheme { 
    default $scheme; 
    https https; 
} 

und die proxy_set_header Linie die Änderung der neuen Regelung zu verwenden:

# proxy_set_header X-Forwarded-Proto $scheme; 
proxy_set_header X-Forwarded-Proto $thescheme; 

Vorherige Abhilfe:

Wir haben das gleiche Problem bekam. Wir umgehen das Problem mit NGINX redirect HTTP => HTTPS (doppelte Weiterleitung).

Wenn ich gerade docs.asp.net wieder sorgfältig gelesen habe, scheint es umleitung HTTP => HTTPS ist der einzige Weg diesmal.

server { 
    listen *:80; 
    add_header Strict-Transport-Security max-age=15768000; 
    return 301 https://$host$request_uri; 
} 

Siehe docs hier Securing our application/Configure SSL