Framtvinga HTTPS i ASP.NET Core

HTTP-omdirigering till HTTPS, orsakar ERR_INVALID_REDIRECT för CORS-förfrågan vid preflight-begäran.

Begäranden till en slutpunkt med HTTP som omdirigeras till HTTPS av UseHttpsRedirection misslyckas på ERR_INVALID_REDIRECT på CORS-preflight-begäran.

API-projekt kan avvisa HTTP-begäranden i stället för att använda UseHttpsRedirection för att omdirigera begäranden till HTTPS.

Kräv HTTPS

Vi rekommenderar att produktions-ASP.NET Core-webbapplikationer använder:

• HTTPS Redirection Middleware (UseHttpsRedirection) för att omdirigera HTTP-begäranden till HTTPS.
• HSTS Middleware (UseHsts) för att skicka HSTS-huvuden (HTTP Strict Transport Security Protocol) till klienter.

AnvändHttpsOmdirigering

Följande kod anropar UseHttpsRedirection i filen Program.cs:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Föregående markerade kod:

• Använder standardvärdet HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Använder standardvärdet HttpsRedirectionOptions.HttpsPort (null) om det inte åsidosätts av miljövariabeln ASPNETCORE_HTTPS_PORT eller IServerAddressesFeature.

Vi rekommenderar att du använder tillfälliga omdirigeringar i stället för permanenta omdirigeringar. Länkcachelagring kan orsaka instabilt beteende i utvecklingsmiljöer. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen finns i en miljö som inte är utvecklingsmiljö kan du läsa avsnittet Konfigurera permanenta omdirigeringar i produktion. Vi rekommenderar att du använder HSTS- för att signalera till klienter att endast säkra resursbegäranden ska skickas till appen (endast i produktion).

Portkonfiguration

En port måste vara tillgänglig för mellanprogrammet för att omdirigera en osäker begäran till HTTPS. Om ingen port är tillgänglig:

• Omdirigering till HTTPS sker inte.
• Mellanprogrammet loggar varningen "Det gick inte att fastställa https-porten för omdirigering".

Ange HTTPS-porten med någon av följande metoder:

• Ange HttpsRedirectionOptions.HttpsPort.

• Ange värdinställning https_port:

  • I värdkonfiguration.

  • Genom att ange miljövariabeln ASPNETCORE_HTTPS_PORT.

  • Genom att lägga till en post på den översta nivån i appsettings.json:

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• Ange en port med det säkra schemat med hjälp av ASPNETCORE_URLS miljövariabeln. Miljövariabeln konfigurerar servern. Mellanprogrammet identifierar indirekt HTTPS-porten via IServerAddressesFeature. Den här metoden fungerar inte i distributioner med omvänd proxy.

• Webbmallarna ASP.NET Core anger en HTTPS-URL i Properties/launchsettings.json för både Kestrel och IIS Express. launchsettings.json används endast på den lokala datorn.

• Konfigurera en HTTPS-URL-slutpunkt för en offentlig edge-distribution av Kestrel server eller HTTP.sys server. Endast en HTTPS-port används av appen. Mellanprogrammet identifierar porten via IServerAddressesFeature.

Edge-distributioner

När Kestrel eller HTTP.sys används som en offentlig edge-server måste Kestrel eller HTTP.sys konfigureras för att lyssna på båda:

• Den säkra port där klienten omdirigeras (vanligtvis 443 i produktion och 5001 under utveckling).
• Den osäkra porten (vanligtvis 80 i produktion och 5 000 under utveckling).

Den osäkra porten måste vara tillgänglig för klienten för att appen ska kunna ta emot en osäker begäran och omdirigera klienten till den säkra porten.

Mer information finns i Kestrel slutpunktskonfiguration eller HTTP.sys webbserverimplementering i ASP.NET Core.

Distributionsscenarier

Alla brandväggar mellan klienten och servern måste också ha kommunikationsportar öppna för trafik.

Om begäranden vidarebefordras i en konfiguration med omvänd proxy använder du Vidarebefordrade rubriker Mellanprogram innan du anropar HTTPS Redirection Middleware. Mellanprogrammet för vidarebefordrade rubriker uppdaterar Request.Schememed hjälp av X-Forwarded-Proto-huvudet. Mellanprogrammet tillåter att omdirigerings-URI:er och andra säkerhetsprinciper fungerar korrekt. När mellanliggande programvara för vidarebefordrade rubriker inte används kanske backend-appen inte får rätt schema och hamnar i en omdirigeringsloop. Ett vanligt felmeddelande från slutanvändaren är att för många omdirigeringar har inträffat.

När du distribuerar till Azure App Service följer du anvisningarna i Självstudie: Binda ett befintligt anpassat SSL-certifikat till Azure Web Apps.

Alternativ

Följande markerade kod anropar AddHttpsRedirection för att konfigurera mellanprogramsalternativ:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Det är bara nödvändigt att anropa AddHttpsRedirection för att ändra värdena för HttpsPort eller RedirectStatusCode.

Föregående markerade kod:

• Anger HttpsRedirectionOptions.RedirectStatusCode till Status307TemporaryRedirect, vilket är standardvärdet. Använd fälten i klassen StatusCodes för tilldelningar till RedirectStatusCode.
• Anger HTTPS-porten till 5001.

Konfigurera permanenta omdirigeringar i produktion

Mellanprogrammet skickar som standard en Status307TemporaryRedirect med alla omdirigeringar. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen är i en icke-utvecklingsmiljö, omsluter du konfigurationen av mellanprogramsalternativen i en villkorlig kontroll för en miljö som inte är utvecklingsmiljö.

När du konfigurerar tjänster i Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Alternativ metod för HTTPS-omdirigeringsmiddleware

Ett alternativ till att använda HTTPS Redirection Middleware (UseHttpsRedirection) är att använda URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps kan också ange statuskod och port när omdirigeringen körs. Mer information finns i URL-omskrivningsmellanlager.

När du omdirigerar till HTTPS utan krav på ytterligare omdirigeringsregler rekommenderar vi att du använder HTTPS Redirection Middleware (UseHttpsRedirection) som beskrivs i den här artikeln.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HTTP Strict Transport Security (HSTS) är en alternativ säkerhetsförbättring som anges av en webbapp med hjälp av ett svarshuvud. När en webbläsare som stöder HSTS tar emot den här rubriken:

• Webbläsaren lagrar konfigurationen för domänen som förhindrar att någon kommunikation skickas via HTTP. Webbläsaren tvingar fram all kommunikation via HTTPS.
• Webbläsaren hindrar användaren från att använda ej betrodda eller ogiltiga certifikat. Webbläsaren inaktiverar uppmaningar som gör att en användare tillfälligt kan lita på ett sådant certifikat.

Eftersom HSTS- tillämpas av klienten har den vissa begränsningar:

• Klienten måste ha stöd för HSTS.
• HSTS kräver minst en lyckad HTTPS-begäran för att upprätta HSTS-principen.
• Programmet måste kontrollera varje HTTP-begäran och omdirigera eller avvisa HTTP-begäran.

ASP.NET Core implementerar HSTS med UseHsts-tilläggsmetoden. Följande kod anropar UseHsts när appen inte är i utvecklingsläge:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts rekommenderas inte under utveckling eftersom HSTS-inställningarna är mycket cachelagrade av webbläsare. Som standard utesluter UseHsts den lokala loopback-adressen.

För produktionsmiljöer som implementerar HTTPS för första gången anger du den första HstsOptions.MaxAge till ett litet värde med någon av de TimeSpan metoderna. Ange värdet från timmar till högst en enda dag om du behöver återställa HTTPS-infrastrukturen till HTTP. När du är säker på hållbarheten i HTTPS-konfigurationen ökar du värdet för HSTS-max-age. ett vanligt värde är ett år.

Följande markerade kod:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• Anger parametern för förinläsning av Strict-Transport-Security-huvudet. Förinläsning är inte en del av RFC HSTS-specifikationen, men stöds av webbläsare för att förinstallera HSTS-webbplatser vid ny installation. Mer information finns i https://hstspreload.org/.
• Aktiverar includeSubDomain, som tillämpar HSTS-principen på värdunderdomäner.
• Anger uttryckligen max-age-parametern för Strict-Transport-Security-huvudet till 60 dagar. Om den inte har angetts är standardvärdet 30 dagar. Mer information finns i maxåldersdirektivet.
• Lägger till example.com i listan över värdar som ska undantas.

UseHsts exkluderar följande loopback-värdar:

• localhost : IPv4-loopback-adressen.
• 127.0.0.1 : IPv4-loopback-adressen.
• [::1] : IPv6-loopback-adressen.

Välj bort HTTPS/HSTS vid skapande av projekt

I vissa scenarier med serverdelstjänst där anslutningssäkerhet hanteras på nätverkets offentliga kant krävs inte konfigurering av anslutningssäkerhet vid varje nod. Webbappar som genereras från mallarna i Visual Studio eller från kommandot dotnet new möjliggör HTTPS-omdirigering och HSTS. För distributioner som inte kräver dessa scenarier kan du välja bort HTTPS/HSTS när appen skapas från mallen.

Så här väljer du bort HTTPS/HSTS:

dotnet new webapp --no-https

Lita på https-utvecklingscertifikatet för ASP.NET Core

.NET Core SDK innehåller ett HTTPS-utvecklingscertifikat. Certifikatet installeras som en del av den första användarupplevelsen. Till exempel ger dotnet --info en variant av följande utdata:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

När du installerar .NET Core SDK installeras ASP.NET Core HTTPS-utvecklingscertifikatet i det lokala användarcertifikatarkivet. Certifikatet har installerats, men det är inte pålitligt. Om du vill lita på certifikatet utför du engångssteget för att köra verktyget dotnet dev-certs:

dotnet dev-certs https --trust

Följande kommando innehåller hjälp om verktyget dotnet dev-certs:

dotnet dev-certs https --help

Så här konfigurerar du ett utvecklarcertifikat för Docker

Se det här GitHub-problemet.

Linux-specifika överväganden

Linux-distributioner skiljer sig avsevärt åt i hur de markerar certifikat som betrodda. Även om dotnet dev-certs förväntas vara allmänt tillämpligt stöds det endast officiellt på Ubuntu och Fedora och syftar specifikt till att säkerställa förtroende för Firefox och Chromium-baserade webbläsare (Edge, Chrome och Chromium).

Beroenden

För att upprätta OpenSSL-förtroende måste verktyget openssl finnas på sökvägen.

För att upprätta webbläsarförtroende (till exempel i Edge eller Firefox) måste verktyget certutil vara på sökvägen.

OpenSSL-förtroende

När ASP.NET Core-utvecklingscertifikatet är betrott exporteras det till en mapp i den aktuella användarens hemkatalog. Om du vill att OpenSSL- (och klienter som använder den) ska kunna hämta den här mappen måste du ange SSL_CERT_DIR miljövariabeln. Du kan antingen göra detta i en enda session genom att köra ett kommando som export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (det exakta värdet finns i utdata när --verbose skickas) eller genom att lägga till den din (distributions- och gränssnittsspecifika) konfigurationsfil (till exempel .profile).

Detta krävs för att göra verktyg som curl lita på utvecklingscertifikatet. Alternativt kan du skicka -CAfile eller -CApath till varje enskilt curl-anrop.

Observera att detta kräver 1.1.1h eller senare eller 3.0.0 eller senare, beroende på vilken huvudversion du använder.

Om OpenSSL-förtroende hamnar i ett felaktigt tillstånd (till exempel om dotnet dev-certs https --clean inte kan ta bort det) är det ofta möjligt att ställa in rätt saker med hjälp av verktyget c_rehash.

Åsidosätter

Om du använder en annan webbläsare med ett eget NSS-arkiv (Network Security Services) kan du använda miljövariabeln DOTNET_DEV_CERTS_NSSDB_PATHS för att ange en kolonavgränsad lista över NSS-kataloger (till exempel katalogen som innehåller cert9.db) för att lägga till utvecklingscertifikatet.

Om du lagrar certifikaten som du vill att OpenSSL ska lita på i en specifik katalog kan du använda miljövariabeln DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY för att ange var det finns.

Användning av sudo

Precis som på andra plattformar lagras och betrods utvecklingscertifikat separat för varje användare. Om du kör dotnet dev-certs som en annan användare (till exempel med hjälp av sudo), är det i så fall som användare (till exempel root) som kommer att lita på utvecklingscertifikatet.

Lita på HTTPS-certifikat i Linux med linux-dev-certs

linux-dev-certs är ett globalt .NET-verktyg med öppen källkod som stöds av communityn och som är ett bekvämt sätt att skapa och lita på ett utvecklarcertifikat på Linux. Verktyget underhålls inte eller stöds inte av Microsoft.

Följande kommandon installerar verktyget och skapar ett betrott utvecklarcertifikat:

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

Mer information eller rapportera problem finns i gitHub-lagringsplatsen linux-dev-certs.

Felsöka problem med certifikat såsom att certifikatet är misstrott

Det här avsnittet innehåller hjälp när ASP.NET Core HTTPS-utvecklingscertifikatet har installerats och betrotts, men du fortfarande har webbläsarvarningar om att certifikatet inte är betrott. ASP.NET Core HTTPS-utvecklingscertifikatet används av Kestrel.

Information om hur du reparerar IIS Express-certifikatet finns i det här Stackoverflow-problemet.

Alla plattformar – certifikatet är inte betrott

Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen. Certifikatförtroendet lagras i cache av webbläsare.

dotnet dev-certs https --clean Misslyckas

De föregående kommandona löser de flesta problem med webbläsarförtroende. Om webbläsaren fortfarande inte litar på certifikatet följer du de plattformsspecifika förslag som följer.

Docker – certifikatet är inte betrott

• Ta bort mappen C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Rensa lösningen. Ta bort bin och obj mappar.
• Starta om utvecklingsverktyg. Till exempel Visual Studio eller Visual Studio Code.

Windows – certifikatet är inte betrott

• Kontrollera certifikaten i certifikatarkivet. Det bör finnas ett localhost certifikat med det ASP.NET Core HTTPS development certificate vänliga namnet både under Current User > Personal > Certificates och Current User > Trusted root certification authorities > Certificates
• Ta bort alla hittade certifikat från både Personliga och Betrodda rotcertifikatmyndigheter. Ta inte bort IIS Express localhost-certifikatet.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen.

OS X – certifikatet är inte betrott

• Öppna Nyckelringsåtkomst.
• Välj systemnyckelringen.
• Kontrollera om det finns ett localhost-certifikat.
• Kontrollera att den innehåller en + symbol på ikonen för att ange att den är betrodd för alla användare.
• Ta bort certifikatet från systemnyckelringen.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen.

Se HTTPS-fel med IIS Express (dotnet/AspNetCore #16892) för felsökning av certifikatproblem med Visual Studio.

Linux-certifikatet är inte betrott

Kontrollera att certifikatet som konfigureras för förtroende är användarens HTTPS-utvecklarcertifikat som ska användas av Kestrel-servern.

Kontrollera den aktuella användarens standardcertifikat för HTTPS-utvecklare Kestrel på följande plats:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

HTTPS-utvecklarcertifikatfilen Kestrel är SHA1-fingeravtrycket. När filen tas bort via dotnet dev-certs https --cleanåterskapas den när det behövs med ett annat tumavtryck. Kontrollera att tumavtrycket för det exporterade certifikatet stämmer överens med följande kommando:

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Om certifikatet inte matchar kan det vara något av följande:

• Ett gammalt certifikat.
• Ett exporterat utvecklarcertifikat för rotanvändaren. I det här fallet exporterar du certifikatet.

Rotanvändarcertifikatet kan kontrolleras på:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

IIS Express SSL-certifikat som används med Visual Studio

Om du vill åtgärda problem med IIS Express-certifikatet väljer du Reparera från Installationsprogrammet för Visual Studio. Mer information finns i det här GitHub-ärendet.

Grupprincip förhindrar att självsignerade certifikat är betrodda

I vissa fall kan grupprincip förhindra att självsignerade certifikat är betrodda. Mer information finns i det här GitHub-ärendet.

Ytterligare information

• Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare
• Värd för ASP.NET Core i Linux med Nginx: HTTPS-konfiguration
• Konfigurera SSL på IIS-
• Konfigurera slutpunkter för webbservern ASP.NET Core Kestrel
• OWASP HSTS-webbläsarstöd

HTTP-omdirigering till HTTPS orsakar ERR_INVALID_REDIRECT på CORS-förfrågan inför preflight-begäran.

Begäranden till en endpunkt med HTTP som omdirigeras till HTTPS av UseHttpsRedirection misslyckas med ERR_INVALID_REDIRECT på CORS-preflight-begäran.

API-projekt kan avvisa HTTP-begäranden i stället för att använda UseHttpsRedirection för att omdirigera begäranden till HTTPS.

Kräv HTTPS

Vi rekommenderar att ASP.NET Core-webbappar i produktion använder:

• HTTPS Redirection Middleware (UseHttpsRedirection) för att omdirigera HTTP-begäranden till HTTPS.
• HSTS Middleware (UseHsts) för att skicka HSTS-huvuden (HTTP Strict Transport Security Protocol) till klienter.

UseHttpsRedirection

Följande kod anropar UseHttpsRedirection i filen Program.cs:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Föregående markerade kod:

• Använder standardvärdet HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Använder standardvärdet HttpsRedirectionOptions.HttpsPort (null) om det inte åsidosätts av miljövariabeln ASPNETCORE_HTTPS_PORT eller IServerAddressesFeature.

Vi rekommenderar att du använder tillfälliga omdirigeringar i stället för permanenta omdirigeringar. Länkcachelagring kan orsaka instabilt beteende i utvecklingsmiljöer. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen finns i en miljö som inte är utvecklingsmiljö kan du läsa avsnittet Konfigurera permanenta omdirigeringar i produktion. Vi rekommenderar att du använder HSTS- för att signalera till klienter att endast säkra resursbegäranden ska skickas till appen (endast i produktion).

Portkonfiguration

En port måste vara tillgänglig för mellanprogrammet för att omdirigera en osäker begäran till HTTPS. Om ingen port är tillgänglig:

• Omdirigering till HTTPS sker inte.
• Mellanprogrammet loggar varningen "Det gick inte att fastställa https-porten för omdirigering".

Ange HTTPS-porten med någon av följande metoder:

• Ange HttpsRedirectionOptions.HttpsPort.

• Ange värdinställningen https_port:

  • I värdkonfiguration.

  • Genom att ange miljövariabeln ASPNETCORE_HTTPS_PORT.

  • Genom att lägga till en post på den översta nivån i appsettings.json:

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• Ange en port med det säkra schemat med hjälp av ASPNETCORE_URLS miljövariabeln. Miljövariabeln konfigurerar servern. Mellanprogrammet identifierar indirekt HTTPS-porten via IServerAddressesFeature. Den här metoden fungerar inte i distributioner med omvänd proxy.

• Webbmallarna ASP.NET Core anger en HTTPS-URL i Properties/launchsettings.json för både Kestrel och IIS Express. launchsettings.json används endast på den lokala datorn.

• Konfigurera en HTTPS-URL-slutpunkt för en offentlig edge-distribution av Kestrel server eller HTTP.sys server. Endast en HTTPS-port används av appen. Mellanprogrammet identifierar porten via IServerAddressesFeature.

Edge-distributioner

När Kestrel eller HTTP.sys används som en offentlig edge-server måste Kestrel eller HTTP.sys konfigureras för att lyssna på båda:

• Den säkra port där klienten omdirigeras (vanligtvis 443 i produktion och 5001 under utveckling).
• Den osäkra porten (vanligtvis 80 i produktion och 5 000 under utveckling).

Den osäkra porten måste vara tillgänglig för klienten för att appen ska kunna ta emot en osäker begäran och omdirigera klienten till den säkra porten.

Mer information finns i Kestrel slutpunktskonfiguration eller HTTP.sys webbserverimplementering i ASP.NET Core.

Distributionsscenarier

Alla brandväggar mellan klienten och servern måste också ha kommunikationsportar öppna för trafik.

Om begäranden vidarebefordras i en konfiguration med omvänd proxy, använder du Middleware för vidarebefordrade rubriker innan du använder HTTPS-omdirigeringsmellanprogramvara. Vidarebefordrade rubriker-mellanprogrammet uppdaterar Request.Schememed hjälp av X-Forwarded-Proto-rubriken. Mellanprogrammet tillåter att omdirigerings-URI:er och andra säkerhetsprinciper fungerar korrekt. När Mellanprogram för vidarebefordrade huvuden inte används kanske serverdelsappen inte får rätt schema och hamnar i en omdirigeringsloop. Ett vanligt felmeddelande från slutanvändaren är att för många omdirigeringar har inträffat.

När du distribuerar till Azure App Service följer du anvisningarna i Självstudie: Binda ett befintligt anpassat SSL-certifikat till Azure Web Apps.

Alternativ

Följande markerade kod anropar AddHttpsRedirection för att konfigurera mellanprogramsalternativ:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Det är bara nödvändigt att anropa AddHttpsRedirection för att ändra värdena för HttpsPort eller RedirectStatusCode.

Föregående markerade kod:

• Anger HttpsRedirectionOptions.RedirectStatusCode till Status307TemporaryRedirect, vilket är standardvärdet. Använd fälten i klassen StatusCodes för tilldelningar till RedirectStatusCode.
• Anger HTTPS-porten till 5001.

Konfigurera permanenta omdirigeringar i produktion

Mellanprogrammet skickar som standard en Status307TemporaryRedirect med alla omdirigeringar. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen är i en icke-utvecklingsmiljö, omsluter du konfigurationen av middleware-alternativen i en villkorlig kontroll för en miljö som inte är en utvecklingsmiljö.

När du konfigurerar tjänster i Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Alternativa metoder för HTTPS-omdirigeringsmiddleware

Ett alternativ till att använda HTTPS Redirection Middleware (UseHttpsRedirection) är att använda URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps kan också ange statuskod och port när omdirigeringen körs. Mer information finns i URL-omskrivningsmiddleware.

När du omdirigerar till HTTPS utan krav på ytterligare omdirigeringsregler rekommenderar vi att du använder HTTPS Redirection Middleware (UseHttpsRedirection) som beskrivs i den här artikeln.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HTTP Strict Transport Security (HSTS) är en alternativ säkerhetsförbättring som anges av en webbapp med hjälp av ett svarshuvud. När en webbläsare som stöder HSTS tar emot den här rubriken:

• Webbläsaren lagrar konfigurationen för domänen som förhindrar att någon kommunikation skickas via HTTP. Webbläsaren tvingar all kommunikation över HTTPS.
• Webbläsaren hindrar användaren från att använda ej betrodda eller ogiltiga certifikat. Webbläsaren inaktiverar uppmaningar som gör att en användare tillfälligt kan lita på ett sådant certifikat.

Eftersom HSTS- tillämpas av klienten har den vissa begränsningar:

• Klienten måste ha stöd för HSTS.
• HSTS kräver minst en lyckad HTTPS-begäran för att upprätta HSTS-principen.
• Programmet måste kontrollera varje HTTP-begäran och omdirigera eller avvisa HTTP-begäran.

ASP.NET Core implementerar HSTS med UseHsts-tilläggsmetoden. Följande kod anropar UseHsts när appen inte är i utvecklingsläge:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts rekommenderas inte under utveckling eftersom HSTS-inställningarna är mycket cachelagrade av webbläsare. Som standard utesluter UseHsts den lokala loopback-adressen.

För produktionsmiljöer som implementerar HTTPS för första gången anger du den första HstsOptions.MaxAge till ett litet värde med någon av de TimeSpan metoderna. Ange värdet från timmar till högst en enda dag om du behöver återställa HTTPS-infrastrukturen till HTTP. När du är säker på hållbarheten i HTTPS-konfigurationen ökar du värdet för HSTS-max-age. ett vanligt värde är ett år.

Följande markerade kod:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• Anger förinläsningsparametern för Strict-Transport-Security-huvudet. Förinläsning är inte en del av RFC HSTS-specifikationen, men stöds av webbläsare för att förinstallera HSTS-webbplatser vid ny installation. Mer information finns i https://hstspreload.org/.
• Aktiverar includeSubDomain, som tillämpar HSTS-principen på värdunderdomäner.
• Anger uttryckligen max-age-parametern för Strict-Transport-Security-huvudet till 60 dagar. Om den inte har angetts är standardvärdet 30 dagar. Mer information finns i maxåldersdirektivet.
• Lägger till example.com i listan över värdar som ska undantas.

UseHsts exkluderar följande loopback-värdar:

• localhost : IPv4-loopback-adressen.
• 127.0.0.1 : IPv4-loopback-adressen.
• [::1] : IPv6-loopback-adressen.

Välj bort HTTPS/HSTS under projektskapande

I vissa scenarier med serverdelstjänst där anslutningssäkerhet hanteras på nätverkets offentliga kant krävs inte konfigurering av anslutningssäkerhet vid varje nod. Webbappar som genereras från mallarna i Visual Studio eller från kommandot dotnet new möjliggör HTTPS-omdirigering och HSTS. För distributioner som inte kräver dessa scenarier kan du välja bort HTTPS/HSTS när appen skapas från mallen.

Så här väljer du bort HTTPS/HSTS:

dotnet new webapp --no-https

Lita på https-utvecklingscertifikatet för ASP.NET Core i Windows och macOS

För webbläsaren Firefox, se nästa avsnitt.

.NET Core SDK innehåller ett HTTPS-utvecklingscertifikat. Certifikatet installeras som en del av den första gångs upplevelsen. Till exempel ger dotnet --info en variant av följande utdata:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

När du installerar .NET Core SDK installeras ASP.NET Core HTTPS-utvecklingscertifikatet i det lokala användarcertifikatarkivet. Certifikatet har installerats, men det är inte betrott. Om du vill lita på certifikatet utför du engångssteget för att köra verktyget dotnet dev-certs:

dotnet dev-certs https --trust

Följande kommando innehåller hjälp om verktyget dotnet dev-certs:

dotnet dev-certs https --help

Lita på HTTPS-certifikatet med Firefox för att förhindra SEC_ERROR_INADEQUATE_KEY_USAGE fel

Webbläsaren Firefox använder ett eget certifikatarkiv och litar därför inte på IIS Express- eller Kestrel utvecklarcertifikat.

Det finns två sätt att lita på HTTPS-certifikatet med Firefox, skapa en principfil eller konfigurera med FireFox-webbläsaren. När du konfigurerar med webbläsaren skapas principfilen, så de två metoderna är likvärdiga.

Skapa en principfil för att lita på HTTPS-certifikat med Firefox

Skapa en principfil (policies.json) på:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: Se Lita på certifikatet med Firefox på Linux i den här artikeln.

Lägg till följande JSON i Firefox-principfilen:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Den föregående policyfilen gör att Firefox litar på certifikat från de betrodda certifikaten i certifikatsförrådet i Windows. Nästa avsnitt innehåller en alternativ metod för att skapa föregående principfil med hjälp av webbläsaren Firefox.

Konfigurera förtroende för HTTPS-certifikat med webbläsaren Firefox

Ange security.enterprise_roots.enabled = true med hjälp av följande instruktioner:

1. Ange about:config i FireFox-webbläsaren.
2. Välj Acceptera risken och fortsätt om du accepterar risken.
3. Välj Visa alla
4. Ange security.enterprise_roots.enabled = true
5. Avsluta och starta om Firefox

Mer information finns i Konfigurera certifikatutfärdare (CA) i Firefox och filen mozilla/policy-templates/README.

Så här konfigurerar du ett utvecklarcertifikat för Docker

Se det här GitHub-problemet.

Lita på HTTPS-certifikat i Linux

Att upprätta förtroende är distributions- och webbläsarspecifikt. Följande avsnitt innehåller instruktioner för några populära distributioner och Chromium-webbläsare (Edge och Chrome) och för Firefox.

Ubuntu litar på certifikatet för tjänst-till-tjänst-kommunikation

Följande instruktioner fungerar inte för vissa Ubuntu-versioner, till exempel 20.04. Mer information finns i GitHub-problem dotnet/AspNetCore.Docs #23686.

1. Installera OpenSSL 1.1.1h eller senare. Se distributionen för instruktioner om hur du uppdaterar OpenSSL.

2. Kör följande kommandon:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

Föregående kommandon:

• Kontrollera att den aktuella användarens utvecklarcertifikat har skapats.
• Exporterar certifikatet med utökade behörigheter som krävs för mappen ca-certificates med hjälp av den aktuella användarens miljö.
• Att ta bort -E-flaggan exporterar rotcertifikatet för användare, och genererar det vid behov. Varje nyligen genererat certifikat har olika tumavtryck. När du kör som root-användare behövs inte sudo och -E.

Sökvägen i föregående kommando är specifik för Ubuntu. För andra distributioner väljer du en lämplig sökväg eller använder sökvägen för certifikatutfärdare (CA).

Lita på HTTPS-certifikat i Linux med Edge eller Chrome

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

dnf install nss-tools

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Lita på certifikatet med Fedora 34

Se:

• Den här GitHub-kommentaren
• Fedora: Använda delade systemcertifikat
• Konfigurera en .NET-utvecklingsmiljö på Fedora.

Lita på certifikatet med andra distributioner

Se det här GitHub-problemet.

Lita på HTTPS-certifikat från Windows-undersystem för Linux

Följande instruktioner fungerar inte för vissa Linux-distributioner, till exempel Ubuntu 20.04. Mer information finns i GitHub-problem dotnet/AspNetCore.Docs #23686.

Windows-undersystem för Linux (WSL) genererar ett SJÄLVsignerat HTTPS-utvecklingscertifikat som som standard inte är betrott i Windows. Det enklaste sättet att låta Windows lita på WSL-certifikatet är att konfigurera WSL att använda samma certifikat som Windows:

• Exportera utvecklarcertifikatet till en fil på Windows:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  Där $CREDENTIAL_PLACEHOLDER$ är ett lösenord.

• I ett WSL-fönster importerar du det exporterade certifikatet på WSL-instansen:

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

Föregående metod är en engångsåtgärd per certifikat och per WSL-distribution. Det är enklare än att exportera certifikatet om och om. Om du uppdaterar eller återskapar certifikatet i windows kan du behöva köra föregående kommandon igen.

Felsöka certifikatproblem som att certifikatet inte är betrodda

Det här avsnittet innehåller hjälp när ASP.NET Core HTTPS-utvecklingscertifikatet har installerats och betrotts, men du fortfarande har webbläsarvarningar om att certifikatet inte är betrott. ASP.NET Core HTTPS-utvecklingscertifikatet används av Kestrel.

Se den här Stackoverflow-frågan för hur du reparerar IIS Express-certifikatet.

Alla plattformar – certifikatet är inte pålitligt

Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen. Tilliten till certifikatet cachelagras av webbläsare.

dotnet dev-certs https --clean misslyckades

De föregående kommandona löser de flesta problem med webbläsarförtroende. Om webbläsaren fortfarande inte litar på certifikatet följer du de plattformsspecifika förslag som följer.

Docker – certifikatet kan inte litas på

• Ta bort mappen C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Rensa lösningen. Ta bort bin och obj mappar.
• Starta om utvecklingsverktyg. Till exempel Visual Studio eller Visual Studio Code.

Windows – certifikatet är inte betrott

• Kontrollera certifikaten i certifikatarkivet. Det bör finnas ett localhost-certifikat med det ASP.NET Core HTTPS development certificate vänliga namnet både under Current User > Personal > Certificates och Current User > Trusted root certification authorities > Certificates
• Ta bort alla hittade certifikat från både personliga och betrodda rotcertifikatmyndigheter. Ta inte bort IIS Express localhost-certifikatet.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen.

OS X – certifikatet är inte betrott

• Öppna Nyckelringsåtkomst.
• Välj systemnyckelringen.
• Kontrollera om det finns ett localhost-certifikat.
• Kontrollera att den innehåller en + symbol på ikonen för att ange att den är betrodd för alla användare.
• Ta bort certifikatet från systemnyckelringen.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen.

Se HTTPS-fel med IIS Express (dotnet/AspNetCore #16892) för felsökning av certifikatproblem med Visual Studio.

Linux-certifikatet är inte tillförlitligt

Kontrollera att certifikatet som konfigureras för förtroende är användarens HTTPS-utvecklarcertifikat som ska användas av Kestrel-servern.

Kontrollera den aktuella användarens standardcertifikat för HTTPS-utvecklare Kestrel på följande plats:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

HTTPS-utvecklaren Kestrel:s certifikatfil är SHA1-fingeravtrycket. När filen tas bort via dotnet dev-certs https --cleanåterskapas den när det behövs med ett annat tumavtryck. Kontrollera tumavtrycket för det exporterade certifikatet med följande kommando:

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Om certifikatet inte matchar kan det vara något av följande:

• Ett gammalt certifikat.
• Ett exporterat utvecklarcertifikat för rotanvändaren. I det här fallet exporterar du certifikatet.

Rotanvändarcertifikatet kan kontrolleras på:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

IIS Express SSL-certifikat som används med Visual Studio

Om du vill åtgärda problem med IIS Express-certifikatet väljer du Reparera från Installationsprogrammet för Visual Studio. Mer information finns i det här GitHub-ärendet.

Grupprincip förhindrar att självsignerade certifikat är betrodda

I vissa fall kan grupprincip förhindra att självsignerade certifikat är betrodda. Mer information finns i det här GitHub-problemet.

Ytterligare information

• Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare
• Värd för ASP.NET Core i Linux med Nginx: HTTPS-konfiguration
• Konfigurera SSL på IIS-
• Konfigurera slutpunkter för webbservern ASP.NET Core Kestrel
• OWASP HSTS-webbläsarstöd

Kräv HTTPS

Vi rekommenderar att produktions ASP.NET Core webbappar använder:

• HTTPS Redirection Middleware (UseHttpsRedirection) för att omdirigera HTTP-begäranden till HTTPS.
• HSTS Middleware (UseHsts) för att skicka HSTS-huvuden (HTTP Strict Transport Security Protocol) till klienter.

UseHttpsRedirection

Följande kod anropar UseHttpsRedirection i klassen Startup:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

Föregående markerade kod:

• Använder standardvärdet HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Använder standardvärdet HttpsRedirectionOptions.HttpsPort (null) om det inte åsidosätts av miljövariabeln ASPNETCORE_HTTPS_PORT eller IServerAddressesFeature.

Vi rekommenderar att du använder tillfälliga omdirigeringar i stället för permanenta omdirigeringar. Länkcachelagring kan orsaka instabilt beteende i utvecklingsmiljöer. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen finns i en miljö som inte är utvecklingsmiljö kan du läsa avsnittet Konfigurera permanenta omdirigeringar i produktion. Vi rekommenderar att du använder HSTS- för att signalera till klienter att endast säkra resursbegäranden ska skickas till appen (endast i produktion).

Portkonfiguration

En port måste vara tillgänglig för mellanprogrammet för att omdirigera en osäker begäran till HTTPS. Om ingen port är tillgänglig:

• Omdirigering till HTTPS sker inte.
• Mellanprogrammet loggar varningen "Det gick inte att fastställa https-porten för omdirigering".

Ange HTTPS-porten med någon av följande metoder:

• Ange HttpsRedirectionOptions.HttpsPort.

• Ange värdinställningen https_port:

  • I värdkonfiguration.

  • Genom att ange miljövariabeln ASPNETCORE_HTTPS_PORT.

  • Genom att lägga till en post på den översta nivån i appsettings.json:

    {
        "https_port": 443,
        "Logging": {
            "LogLevel": {
                "Default": "Information",
                "Microsoft": "Warning",
                "Microsoft.Hosting.Lifetime": "Information"
            }
        },
        "AllowedHosts": "*"
    }
    

• Ange en port med det säkra schemat med hjälp av ASPNETCORE_URLS miljövariabeln. Miljövariabeln konfigurerar servern. Mellanprogrammet identifierar indirekt HTTPS-porten via IServerAddressesFeature. Den här metoden fungerar inte i distributioner med omvänd proxy.

• Under utvecklingsfasen anger du en HTTPS-URL i launchsettings.json. Aktivera HTTPS när IIS Express används.

• Konfigurera en HTTPS-URL-slutpunkt för en offentlig edge-distribution av Kestrel server eller HTTP.sys server. Endast en HTTPS-port används av appen. Mellanprogrammet identifierar porten via IServerAddressesFeature.

Edge-utplaceringar

När Kestrel eller HTTP.sys används som en offentlig edge-server måste Kestrel eller HTTP.sys konfigureras för att lyssna på båda:

• Den säkra port där klienten omdirigeras (vanligtvis 443 i produktion och 5001 under utveckling).
• Den osäkra porten (vanligtvis 80 i produktion och 5 000 under utveckling).

Den osäkra porten måste vara tillgänglig för klienten för att appen ska kunna ta emot en osäker begäran och omdirigera klienten till den säkra porten.

Mer information finns i Kestrel slutpunktskonfiguration eller HTTP.sys webbserverimplementering i ASP.NET Core.

Distributionsscenarier

Alla brandväggar mellan klienten och servern måste också ha kommunikationsportar öppna för trafik.

Om begäranden vidarebefordras i en konfiguration med omvänd proxy ska du använda mellanmjukvara för vidarebefordrade rubriker innan du anropar HTTPS Omdirigerings Middleware. Mellanprogram för vidarebefordrade rubriker uppdaterar Request.Schememed hjälp av X-Forwarded-Proto-huvudet. Mellanprogrammet tillåter att omdirigerings-URI:er och andra säkerhetsprinciper fungerar korrekt. När Mellanprogram för vidarebefordrade huvuden inte används kanske serverdelsappen inte får rätt schema och hamnar i en omdirigeringsloop. Ett vanligt felmeddelande från slutanvändaren är att för många omdirigeringar har inträffat.

När du distribuerar till Azure App Service följer du anvisningarna i Självstudie: Binda ett befintligt anpassat SSL-certifikat till Azure Web Apps.

Alternativ

Följande markerade kod anropar AddHttpsRedirection för att konfigurera mellanprogramsalternativ:

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();

    services.AddHsts(options =>
    {
        options.Preload = true;
        options.IncludeSubDomains = true;
        options.MaxAge = TimeSpan.FromDays(60);
        options.ExcludedHosts.Add("example.com");
        options.ExcludedHosts.Add("www.example.com");
    });

    services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
        options.HttpsPort = 5001;
    });
}

Det är bara nödvändigt att anropa AddHttpsRedirection för att ändra värdena för HttpsPort eller RedirectStatusCode.

Föregående markerade kod:

• Anger HttpsRedirectionOptions.RedirectStatusCode till Status307TemporaryRedirect, vilket är standardvärdet. Använd fälten i klassen StatusCodes för tilldelningar till RedirectStatusCode.
• Anger HTTPS-porten till 5001.

Konfigurera permanenta omdirigeringar i produktion

Mellanprogrammet skickar som standard en Status307TemporaryRedirect med alla omdirigeringar. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen är i en icke-utvecklingsmiljö, omsluter du konfigurationen av mellanprogramsalternativen i en villkorlig kontroll för en miljö som inte är utvecklingsmiljö.

När du konfigurerar tjänster i Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    // IWebHostEnvironment (stored in _env) is injected into the Startup class.
    if (!_env.IsDevelopment())
    {
        services.AddHttpsRedirection(options =>
        {
            options.RedirectStatusCode = (int) HttpStatusCode.PermanentRedirect;
            options.HttpsPort = 443;
        });
    }
}

Alternativ metod för HTTPS-omdirigeringsmiddleware

Ett alternativ till att använda HTTPS Redirection Middleware (UseHttpsRedirection) är att använda URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps kan också ange statuskod och port när omdirigeringen körs. Mer information finns i URL-omskrivnings-mellanvara.

När du omdirigerar till HTTPS utan krav på ytterligare omdirigeringsregler rekommenderar vi att du använder HTTPS Redirection Middleware (UseHttpsRedirection) som beskrivs i den här artikeln.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HTTP Strict Transport Security (HSTS) är en frivillig säkerhetsförbättring som anges av en webbapplikation med hjälp av ett svarshuvud. När en webbläsare som stöder HSTS tar emot denna header:

• Webbläsaren lagrar konfigurationen för domänen som förhindrar att någon kommunikation skickas via HTTP. Webbläsaren tvingar all kommunikationen över HTTPS.
• Webbläsaren hindrar användaren från att använda ej betrodda eller ogiltiga certifikat. Webbläsaren inaktiverar uppmaningar som gör att en användare tillfälligt kan lita på ett sådant certifikat.

Eftersom HSTS tillämpas av klienten har den vissa begränsningar:

• Klienten måste ha stöd för HSTS.
• HSTS kräver minst en lyckad HTTPS-begäran för att upprätta HSTS-principen.
• Programmet måste kontrollera varje HTTP-begäran och omdirigera eller avvisa HTTP-begäran.

ASP.NET Core implementerar HSTS med UseHsts-tilläggsmetoden. Följande kod anropar UseHsts när appen inte är i utvecklingsläge:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

UseHsts rekommenderas inte under utveckling eftersom HSTS-inställningarna är mycket cachelagrade av webbläsare. Som standard utesluter UseHsts den lokala loopback-adressen.

För produktionsmiljöer som implementerar HTTPS för första gången anger du den första HstsOptions.MaxAge till ett litet värde med någon av de TimeSpan metoderna. Ange värdet från timmar till högst en enda dag om du behöver återställa HTTPS-infrastrukturen till HTTP. När du är säker på hållbarheten i HTTPS-konfigurationen ökar du värdet för HSTS-max-age. ett vanligt värde är ett år.

Följande kod:

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();

    services.AddHsts(options =>
    {
        options.Preload = true;
        options.IncludeSubDomains = true;
        options.MaxAge = TimeSpan.FromDays(60);
        options.ExcludedHosts.Add("example.com");
        options.ExcludedHosts.Add("www.example.com");
    });

    services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
        options.HttpsPort = 5001;
    });
}

• Anger förinläsningsparametern för Strict-Transport-Security-huvudet. Förinläsning är inte en del av RFC HSTS-specifikationen, men stöds av webbläsare för att förinstallera HSTS-webbplatser vid ny installation. Mer information finns i https://hstspreload.org/.
• Aktiverar includeSubDomain, som tillämpar HSTS-principen på värdunderdomäner.
• Anger uttryckligen max-age-parametern för Strict-Transport-Security-huvudet till 60 dagar. Om den inte har angetts är standardvärdet 30 dagar. Mer information finns i maxåldersdirektivet.
• Lägger till example.com i listan över värdar som ska undantas.

UseHsts exkluderar följande loopback-värdar:

• localhost : IPv4-loopback-adressen.
• 127.0.0.1 : IPv4-loopback-adressen.
• [::1] : IPv6-loopback-adressen.

Välj bort HTTPS/HSTS vid projektskapande

I vissa scenarier med serverdelstjänst där anslutningssäkerhet hanteras på nätverkets offentliga kant krävs inte konfigurering av anslutningssäkerhet vid varje nod. Webbappar som genereras från mallarna i Visual Studio eller från kommandot dotnet new möjliggör HTTPS-omdirigering och HSTS. För distributioner som inte kräver dessa scenarier kan du välja bort HTTPS/HSTS när appen skapas från mallen.

Så här väljer du bort HTTPS/HSTS:

dotnet new webapp --no-https

Lita på https-utvecklingscertifikatet för ASP.NET Core i Windows och macOS

För webbläsaren Firefox, se nästa avsnitt.

.NET Core SDK innehåller ett HTTPS-utvecklingscertifikat. Certifikatet installeras som en del av den första användarupplevelsen. Om du till exempel kör dotnet new webapp för första gången genereras en variant av följande utdata:

Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https

När du installerar .NET Core SDK installeras ASP.NET Core HTTPS-utvecklingscertifikatet i det lokala användarcertifikatarkivet. Certifikatet har installerats, men det är inte betrodd. Om du vill lita på certifikatet utför du engångssteget för att köra verktyget dotnet dev-certs:

dotnet dev-certs https --trust

Följande kommando innehåller hjälp om verktyget dotnet dev-certs:

dotnet dev-certs https --help

Lita på HTTPS-certifikatet med Firefox för att förhindra SEC_ERROR_INADEQUATE_KEY_USAGE fel

Webbläsaren Firefox använder ett eget certifikatarkiv och litar därför inte på IIS Express- eller Kestrel utvecklarcertifikat.

Det finns två sätt att lita på HTTPS-certifikatet med Firefox, skapa en principfil eller konfigurera med FireFox-webbläsaren. När du konfigurerar med webbläsaren skapas principfilen, så de två metoderna är likvärdiga.

Skapa en principfil för att lita på HTTPS-certifikat med Firefox

Skapa en principfil (policies.json) på:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: Se Lita på certifikatet med Firefox på Linux senare i den här artikeln.

Lägg till följande JSON i Firefox-principfilen:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Den föregående policyfilen gör att Firefox litar på certifikat från de betrodda certifikaten i Windows certifikatlager. Nästa avsnitt innehåller en alternativ metod för att skapa föregående principfil med hjälp av webbläsaren Firefox.

Konfigurera förtroende för HTTPS-certifikat med webbläsaren Firefox

Ange security.enterprise_roots.enabled = true med hjälp av följande instruktioner:

1. Ange about:config i FireFox-webbläsaren.
2. Välj Acceptera risken och fortsätt om du accepterar risken.
3. Välj Visa alla.
4. Ange security.enterprise_roots.enabled = true.
5. Avsluta och starta om Firefox.

Mer information finns i Konfigurera certifikatutfärdare (CA) i Firefox och filen mozilla/policy-templates/README.

Så här konfigurerar du ett utvecklarcertifikat för Docker

Se det här GitHub-problemet.

Lita på HTTPS-certifikat i Linux

Att upprätta förtroende är distributions- och webbläsarspecifikt. Följande avsnitt innehåller instruktioner för några populära distributioner och Chromium-webbläsare (Edge och Chrome) och för Firefox.

Ubuntu litar på certifikatet för tjänst-till-tjänst-kommunikation

1. Installera OpenSSL 1.1.1h eller senare. Se distributionen för instruktioner om hur du uppdaterar OpenSSL.

2. Kör följande kommandon:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

Föregående kommandon:

• Kontrollera att den aktuella användarens utvecklarcertifikat har skapats.
• Exportera certifikatet med utökade behörigheter som krävs för ca-certificates-mappen med hjälp av den aktuella användarens miljö.
• Ta bort flaggan -E för att exportera rotanvändarcertifikatet och generera det om det behövs. Varje nyligen genererat certifikat har olika tumavtryck. När du kör som root-användare behövs inte sudo och -E.

Sökvägen i föregående kommando är specifik för Ubuntu. För andra distributioner väljer du en lämplig sökväg eller använder sökvägen för certifikatutfärdare (CA).

Lita på HTTPS-certifikat i Linux med Edge eller Chrome

För chromium-webbläsare i Linux:

• Installera libnss3-tools för distributionen.

• Skapa eller kontrollera att mappen $HOME/.pki/nssdb finns på datorn.

• Exportera certifikatet med följande kommando:

  dotnet dev-certs https
  sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
  

  Sökvägen i föregående kommando är specifik för Ubuntu. För andra distributioner väljer du en lämplig sökväg eller använder sökvägen för certifikatutfärdare (CA).

• Kör följande kommandon:

  certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
  

• Avsluta och starta om webbläsaren.

Lita på certifikatet med Firefox på Linux

• Exportera certifikatet med följande kommando:

  dotnet dev-certs https
  sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
  

  Sökvägen i föregående kommando är specifik för Ubuntu. För andra distributioner väljer du en lämplig sökväg eller använder sökvägen för certifikatutfärdare (CA).

• Skapa en JSON-fil på /usr/lib/firefox/distribution/policies.json med följande innehåll:

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

Se Konfigurera förtroende för HTTPS-certifikat med webbläsaren Firefox i den här artikeln för ett alternativt sätt att konfigurera principfilen med hjälp av webbläsaren.

Lita på certifikatet med Fedora 34

Firefox på Fedora

echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js

echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg

echo "{
    \"policies\": {
        \"Certificates\": {
            \"Install\": [
                \"aspnetcore-localhost-https.crt\"
            ]
        }
    }
}" > policies.json

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt
rm localhost.crt

Lita på dotnet-to-dotnet-lösningen på Fedora

sudo cp localhost.crt /etc/pki/tls/certs/localhost.pem
sudo update-ca-trust
rm localhost.crt

Mer information finns i den här GitHub-kommentaren.

Lita på certifikatet med andra distributioner

Se det här GitHub-problemet.

Lita på HTTPS-certifikat från Windows-undersystem för Linux

Windows-undersystem för Linux (WSL) genererar ett självsignerat HTTPS-utvecklingscertifikat. Så här konfigurerar du Windows-certifikatarkivet för att lita på WSL-certifikatet:

• Exportera utvecklarcertifikatet till en fil på Windows:

  dotnet dev-certs https -ep C:\<<path-to-folder>>\aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$
  

  Där $CREDENTIAL_PLACEHOLDER$ är ett lösenord.

• I ett WSL-fönster importerar du det exporterade certifikatet på WSL-instansen:

  dotnet dev-certs https --clean --import /mnt/c/<<path-to-folder>>/aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$
  

Föregående metod är en engångsåtgärd per certifikat och per WSL-distribution. Det är enklare än att exportera certifikatet om och om. Om du uppdaterar eller återskapar certifikatet i windows kan du behöva köra föregående kommandon igen.

Felsöka certifikatproblem som att certifikatet inte är pålitligt

Det här avsnittet innehåller hjälp när ASP.NET Core HTTPS-utvecklingscertifikatet har installerats och betrotts, men du fortfarande har webbläsarvarningar om att certifikatet inte är betrott. ASP.NET Core HTTPS-utvecklingscertifikatet används av Kestrel.

Information om hur du reparerar IIS Express-certifikatet finns i den här frågan på Stackoverflow.

Alla plattformar – certifikatet är inte betrott

Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser som är öppna. Öppna ett nytt webbläsarfönster i appen. Certifikatförtroende cachelagras av webbläsare.

dotnet dev-certs https --clean misslyckas

De föregående kommandona löser de flesta problem med webbläsarförtroende. Om webbläsaren fortfarande inte litar på certifikatet följer du de plattformsspecifika förslag som följer.

Docker – certifikatet är inte betrott

• Ta bort mappen C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Rensa lösningen. Ta bort bin och obj mappar.
• Starta om utvecklingsverktyg. Till exempel Visual Studio, Visual Studio Code eller Visual Studio för Mac.

Windows – certifikatet är inte pålitligt

• Kontrollera certifikaten i certifikatarkivet. Det bör finnas ett localhost-certifikat med det ASP.NET Core HTTPS development certificate vänliga namnet både under Current User > Personal > Certificates och Current User > Trusted root certification authorities > Certificates
• Ta bort alla certifikat som har hittats från både personliga och betrodda rotcertifikatsutfärdare. Ta inte bort IIS Express localhost-certifikatet.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser som är öppna. Öppna ett nytt webbläsarfönster i appen. Certifikatförtroendet cachelagras av webbläsare.

OS X – certifikatet är inte betrodd

• Öppna Nyckelringsåtkomst.
• Välj systemnyckelringen.
• Kontrollera om det finns ett localhost-certifikat.
• Kontrollera att den innehåller en + symbol på ikonen för att ange att den är betrodd för alla användare.
• Ta bort certifikatet från systemnyckelringen.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser som är öppna. Öppna ett nytt webbläsarfönster i appen. Certifikatförtroendet cachelagras av webbläsare.

Se HTTPS-fel med IIS Express (dotnet/AspNetCore #16892) för felsökning av certifikatproblem med Visual Studio.

Linux-certifikatet är inte pålitligt

Kontrollera att certifikatet som konfigureras för förtroende är användarens HTTPS-utvecklarcertifikat som ska användas av Kestrel-servern.

Kontrollera den aktuella användarens standardcertifikat för HTTPS-utvecklare Kestrel på följande plats:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

HTTPS-utvecklarcertifikatfilen Kestrel är SHA1-fingeravtrycket. När filen tas bort via dotnet dev-certs https --cleanåterskapas den när det behövs med ett annat tumavtryck. Kontrollera tumavtrycket för det exporterade certifikatet med följande kommando:

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Om certifikatet inte matchar kan det vara något av följande:

• Ett gammalt certifikat.
• Ett exporterat utvecklarcertifikat för rotanvändaren. I det här fallet exporterar du certifikatet.

Rotanvändarcertifikatet kan kontrolleras på:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

IIS Express SSL-certifikat som används med Visual Studio

Om du vill åtgärda problem med IIS Express-certifikatet väljer du Reparera från Installationsprogrammet för Visual Studio. Mer information finns i det här GitHub-ärendet.

Ytterligare information

• Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare
• Värd för ASP.NET Core i Linux med Nginx: HTTPS-konfiguration
• Konfigurera SSL på IIS-
• OWASP HSTS-webbläsarens stöd
• dotnet dev-certs

HTTP-omdirigering till HTTPS orsakar ERR_INVALID_REDIRECT för CORS-förflygningsbegäran

Begäranden till en nätverksadress med HTTP som omdirigeras till HTTPS av UseHttpsRedirection misslyckas vid CORS-förhandsförfrågan med ERR_INVALID_REDIRECT.

API-projekt kan avvisa HTTP-begäranden i stället för att använda UseHttpsRedirection för att omdirigera begäranden till HTTPS.

Kräv HTTPS

Vi rekommenderar att produktions-ASP.NET Core webbappar använder:

• HTTPS Redirection Middleware (UseHttpsRedirection) för att omdirigera HTTP-begäranden till HTTPS.
• HSTS Middleware (UseHsts) för att skicka HSTS-huvuden (HTTP Strict Transport Security Protocol) till klienter.

AnvändHttpsOmdirigering

Följande kod anropar UseHttpsRedirection i filen Program.cs:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Föregående markerade kod:

• Använder standardvärdet HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Använder standardvärdet HttpsRedirectionOptions.HttpsPort (null) om det inte åsidosätts av miljövariabeln ASPNETCORE_HTTPS_PORT eller IServerAddressesFeature.

Vi rekommenderar att du använder tillfälliga omdirigeringar i stället för permanenta omdirigeringar. Länkcachelagring kan orsaka instabilt beteende i utvecklingsmiljöer. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen finns i en miljö som inte är utvecklingsmiljö kan du läsa avsnittet Konfigurera permanenta omdirigeringar i produktion. Vi rekommenderar att du använder HSTS- för att signalera till klienter att endast säkra resursbegäranden ska skickas till appen (endast i produktion).

Portkonfiguration

En port måste vara tillgänglig för mellanprogrammet för att omdirigera en osäker begäran till HTTPS. Om ingen port är tillgänglig:

• Omdirigering till HTTPS sker inte.
• Mellanprogrammet loggar varningen "Det gick inte att fastställa https-porten för omdirigering".

Ange HTTPS-porten med någon av följande metoder:

• Ange HttpsRedirectionOptions.HttpsPort.

• Ange värdinställningen https_port:

  • I värdkonfiguration.

  • Genom att ange miljövariabeln ASPNETCORE_HTTPS_PORT.

  • Genom att lägga till en post på den översta nivån i appsettings.json:

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• Ange en port med det säkra schemat med hjälp av ASPNETCORE_URLS miljövariabeln. Miljövariabeln konfigurerar servern. Mellanprogrammet identifierar indirekt HTTPS-porten via IServerAddressesFeature. Den här metoden fungerar inte i distributioner med omvänd proxy.

• Webbmallarna ASP.NET Core anger en HTTPS-URL i Properties/launchsettings.json för både Kestrel och IIS Express. launchsettings.json används endast på den lokala datorn.

• Konfigurera en HTTPS-URL-slutpunkt för en offentlig edge-distribution av Kestrel server eller HTTP.sys server. Endast en HTTPS-port används av appen. Mellanprogrammet identifierar porten via IServerAddressesFeature.

Edge-implementeringar

När Kestrel eller HTTP.sys används som en offentlig edge-server måste Kestrel eller HTTP.sys konfigureras för att lyssna på båda:

• Den säkra port där klienten omdirigeras (vanligtvis 443 i produktion och 5001 under utveckling).
• Den osäkra porten (vanligtvis 80 i produktion och 5 000 under utveckling).

Den osäkra porten måste vara tillgänglig för klienten för att appen ska kunna ta emot en osäker begäran och omdirigera klienten till den säkra porten.

Mer information finns i Kestrel slutpunktskonfiguration eller HTTP.sys webbserverimplementering i ASP.NET Core.

Distributionsscenarier

Alla brandväggar mellan klienten och servern måste också ha kommunikationsportar öppna för trafik.

Om förfrågningar vidarebefordras i en konfiguration med omvänd proxy, använd Mellanvara för vidarebefordrade rubriker innan du anropar HTTPS-omdirigeringsmellanvara. Mellanprogram för vidarebefordrade rubriker uppdaterar Request.Schemegenom X-Forwarded-Proto-huvud. Mellanprogrammet tillåter att omdirigerings-URI:er och andra säkerhetsprinciper fungerar korrekt. När Mellanprogram för vidarebefordrade huvuden inte används kanske serverdelsappen inte får rätt schema och hamnar i en omdirigeringsloop. Ett vanligt felmeddelande från slutanvändaren är att för många omdirigeringar har inträffat.

När du distribuerar till Azure App Service följer du anvisningarna i Självstudie: Binda ett befintligt anpassat SSL-certifikat till Azure Web Apps.

Alternativ

Följande markerade kod anropar AddHttpsRedirection för att konfigurera mellanprogramsalternativ:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Det är bara nödvändigt att anropa AddHttpsRedirection för att ändra värdena för HttpsPort eller RedirectStatusCode.

Föregående markerade kod:

• Anger HttpsRedirectionOptions.RedirectStatusCode till Status307TemporaryRedirect, vilket är standardvärdet. Använd fälten i klassen StatusCodes för att göra tilldelningar till RedirectStatusCode.
• Anger HTTPS-porten till 5001.

Konfigurera permanenta omdirigeringar i produktion

Mellanprogrammet skickar som standard en Status307TemporaryRedirect med alla omdirigeringar. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen är i en icke-utvecklingsmiljö, omsluter du konfigurationen av mellanprogramsalternativen i en villkorlig kontroll för en miljö som inte är utvecklingsmiljö.

När du konfigurerar tjänster i Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Alternativt angreppssätt för HTTPS-omdirigering i middleware

Ett alternativ till att använda HTTPS Redirection Middleware (UseHttpsRedirection) är att använda URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps kan också ange statuskod och port när omdirigeringen körs. Mer information finns i URL Omskrivning av mellanprogram.

När du omdirigerar till HTTPS utan krav på ytterligare omdirigeringsregler rekommenderar vi att du använder HTTPS Redirection Middleware (UseHttpsRedirection) som beskrivs i den här artikeln.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HTTP Strict Transport Security (HSTS) är en valfri säkerhetsförbättring som definieras av en webbapplikation genom användningen av ett svarshuvud. När en webbläsare som stöder HSTS tar emot den här rubriken:

• Webbläsaren lagrar konfigurationen för domänen som förhindrar att någon kommunikation skickas via HTTP. Webbläsaren tvingar all kommunikation över HTTPS.
• Webbläsaren hindrar användaren från att använda ej betrodda eller ogiltiga certifikat. Webbläsaren inaktiverar uppmaningar som gör att en användare tillfälligt kan lita på ett sådant certifikat.

Eftersom HSTS- tillämpas av klienten har den vissa begränsningar:

• Klienten måste ha stöd för HSTS.
• HSTS kräver minst en lyckad HTTPS-begäran för att upprätta HSTS-principen.
• Programmet måste kontrollera varje HTTP-begäran och omdirigera eller avvisa HTTP-begäran.

ASP.NET Core implementerar HSTS med UseHsts-tilläggsmetoden. Följande kod anropar UseHsts när appen inte är i utvecklingsläge:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts rekommenderas inte under utveckling eftersom HSTS-inställningarna är mycket cachelagrade av webbläsare. Som standard utesluter UseHsts den lokala loopback-adressen.

För produktionsmiljöer som implementerar HTTPS för första gången anger du den första HstsOptions.MaxAge till ett litet värde med någon av de TimeSpan metoderna. Ange värdet från timmar till högst en enda dag om du behöver återställa HTTPS-infrastrukturen till HTTP. När du är säker på hållbarheten i HTTPS-konfigurationen ökar du värdet för HSTS-max-age. ett vanligt värde är ett år.

Följande markerade kod:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• Anger förhandsladdningsparametern för Strict-Transport-Security-headern. Förinläsning är inte en del av RFC HSTS-specifikationen, men stöds av webbläsare för att förinstallera HSTS-webbplatser vid ny installation. Mer information finns i https://hstspreload.org/.
• Aktiverar includeSubDomain, som tillämpar HSTS-principen på värdunderdomäner.
• Anger uttryckligen max-age-parametern för Strict-Transport-Security-huvudet till 60 dagar. Om den inte har angetts är standardvärdet 30 dagar. Mer information finns i maxåldersdirektivet.
• Lägger till example.com i listan över värdar som ska undantas.

UseHsts exkluderar följande loopback-värdar:

• localhost : IPv4-loopback-adressen.
• 127.0.0.1 : IPv4-loopback-adressen.
• [::1] : IPv6-loopback-adressen.

Välj bort HTTPS/HSTS vid projektskapande

I vissa scenarier med serverdelstjänst där anslutningssäkerhet hanteras på nätverkets offentliga kant krävs inte konfigurering av anslutningssäkerhet vid varje nod. Webbappar som genereras från mallarna i Visual Studio eller från kommandot dotnet new gör det möjligt att använda HTTPS-omdirigering och HSTS. För distributioner som inte kräver dessa scenarier kan du välja bort HTTPS/HSTS när appen skapas från mallen.

Så här väljer du bort HTTPS/HSTS:

dotnet new webapp --no-https

Lita på https-utvecklingscertifikatet för ASP.NET Core i Windows och macOS

För webbläsaren Firefox, se nästa avsnitt.

.NET Core SDK innehåller ett HTTPS-utvecklingscertifikat. Certifikatet installeras som en del av förstegångsupplevelsen. Till exempel ger dotnet --info en variant av följande utdata:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

När du installerar .NET Core SDK installeras ASP.NET Core HTTPS-utvecklingscertifikatet i det lokala användarcertifikatarkivet. Certifikatet har installerats, men det är inte pålitligt. Om du vill lita på certifikatet utför du engångssteget för att köra verktyget dotnet dev-certs:

dotnet dev-certs https --trust

Följande kommando innehåller hjälp om verktyget dotnet dev-certs:

dotnet dev-certs https --help

Lita på HTTPS-certifikatet med Firefox för att förhindra SEC_ERROR_INADEQUATE_KEY_USAGE fel

Webbläsaren Firefox använder ett eget certifikatarkiv och litar därför inte på IIS Express- eller Kestrel utvecklarcertifikat.

Det finns två sätt att lita på HTTPS-certifikatet med Firefox, skapa en principfil eller konfigurera med FireFox-webbläsaren. När du konfigurerar med webbläsaren skapas principfilen, så de två metoderna är likvärdiga.

Skapa en principfil för att lita på HTTPS-certifikat med Firefox

Skapa en principfil (policies.json) på:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: Se Lita på certifikatet med Firefox på Linux i den här artikeln.

Lägg till följande JSON i Firefox-principfilen:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Den föregående principfilen gör Att Firefox litar på certifikat från de betrodda certifikaten i Windows-certifikatarkivet. Nästa avsnitt innehåller en alternativ metod för att skapa föregående principfil med hjälp av webbläsaren Firefox.

Konfigurera förtroende för HTTPS-certifikat med webbläsaren Firefox

Ange security.enterprise_roots.enabled = true med hjälp av följande instruktioner:

1. Ange about:config i FireFox-webbläsaren.
2. Välj Acceptera risken och fortsätt om du accepterar risken.
3. Välj Visa alla
4. Ange security.enterprise_roots.enabled = true
5. Avsluta och starta om Firefox

Mer information finns i Konfigurera certifikatutfärdare (CA) i Firefox och filen mozilla/policy-templates/README.

Så här konfigurerar du ett utvecklarcertifikat för Docker

Se det här GitHub-problemet.

Lita på HTTPS-certifikat i Linux

Att upprätta förtroende är distributions- och webbläsarspecifikt. Följande avsnitt innehåller instruktioner för några populära distributioner och Chromium-webbläsare (Edge och Chrome) och för Firefox.

Ubuntu litar på certifikatet för tjänst-till-tjänst-kommunikation

Följande instruktioner fungerar inte för vissa Ubuntu-versioner, till exempel 20.04. Mer information finns i GitHub-problem dotnet/AspNetCore.Docs #23686.

1. Installera OpenSSL 1.1.1h eller senare. Se distributionen för instruktioner om hur du uppdaterar OpenSSL.

2. Kör följande kommandon:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

Föregående kommandon:

• Kontrollera att den aktuella användarens utvecklarcertifikat har skapats.
• Exporterar certifikatet med utökade behörigheter som krävs för mappen ca-certificates med hjälp av den aktuella användarens miljö.
• Om du tar bort -E-flaggan exporteras rotanvändarcertifikatet och genereras om det behövs. Varje nyligen genererat certifikat har olika tumavtryck. När du kör som root behövs inte sudo och -E.

Sökvägen i föregående kommando är specifik för Ubuntu. För andra distributioner väljer du en lämplig sökväg eller använder sökvägen för certifikatutfärdare (CA).

Lita på HTTPS-certifikat i Linux med Edge eller Chrome

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

dnf install nss-tools

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Lita på certifikatet med Fedora 34

Se:

• Den här GitHub-kommentaren
• Fedora: Använda delade systemcertifikat
• Konfigurera en .NET-utvecklingsmiljö på Fedora.

Lita på certifikatet med andra distributioner

Se det här GitHub-problemet.

Lita på HTTPS-certifikat från Windows-undersystem för Linux

Följande instruktioner fungerar inte för vissa Linux-distributioner, till exempel Ubuntu 20.04. Mer information finns i GitHub-problem dotnet/AspNetCore.Docs #23686.

Windows-undersystem för Linux (WSL) genererar ett SJÄLVsignerat HTTPS-utvecklingscertifikat som som standard inte är betrott i Windows. Det enklaste sättet att låta Windows lita på WSL-certifikatet är att konfigurera WSL att använda samma certifikat som Windows:

• Exportera utvecklarcertifikatet till en fil på Windows:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  Där $CREDENTIAL_PLACEHOLDER$ är ett lösenord.

• I ett WSL-fönster importerar du det exporterade certifikatet på WSL-instansen:

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

Föregående metod är en engångsåtgärd per certifikat och per WSL-distribution. Det är enklare än att exportera certifikatet om och om. Om du uppdaterar eller återskapar certifikatet i windows kan du behöva köra föregående kommandon igen.

Felsöka certifikatproblem såsom certifikatet inte är pålitligt

Det här avsnittet innehåller hjälp när ASP.NET Core HTTPS-utvecklingscertifikatet har installerats och betrotts, men du fortfarande har webbläsarvarningar om att certifikatet inte är betrott. ASP.NET Core HTTPS-utvecklingscertifikatet används av Kestrel.

Information om hur du reparerar IIS Express-certifikatet finns i det här Problemet med Stackoverflow-.

Alla plattformar – certifikatet är inte tillförlitligt

Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen. Webbläsare cachelagrar certifikatförtroenden.

dotnet dev-certs https --clean misslyckades

De föregående kommandona löser de flesta problem med webbläsarförtroende. Om webbläsaren fortfarande inte litar på certifikatet följer du de plattformsspecifika förslag som följer.

Docker – certifikatet är inte betrott

• Ta bort mappen C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Rensa lösningen. Ta bort bin och obj mappar.
• Starta om utvecklingsverktyg. Till exempel Visual Studio eller Visual Studio Code.

Windows – certifikatet är inte betrott

• Kontrollera certifikaten i certifikatarkivet. Det bör finnas ett localhost-certifikat med det ASP.NET Core HTTPS development certificate vänliga namnet både under Current User > Personal > Certificates och Current User > Trusted root certification authorities > Certificates.
• Ta bort alla hittade certifikat från både personliga och betrodda rotcertifikatmyndigheter. Ta inte bort IIS Express localhost-certifikatet.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen.

OS X – certifikatet är inte förtrott

• Öppna Nyckelringsåtkomst.
• Välj systemnyckelringen.
• Kontrollera om det finns ett localhost-certifikat.
• Kontrollera att den innehåller en + symbol på ikonen för att ange att den är betrodd för alla användare.
• Ta bort certifikatet från systemnyckelringen.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen.

Se HTTPS-fel med IIS Express (dotnet/AspNetCore #16892) för felsökning av certifikatproblem med Visual Studio.

Linux-certifikatet är ej betrott

Kontrollera att certifikatet som konfigureras för förtroende är användarens HTTPS-utvecklarcertifikat som ska användas av Kestrel-servern.

Kontrollera den aktuella användarens standardcertifikat för HTTPS-utvecklare Kestrel på följande plats:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

HTTPS-utvecklare Kestrel:s certifikatfil är SHA1-fingeravtrycket. När filen tas bort via dotnet dev-certs https --cleanåterskapas den när det behövs med ett annat tumavtryck. Kontrollera att fingeravtrycket för det exporterade certifikatet stämmer med följande kommando:

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Om certifikatet inte matchar kan det vara något av följande:

• Ett gammalt certifikat.
• Ett utvecklarcertifikat har exporterats för rotanvändaren. I det här fallet exporterar du certifikatet.

Rotanvändarcertifikatet kan kontrolleras på:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

IIS Express SSL-certifikat som används med Visual Studio

Om du vill åtgärda problem med IIS Express-certifikatet väljer du Reparera från Installationsprogrammet för Visual Studio. Mer information finns i det här GitHub-ärendet.

Grupprincip förhindrar att självsignerade certifikat är betrodda

I vissa fall kan grupprincip förhindra att självsignerade certifikat är betrodda. Mer information finns i det här GitHub-ärendet.

Ytterligare information

• Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare
• Värd för ASP.NET Core i Linux med Nginx: HTTPS-konfiguration
• Konfigurera SSL på IIS-
• Konfigurera slutpunkter för webbservern ASP.NET Core Kestrel
• Stöd för OWASP HSTS i webbläsare

HTTP-omdirigering till HTTPS orsakar ERR_INVALID_REDIRECT för CORS-begäran

Anrop till slutpunkten över HTTP som omdirigeras till HTTPS av UseHttpsRedirection misslyckas med ERR_INVALID_REDIRECT vid CORS-förhandsbegäran.

API-projekt kan avvisa HTTP-begäranden i stället för att använda UseHttpsRedirection för att omdirigera begäranden till HTTPS.

Kräv HTTPS

Vi rekommenderar att produktionsmiljö ASP.NET Core-webb-appar bör använda:

• HTTPS Redirection Middleware (UseHttpsRedirection) för att omdirigera HTTP-begäranden till HTTPS.
• HSTS Middleware (UseHsts) för att skicka HSTS-huvuden (HTTP Strict Transport Security Protocol) till klienter.

AnvändHttpsOmdirigering

Följande kod anropar UseHttpsRedirection i filen Program.cs:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Föregående markerade kod:

• Använder standardvärdet HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Använder standardvärdet HttpsRedirectionOptions.HttpsPort (null) om det inte åsidosätts av miljövariabeln ASPNETCORE_HTTPS_PORT eller IServerAddressesFeature.

Vi rekommenderar att du använder tillfälliga omdirigeringar i stället för permanenta omdirigeringar. Länkcachelagring kan orsaka instabilt beteende i utvecklingsmiljöer. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen finns i en miljö som inte är utvecklingsmiljö kan du läsa avsnittet Konfigurera permanenta omdirigeringar i produktion. Vi rekommenderar att du använder HSTS- för att signalera till klienter att endast säkra resursbegäranden ska skickas till appen (endast i produktion).

Portkonfiguration

En port måste vara tillgänglig för mellanprogrammet för att omdirigera en osäker begäran till HTTPS. Om ingen port är tillgänglig:

• Omdirigering till HTTPS sker inte.
• Mellanprogrammet loggar varningen "Det gick inte att fastställa https-porten för omdirigering".

Ange HTTPS-porten med någon av följande metoder:

• Ange HttpsRedirectionOptions.HttpsPort.

• Ange värdinställningen https_port:

  • I värdkonfiguration.

  • Genom att ange miljövariabeln ASPNETCORE_HTTPS_PORT.

  • Genom att lägga till en post på den översta nivån i appsettings.json:

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• Ange en port med det säkra schemat med hjälp av ASPNETCORE_URLS miljövariabeln. Miljövariabeln konfigurerar servern. Mellanprogrammet identifierar indirekt HTTPS-porten via IServerAddressesFeature. Den här metoden fungerar inte i distributioner med omvänd proxy.

• Webbmallarna ASP.NET Core anger en HTTPS-URL i Properties/launchsettings.json för både Kestrel och IIS Express. launchsettings.json används endast på den lokala datorn.

• Konfigurera en HTTPS-URL-slutpunkt för en offentlig edge-distribution av Kestrel server eller HTTP.sys server. Endast en HTTPS-port används av appen. Mellanprogrammet identifierar porten via IServerAddressesFeature.

Edge-implementeringar

När Kestrel eller HTTP.sys används som en offentlig edge-server måste Kestrel eller HTTP.sys konfigureras för att lyssna på båda:

• Den säkra port där klienten omdirigeras (vanligtvis 443 i produktion och 5001 under utveckling).
• Den osäkra porten (vanligtvis 80 i produktion och 5 000 under utveckling).

Den osäkra porten måste vara tillgänglig för klienten för att appen ska kunna ta emot en osäker begäran och omdirigera klienten till den säkra porten.

Mer information finns i Kestrel slutpunktskonfiguration eller HTTP.sys webbserverimplementering i ASP.NET Core.

Distributionsscenarier

Alla brandväggar mellan klienten och servern måste också ha kommunikationsportar öppna för trafik.

Om begäranden vidarebefordras i en konfiguration med omvänd proxy ska du använda Vidarebefordrade Headers Mellanprogram innan du anropar HTTPS-omdirigeringsmellanprogrammet. Vidarebefordrade rubriker Mellanprogram uppdaterar Request.Schememed hjälp av X-Forwarded-Proto-huvudet. Mellanprogrammet tillåter att omdirigerings-URI:er och andra säkerhetsprinciper fungerar korrekt. När Middleware för vidarebefordrade headers inte används kanske backend-applikationen inte får rätt schema och hamnar i en omdirigeringsloop. Ett vanligt felmeddelande från slutanvändaren är att för många omdirigeringar har inträffat.

När du distribuerar till Azure App Service följer du anvisningarna i Självstudie: Binda ett befintligt anpassat SSL-certifikat till Azure Web Apps.

Alternativ

Följande markerade kod anropar AddHttpsRedirection för att konfigurera mellanprogramsalternativ:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Det är bara nödvändigt att anropa AddHttpsRedirection för att ändra värdena för HttpsPort eller RedirectStatusCode.

Föregående markerade kod:

• Anger HttpsRedirectionOptions.RedirectStatusCode till Status307TemporaryRedirect, vilket är standardvärdet. Använd fälten i klassen StatusCodes för tilldelningar till RedirectStatusCode.
• Anger HTTPS-porten till 5001.

Konfigurera permanenta omdirigeringar i produktion

Mellanprogrammet skickar som standard en Status307TemporaryRedirect med alla omdirigeringar. Om du föredrar att skicka en permanent omdirigeringsstatuskod när appen är i en icke-utvecklingsmiljö, omsluter du konfigurationen av mellanprogramsalternativen i en villkorlig kontroll för en miljö som inte är utvecklingsmiljö.

När du konfigurerar tjänster i Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Alternativ metod för HTTPS-omdirigeringsmiddleware

Ett alternativ till att använda HTTPS Redirection Middleware (UseHttpsRedirection) är att använda URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps kan också ange statuskod och port när omdirigeringen körs. För mer information, se URL Rewriting Middleware.

När du omdirigerar till HTTPS utan krav på ytterligare omdirigeringsregler rekommenderar vi att du använder HTTPS Redirection Middleware (UseHttpsRedirection) som beskrivs i den här artikeln.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HTTP Strict Transport Security (HSTS) är en säkerhetsförbättring som kräver aktivt val och specificeras av en webbapp med hjälp av en responsrubrik. När en webbläsare som stöder HSTS får den här headern:

• Webbläsaren lagrar konfigurationen för domänen som förhindrar att någon kommunikation skickas via HTTP. Webbläsaren tvingar igenom all kommunikation över HTTPS.
• Webbläsaren hindrar användaren från att använda ej betrodda eller ogiltiga certifikat. Webbläsaren inaktiverar uppmaningar som gör att en användare tillfälligt kan lita på ett sådant certifikat.

Eftersom HSTS- tillämpas av klienten har den vissa begränsningar:

• Klienten måste ha stöd för HSTS.
• HSTS kräver minst en lyckad HTTPS-begäran för att upprätta HSTS-principen.
• Programmet måste kontrollera varje HTTP-begäran och omdirigera eller avvisa HTTP-begäran.

ASP.NET Core implementerar HSTS med UseHsts-tilläggsmetoden. Följande kod anropar UseHsts när appen inte är i utvecklingsläge:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts rekommenderas inte under utveckling eftersom HSTS-inställningarna är mycket cachelagrade av webbläsare. Som standard utesluter UseHsts den lokala loopback-adressen.

För produktionsmiljöer som implementerar HTTPS för första gången anger du den första HstsOptions.MaxAge till ett litet värde med någon av de TimeSpan metoderna. Ange värdet från timmar till högst en enda dag om du behöver återställa HTTPS-infrastrukturen till HTTP. När du är säker på hållbarheten i HTTPS-konfigurationen ökar du värdet för HSTS-max-age. ett vanligt värde är ett år.

Följande markerade kod:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• Anger förinläsningsparametern för Strict-Transport-Security-headern. Förinläsning är inte en del av RFC HSTS-specifikationen, men stöds av webbläsare för att förinstallera HSTS-webbplatser vid ny installation. Mer information finns i https://hstspreload.org/.
• Aktiverar includeSubDomain, som tillämpar HSTS-principen på värdunderdomäner.
• Anger uttryckligen max-age-parametern för Strict-Transport-Security-huvudet till 60 dagar. Om den inte har angetts är standardvärdet 30 dagar. Mer information finns i maxåldersdirektivet.
• Lägger till example.com i listan över värdar som ska undantas.

UseHsts exkluderar följande loopback-värdar:

• localhost : IPv4-loopback-adressen.
• 127.0.0.1 : IPv4-loopback-adressen.
• [::1] : IPv6-loopback-adressen.

Välj bort HTTPS/HSTS när ett projekt skapas

I vissa scenarier med serverdelstjänst där anslutningssäkerhet hanteras på nätverkets offentliga kant krävs inte konfigurering av anslutningssäkerhet vid varje nod. Webbappar som genereras från mallarna i Visual Studio eller från kommandot dotnet new aktiverar HTTPS-omdirigering och HSTS. För distributioner som inte kräver dessa scenarier kan du välja bort HTTPS/HSTS när appen skapas från mallen.

Så här väljer du bort HTTPS/HSTS:

dotnet new webapp --no-https

Lita på https-utvecklingscertifikatet för ASP.NET Core i Windows och macOS

För webbläsaren Firefox, se nästa avsnitt.

.NET Core SDK innehåller ett HTTPS-utvecklingscertifikat. Certifikatet installeras som en del av den första körningen. Till exempel ger dotnet --info en variant av följande utdata:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

När du installerar .NET Core SDK installeras ASP.NET Core HTTPS-utvecklingscertifikatet i det lokala användarcertifikatarkivet. Certifikatet har installerats, men det är inte betrott. Om du vill lita på certifikatet utför du engångssteget för att köra verktyget dotnet dev-certs:

dotnet dev-certs https --trust

Följande kommando innehåller hjälp om verktyget dotnet dev-certs:

dotnet dev-certs https --help

Lita på HTTPS-certifikatet med Firefox för att förhindra SEC_ERROR_INADEQUATE_KEY_USAGE fel

Webbläsaren Firefox använder ett eget certifikatarkiv och litar därför inte på IIS Express- eller Kestrel utvecklarcertifikat.

Det finns två sätt att lita på HTTPS-certifikatet med Firefox, skapa en principfil eller konfigurera med FireFox-webbläsaren. När du konfigurerar med webbläsaren skapas principfilen, så de två metoderna är likvärdiga.

Skapa en principfil för att lita på HTTPS-certifikat med Firefox

Skapa en principfil (policies.json) på:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: Se Lita på certifikatet med Firefox på Linux i den här artikeln.

Lägg till följande JSON i Firefox-principfilen:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Den föregående policy-filen gör att Firefox litar på certifikat från de betrodda certifikaten i Windows-certifikatarkivet. Nästa avsnitt innehåller en alternativ metod för att skapa föregående principfil med hjälp av webbläsaren Firefox.

Konfigurera förtroende för HTTPS-certifikat med webbläsaren Firefox

Ange security.enterprise_roots.enabled = true med hjälp av följande instruktioner:

1. Ange about:config i FireFox-webbläsaren.
2. Välj Acceptera risken och fortsätt om du accepterar risken.
3. Välj Visa alla
4. Ange security.enterprise_roots.enabled = true
5. Avsluta och starta om Firefox

Mer information finns i Konfigurera certifikatutfärdare (CA) i Firefox och filen mozilla/policy-templates/README.

Så här konfigurerar du ett utvecklarcertifikat för Docker

Se GitHub-fråga.

Lita på HTTPS-certifikat i Linux

Att upprätta förtroende är distributions- och webbläsarspecifikt. Följande avsnitt innehåller instruktioner för några populära distributioner och Chromium-webbläsare (Edge och Chrome) och för Firefox.

Lita på HTTPS-certifikat i Linux med linux-dev-certs

linux-dev-certs är ett globalt .NET-verktyg med öppen källkod som stöds av communityn och som är ett bekvämt sätt att skapa och lita på ett utvecklarcertifikat på Linux. Verktyget underhålls inte eller stöds inte av Microsoft.

Följande kommandon installerar verktyget och skapar ett betrott utvecklarcertifikat:

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

Mer information eller rapportera problem finns i gitHub-lagringsplatsen linux-dev-certs.

Ubuntu litar på certifikatet för tjänst-till-tjänst-kommunikation

Följande instruktioner fungerar inte för vissa Ubuntu-versioner, till exempel 20.04. Mer information finns i GitHub-problem dotnet/AspNetCore.Docs #23686.

1. Installera OpenSSL 1.1.1h eller senare. Se distributionen för instruktioner om hur du uppdaterar OpenSSL.

2. Kör följande kommandon:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

Föregående kommandon:

• Kontrollera att den aktuella användarens utvecklarcertifikat har skapats.
• Exporterar certifikatet med utökade behörigheter som krävs för mappen ca-certificates med hjälp av den aktuella användarens miljö.
• Om du tar bort -E-flaggan exporteras root-användarcertifikatet, och genereras om det behövs. Varje nyligen genererat certifikat har olika tumavtryck. När du kör som rot behövs inte sudo och -E.

Sökvägen i föregående kommando är specifik för Ubuntu. För andra distributioner väljer du en lämplig sökväg eller använder sökvägen för certifikatutfärdare (CA).

Lita på HTTPS-certifikat i Linux med Edge eller Chrome

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

dnf install nss-tools

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Lita på certifikatet med Fedora 34

Se:

• Den här GitHub-kommentaren
• Fedora: Använda delade systemcertifikat
• Konfigurera en .NET-utvecklingsmiljö på Fedora.

Lita på certifikatet med andra distributioner

Se det här GitHub-problemet.

Lita på HTTPS-certifikat från Windows-undersystem för Linux

Följande instruktioner fungerar inte för vissa Linux-distributioner, till exempel Ubuntu 20.04. Mer information finns i GitHub-problem dotnet/AspNetCore.Docs #23686.

Windows-undersystem för Linux (WSL) genererar ett självsignerat HTTPS-utvecklingscertifikat som inte är betrott som standard i Windows. Det enklaste sättet att låta Windows lita på WSL-certifikatet är att konfigurera WSL att använda samma certifikat som Windows:

• Exportera utvecklarcertifikatet till en fil på Windows:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  Där $CREDENTIAL_PLACEHOLDER$ är ett lösenord.

• I ett WSL-fönster importerar du det exporterade certifikatet på WSL-instansen:

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

Föregående metod är en engångsåtgärd per certifikat och per WSL-distribution. Det är enklare än att exportera certifikatet om och om. Om du uppdaterar eller återskapar certifikatet i windows kan du behöva köra föregående kommandon igen.

Felsöka certifikatproblem som att certifikatet inte är betrott

Det här avsnittet innehåller hjälp när ASP.NET Core HTTPS-utvecklingscertifikatet har installerats och betrotts, men du fortfarande har webbläsarvarningar om att certifikatet inte är betrott. ASP.NET Core HTTPS-utvecklingscertifikatet används av Kestrel.

Information om hur du reparerar IIS Express-certifikatet finns i det här Stackoverflow-ärendet .

Alla plattformar – certifikatet är inte betrott

Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen. Certifikatförtroendet cachelagras av webbläsare.

dotnet dev-certs https --clean Misslyckas

De föregående kommandona löser de flesta problem med webbläsarförtroende. Om webbläsaren fortfarande inte litar på certifikatet följer du de plattformsspecifika förslag som följer.

Docker – certifikatet är inte betrott

• Ta bort mappen C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Rensa lösningen. Ta bort bin och obj mappar.
• Starta om utvecklingsverktyg. Till exempel Visual Studio eller Visual Studio Code.

Windows – certifikatet är inte betrott

• Kontrollera certifikaten i certifikatarkivet. Det bör finnas ett localhost-certifikat med det ASP.NET Core HTTPS development certificate vänliga namnet både under Current User > Personal > Certificates och Current User > Trusted root certification authorities > Certificates.
• Ta bort alla hittade certifikat från både personliga och betrodda rotcertifikatmyndigheter. Ta inte bort IIS Express localhost-certifikatet.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen.

OS X – certifikatet är inte betrott

• Öppna Nyckelringsåtkomst.
• Välj systemnyckelringen.
• Kontrollera om det finns ett localhost-certifikat.
• Kontrollera att den innehåller en + symbol på ikonen för att ange att den är betrodd för alla användare.
• Ta bort certifikatet från systemnyckelringen.
• Kör följande kommandon:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Stäng alla webbläsarinstanser öppna. Öppna ett nytt webbläsarfönster för appen.

Se HTTPS-fel med IIS Express (dotnet/AspNetCore #16892) för felsökning av certifikatproblem med Visual Studio.

Linux-certifikatet är inte betrodda

Kontrollera att certifikatet som konfigureras för förtroende är användarens HTTPS-utvecklarcertifikat som ska användas av Kestrel-servern.

Kontrollera den aktuella användarens standardcertifikat för HTTPS-utvecklare Kestrel på följande plats:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

HTTPS-utvecklarens certifikatfil Kestrel är SHA1-tummavtrycket. När filen tas bort via dotnet dev-certs https --cleanåterskapas den när det behövs med ett annat tumavtryck. Kontrollera tumavtrycket för det exporterade certifikatet med följande kommando:

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Om certifikatet inte matchar kan det vara något av följande:

• Ett gammalt certifikat.
• Ett utvecklarcertifikat för rotanvändaren har exporterats. I det här fallet exporterar du certifikatet.

Rotanvändarcertifikatet kan kontrolleras på:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

IIS Express SSL-certifikat som används med Visual Studio

Om du vill åtgärda problem med IIS Express-certifikatet väljer du Reparera från Installationsprogrammet för Visual Studio. För mer information, se detta GitHub-ärende.

Grupprincip förhindrar att självsignerade certifikat är betrodda

I vissa fall kan grupprincip förhindra att självsignerade certifikat är betrodda. Mer information finns i det här GitHub-problemet.

Ytterligare information

• Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare
• Värd för ASP.NET Core i Linux med Nginx: HTTPS-konfiguration
• Konfigurera SSL på IIS-
• Konfigurera slutpunkter för webbservern ASP.NET Core Kestrel
• OWASP HSTS-webbläsarstöd