HTTPS afdwingen in ASP.NET Core

Door David Galvan en Rick Anderson

in dit artikel wordt beschreven hoe u:

• HTTPS vereisen voor alle aanvragen.
• Alle HTTP-aanvragen omleiden naar HTTPS.

Er kan geen API worden gebruikt om te voorkomen dat een client gevoelige gegevens verzendt in de eerste aanvraag.

Waarschuwing

API-projecten

Gebruik geenRequireHttpsAttribute op web-API's die gevoelige informatie ontvangen. RequireHttpsAttribute gebruikt HTTP-statuscodes om browsers om te leiden van HTTP naar HTTPS. API-clients begrijpen of gehoorzamen mogelijk geen omleidingen van HTTP naar HTTPS. Dergelijke clients kunnen informatie verzenden via HTTP. Web-API's moeten het volgende doen:

• Luister niet op HTTP.
• Sluit de verbinding met statuscode 400 (Ongeldige aanvraag) en dien de aanvraag niet in.

Als u HTTP-omleiding in een API wilt uitschakelen, stelt u de ASPNETCORE_URLS omgevingsvariabele in of gebruikt u de --urls opdrachtregelvlag. Zie Meerdere omgevingen gebruiken op ASP.NET Core en 8 manieren om de URL's in te stellen voor een ASP.NET Core-app door Andrew Lock voor meer informatie.

HSTS- en API-projecten

De standaard-API-projecten bevatten geen HSTS , omdat HSTS doorgaans alleen een browserinstructie is. Andere bellers, zoals telefoon- of desktop-apps, gehoorzamen niet aan de instructie. Zelfs in browsers heeft één geverifieerde aanroep naar een API via HTTP risico's op onveilige netwerken. De veilige aanpak is het configureren van API-projecten om alleen te luisteren naar en te reageren via HTTPS.

HTTP-omleiding naar HTTPS veroorzaakt ERR_INVALID_REDIRECT op de preflight CORS-verzoek

Aanvragen naar een eindpunt via HTTP die door UseHttpsRedirection naar HTTPS worden omgeleid, falen met ERR_INVALID_REDIRECT tijdens de CORS preflight-aanvraag.

API-projecten kunnen HTTP-aanvragen weigeren in plaats van te gebruiken UseHttpsRedirection om aanvragen om te leiden naar HTTPS.

HTTPS vereisen

We raden aan om ASP.NET Core-web-apps in een productieomgeving te gebruiken.

• HTTPS-omleidingsmiddleware (UseHttpsRedirection) om HTTP-verzoeken om te leiden naar HTTPS.
• HSTS Middleware (UseHsts) om HSTS-headers (Strict Transport Security Protocol) naar clients te verzenden.

Opmerking

Met apps die zijn geïmplementeerd in een omgekeerde proxyconfiguratie, kan de proxy de verbindingsbeveiliging (HTTPS) verwerken. Als de proxy ook HTTPS-omleiding afhandelt, is het niet nodig om Middleware voor HTTPS-omleiding te gebruiken. Als de proxyserver ook HSTS-headers schrijft (bijvoorbeeld systeemeigen HSTS-ondersteuning in IIS 10.0 (1709) of hoger), is HSTS Middleware niet vereist voor de app. Zie Afmelden voor HTTPS/HSTS bij het maken van een project voor meer informatie.

GebruikHttpsOmleiding

De volgende code roept UseHttpsRedirection in het Program.cs bestand aan.

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();

De voorgaande gemarkeerde code:

• Maakt gebruik van de standaardwaarde HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Maakt gebruik van de standaardwaarde HttpsRedirectionOptions.HttpsPort (null), tenzij deze wordt overschreven door de ASPNETCORE_HTTPS_PORT omgevingsvariabele of IServerAddressesFeature.

U wordt aangeraden tijdelijke omleidingen te gebruiken in plaats van permanente omleidingen. Het opslaan van koppelingen kan onstabiel gedrag veroorzaken in ontwikkelomgevingen. Als u liever een permanente omleidingsstatuscode verzendt wanneer de app zich in een niet-ontwikkelomgeving bevindt, raadpleegt u de sectie Permanente omleidingen configureren in productie . U wordt aangeraden HSTS te gebruiken om clients te signaleren dat alleen beveiligde resourceaanvragen naar de app moeten worden verzonden (alleen in productie).

Poortconfiguratie

Er moet een poort beschikbaar zijn voor de middleware om een onveilige aanvraag om te leiden naar HTTPS. Als er geen poort beschikbaar is:

• Omleiding naar HTTPS vindt niet plaats.
• De middleware registreert de waarschuwing 'Kan de https-poort voor omleiding niet bepalen'.

Geef de HTTPS-poort op met behulp van een van de volgende methoden:

• Stel HttpsRedirectionOptions.HttpsPort in.

• Stel de https_porthostinstelling in:

  • In hostconfiguratie.

  • Door de ASPNETCORE_HTTPS_PORT omgevingsvariabele in te stellen.

  • Door een vermelding op het hoogste niveau toe te voegen in appsettings.json:

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

• Geef een poort aan met het beveiligde schema met behulp van de omgevingsvariabele ASPNETCORE_URLS. De omgevingsvariabele configureert de server. De middleware detecteert indirect de HTTPS-poort via IServerAddressesFeature. Deze aanpak werkt niet in omgekeerde proxyimplementaties.

• De ASP.NET Core-websjablonen stellen een HTTPS-URL in Properties/launchsettings.json voor zowel Kestrel ALS IIS Express. launchsettings.json wordt alleen op de lokale computer gebruikt.

• Configureer een HTTPS-URL-eindpunt voor een openbare edge-implementatie van Kestrel de server of HTTP.sys server. Er wordt slechts één HTTPS-poort gebruikt door de app. De middleware detecteert de poort via IServerAddressesFeature.

Opmerking

Wanneer een app wordt uitgevoerd in een omgekeerde proxyconfiguratie, IServerAddressesFeature is deze niet beschikbaar. Stel de poort in met een van de andere methoden die in deze sectie worden beschreven.

Edge-implementatieprocessen

Wanneer Kestrel of HTTP.sys wordt gebruikt als een openbare randserver, moet Kestrel of HTTP.sys worden geconfigureerd om op beide te luisteren:

• De beveiligde poort waar de client wordt omgeleid (meestal 443 in productie en 5001 in ontwikkeling).
• De onveilige poort (doorgaans 80 in productie en 5000 in ontwikkeling).

De onveilige poort moet toegankelijk zijn voor de client om de app een onveilige aanvraag te kunnen ontvangen en de client om te leiden naar de beveiligde poort.

Zie Kestrel de eindpuntconfiguratie of HTTP.sys webserver-implementatie in ASP.NET Core voor meer informatie.

Uitrolscenario's

Elke firewall tussen de client en server moet ook communicatiepoorten hebben geopend voor verkeer.

Als aanvragen worden doorgestuurd in een omgekeerde proxyconfiguratie, gebruikt u Doorverwezen Headers Middleware voordat u HTTPS Redirection Middleware aanroept. Doorgezonden headers-middleware werkt de Request.Scheme-header bij, met behulp van de X-Forwarded-Proto-header. Met de middleware kunnen omleidings-URI's en ander beveiligingsbeleid correct werken. Wanneer de middleware voor doorgeschakelde headers niet wordt gebruikt, ontvangt de backend-app mogelijk niet het juiste schema en kan deze in een omleidingsloop terechtkomen. Een veelvoorkomende gebruikersfoutmelding is dat er te veel omleidingen zijn gegeven.

Wanneer u implementeert in Azure App Service, volgt u de richtlijnen in de zelfstudie: Een bestaand aangepast SSL-certificaat binden aan Azure Web Apps.

Opties

De volgende gemarkeerde code, roept AddHttpsRedirection aan om middlewareopties te configureren.

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();

Het is alleen nodig om AddHttpsRedirection te bellen om de waarden van HttpsPort of RedirectStatusCode te veranderen.

De voorgaande gemarkeerde code:

• Wordt ingesteld HttpsRedirectionOptions.RedirectStatusCode op Status307TemporaryRedirect, wat de standaardwaarde is. Gebruik de velden van de StatusCodes klasse voor toewijzingen.RedirectStatusCode
• Hiermee stelt u de HTTPS-poort in op 5001.

Permanente omleidingen configureren in de productieomgeving

De middleware wordt standaard ingesteld op het verzenden van een Status307TemporaryRedirect met alle omleidingen. Als u liever een permanente omleidingsstatuscode verzendt wanneer de app zich in een niet-ontwikkelomgeving bevindt, verpakt u de configuratie van middlewareopties in een voorwaardelijke controle voor een niet-ontwikkelomgeving.

Bij het configureren van services in 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();

Alternatieve benadering van middleware voor HTTPS-omleiding

Een alternatief voor het gebruik van HTTPS Redirection Middleware (UseHttpsRedirection) is het gebruik van URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps kan ook de statuscode en poort instellen wanneer de omleiding wordt uitgevoerd. Voor meer informatie, zie URL-herschrijvingsmiddleware.

Wanneer u omleidt naar HTTPS zonder de vereiste voor aanvullende omleidingsregels, raden we u aan om Middleware () voor HTTPS-omleiding (UseHttpsRedirection) te gebruiken die in dit artikel wordt beschreven.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP is HTTP Strict Transport Security (HSTS) een opt-in-beveiligingsverbetering die wordt opgegeven door een web-app via het gebruik van een antwoordheader. Wanneer een browser die HSTS ondersteunt , deze header ontvangt:

• De browser slaat de configuratie op voor het domein dat voorkomt dat communicatie via HTTP wordt verzonden. De browser dwingt alle communicatie via HTTPS af.
• De browser voorkomt dat de gebruiker niet-vertrouwde of ongeldige certificaten gebruikt. De browser schakelt prompts uit waarmee een gebruiker een dergelijk certificaat tijdelijk kan vertrouwen.

Omdat HSTS wordt afgedwongen door de client, heeft deze enkele beperkingen:

• De client moet HSTS ondersteunen.
• HSTS vereist ten minste één geslaagde HTTPS-aanvraag om het HSTS-beleid vast te stellen.
• De toepassing moet elke HTTP-aanvraag controleren en de HTTP-aanvraag omleiden of afwijzen.

ASP.NET Core implementeert HSTS met de UseHsts extensiemethode. De volgende code roept aan UseHsts wanneer de app zich niet in de ontwikkelingsmodus bevindt:

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 wordt niet aanbevolen tijdens de ontwikkeling omdat de HSTS-instellingen sterk door browsers in de cache kunnen worden opgeslagen. UseHsts Sluit standaard het lokale loopback-adres uit.

Voor productieomgevingen die HTTPS voor de eerste keer implementeren, stelt u het begin HstsOptions.MaxAge in op een kleine waarde met behulp van een van de TimeSpan methoden. Stel de waarde van uren in op maximaal één dag voor het geval u de HTTPS-infrastructuur moet terugzetten naar HTTP. Nadat u vertrouwen hebt in de duurzaamheid van de HTTPS-configuratie, verhoogt u de HSTS-waarde max-age . Een veelgebruikte waarde is één jaar.

De volgende gemarkeerde code:

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();

• Hiermee stelt u de parameter preload van de Strict-Transport-Security header in. Preload maakt geen deel uit van de RFC HSTS-specificatie, maar wordt ondersteund door webbrowsers om HSTS-sites vooraf te laden op een nieuwe installatie. Zie https://hstspreload.org/ voor meer informatie.
• Hiermee schakelt u includeSubDomain in, waarmee het HSTS-beleid wordt toegepast op hostsubdomeinen.
• Hiermee stelt u de parameter van de max-ageStrict-Transport-Security header expliciet in op 60 dagen. Als er niets is ingesteld, is de standaardwaarde 30 dagen. Zie de richtlijn voor maximale leeftijd voor meer informatie.
• Voegt toe example.com aan de lijst met hosts die moeten worden uitgesloten.

UseHsts sluit de volgende loopback-hosts uit:

• localhost : het IPv4-loopbackadres.
• 127.0.0.1 : het IPv4-loopbackadres.
• [::1] : het IPv6-loopbackadres.

Afmelden voor HTTPS/HSTS bij het maken van een project

In sommige back-endservicescenario's waarbij verbindingsbeveiliging wordt verwerkt aan de openbare rand van het netwerk, is het configureren van verbindingsbeveiliging op elk knooppunt niet vereist. Web-apps die worden gegenereerd op basis van de sjablonen in Visual Studio of met de nieuwe dotnet-opdracht , schakelen HTTPS-omleiding en HSTS in. Voor implementaties waarvoor deze scenario's niet nodig zijn, kunt u zich afmelden voor HTTPS/HSTS wanneer de app wordt gemaakt op basis van de sjabloon.

Afmelden voor HTTPS/HSTS:

Visual Studio

Schakel het selectievakje Configureren voor HTTPS uit.

.NET CLI

Gebruik de optie --no-https. Bijvoorbeeld

dotnet new webapp --no-https

Het ASP.NET Core HTTPS-ontwikkelingscertificaat vertrouwen

De .NET Core SDK bevat een HTTPS-ontwikkelingscertificaat. Het certificaat wordt geïnstalleerd als onderdeel van de first-run-ervaring. Bijvoorbeeld, dotnet --info produceert een variatie van de volgende uitvoer:

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.

Als u de .NET Core SDK installeert, wordt het ASP.NET Core HTTPS-ontwikkelingscertificaat geïnstalleerd in het certificaatarchief van de lokale gebruiker. Het certificaat is geïnstalleerd, maar wordt niet vertrouwd. Als u het certificaat wilt vertrouwen, voert u de eenmalige stap uit om het dotnet dev-certs hulpprogramma uit te voeren:

dotnet dev-certs https --trust

De volgende opdracht biedt help voor de dotnet dev-certs tool:

dotnet dev-certs https --help

Waarschuwing

Maak geen ontwikkelingscertificaat aan in een omgeving die opnieuw wordt gedistribueerd, zoals een containerimage of een virtuele machine. Dit kan leiden tot spoofing en verhoging van bevoegdheden. Om dit te voorkomen, stelt u de omgevingsvariabele in op DOTNET_GENERATE_ASPNET_CERTIFICATE voordat u de .NET CLI voor de false eerste keer aanroept. Hiermee wordt het automatisch genereren van het ASP.NET Core-ontwikkelingscertificaat overgeslagen tijdens de eerste uitvoering van de CLI.

Een ontwikkelaarscertificaat instellen voor Docker

Zie dit GitHub-probleem.

Overwegingen die specifiek zijn voor Linux

Linux-distributies verschillen aanzienlijk in hoe ze certificaten markeren als vertrouwd. Hoewel dotnet dev-certs wordt verwacht dat het algemeen van toepassing is, wordt het alleen officieel ondersteund op Ubuntu en Fedora en is specifiek gericht op vertrouwen in Browsers op basis van Firefox en Chromium (Edge, Chrome en Chromium).

Afhankelijkheden

Om vertrouwen in OpenSSL vast te stellen, moet de openssl tool in het pad staan.

Als u browservertrouwen wilt instellen (bijvoorbeeld in Edge of Firefox), moet het certutil hulpprogramma zich op het pad bevinden.

OpenSSL-vertrouwensrelatie

Wanneer het ASP.NET Core-ontwikkelingscertificaat wordt vertrouwd, wordt het geëxporteerd naar een map in de basismap van de huidige gebruiker. Als u Wilt dat OpenSSL (en clients die deze gebruiken) deze map ophalen, moet u de SSL_CERT_DIR omgevingsvariabele instellen. U kunt dit in één sessie doen door een opdracht uit te voeren zoals export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (de exacte waarde wordt in de uitvoer weergegeven wanneer --verbose wordt doorgegeven) of door het toe te voegen aan uw (distributie- en shell-specifieke) configuratiebestand (bijvoorbeeld .profile).

Dit is vereist om hulpprogramma's curl zoals het ontwikkelingscertificaat te vertrouwen. U kunt -CAfile of -CApath ook aan iedere afzonderlijke curl aanroep doorgeven.

Houd er rekening mee dat hiervoor 1.1.1h of hoger of 3.0.0 of hoger is vereist, afhankelijk van de primaire versie die u gebruikt.

Als de OpenSSL-trust in een slechte staat terechtkomt (bijvoorbeeld als dotnet dev-certs https --clean het niet kan verwijderen), is het vaak mogelijk om de problemen op te lossen met behulp van het c_rehash hulpprogramma.

Overschrijvingen

Als u een andere browser met een eigen NSS-archief (Network Security Services) gebruikt, kunt u de DOTNET_DEV_CERTS_NSSDB_PATHS omgevingsvariabele gebruiken om een lijst met door dubbele punten gescheiden NSS-mappen (bijvoorbeeld de map met cert9.db) op te geven waaraan het ontwikkelingscertificaat moet worden toegevoegd.

Als u de certificaten opslaat die OpenSSL in een specifieke map moet vertrouwen, kunt u de DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY omgevingsvariabele gebruiken om aan te geven waar dat is.

Waarschuwing

Als u een van deze variabelen instelt, is het belangrijk dat ze worden ingesteld op dezelfde waarden wanneer de vertrouwensrelatie wordt bijgewerkt. Als ze veranderen, weet het hulpprogramma niets van de certificaten op de oude locaties (bijvoorbeeld om de certificaten op te schonen).

Gebruik maken van sudo

Net als op andere platforms worden ontwikkelingscertificaten afzonderlijk opgeslagen en vertrouwd voor elke gebruiker. Als u dotnet dev-certs als een andere gebruiker uitvoert (bijvoorbeeld met behulp van sudo), is het deze gebruiker (bijvoorbeeld root) die het ontwikkelingscertificaat vertrouwt.

HTTPS-certificaat in Linux vertrouwen met linux-dev-certs

linux-dev-certs is een opensource, door de community ondersteund . NET global-hulpprogramma dat een handige manier biedt om een ontwikkelaarscertificaat in Linux te maken en te vertrouwen. Het hulpprogramma wordt niet onderhouden of ondersteund door Microsoft.

Met de volgende opdrachten installeert u het hulpprogramma en maakt u een vertrouwd certificaat voor ontwikkelaars:

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

Zie de GitHub-opslagplaats linux-dev-certs voor meer informatie of om problemen te melden.

SUSE Linux Enterprise Server

Bekijk dit GitHub-probleem

Het oplossen van problemen met certificaten, zoals het certificaat dat niet vertrouwd wordt

Deze sectie biedt hulp wanneer het ASP.NET Core HTTPS-ontwikkelingscertificaat is geïnstalleerd en vertrouwd, maar u nog steeds browserwaarschuwingen hebt dat het certificaat niet wordt vertrouwd. Het ASP.NET Core HTTPS-ontwikkelingscertificaat wordt gebruikt door Kestrel.

Als u het IIS Express-certificaat wilt herstellen, raadpleegt u dit Stackoverflow-probleem .

Alle platforms - certificaat niet vertrouwd

Voer de volgende opdrachten uit:

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

Sluit alle browserexemplaren die zijn geopend. Open een nieuw browservenster naar de app. Certificaatvertrouwen wordt in de cache opgeslagen door browsers.

dotnet dev-certs https --clean mislukt

De voorgaande opdrachten lossen de meeste problemen met browservertrouwen op. Als de browser het certificaat nog steeds niet vertrouwt, volgt u de platformspecifieke suggesties die volgen.

Docker - certificaat niet vertrouwd

• Verwijder de map C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Maak de oplossing schoon. Verwijder de bin en obj-mappen.
• Start het ontwikkelhulpprogramma opnieuw op. Bijvoorbeeld Visual Studio of Visual Studio Code.

Windows - certificaat niet vertrouwd

• Controleer de certificaten in het certificaatarchief. Er moet een localhost certificaat zijn met de ASP.NET Core HTTPS development certificate vriendelijke naam bij zowel Current User > Personal > Certificates als Current User > Trusted root certification authorities > Certificates
• Verwijder alle gevonden certificaten van zowel persoonlijke als vertrouwde basiscertificeringsinstanties. Verwijder het IIS Express localhost-certificaat niet.
• Voer de volgende opdrachten uit:

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

Sluit alle browserexemplaren die zijn geopend. Open een nieuw browservenster naar de app.

OS X - certificaat niet vertrouwd

• Open Keychain Access.
• Selecteer de systeemsleutelhanger.
• Controleer op de aanwezigheid van een localhost-certificaat.
• Controleer of er op het pictogram een + symbool staat om aan te geven dat het betrouwbaar is voor alle gebruikers.
• Verwijder het certificaat uit de systeemsleutelhanger.
• Voer de volgende opdrachten uit:

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

Sluit alle browserexemplaren die zijn geopend. Open een nieuw browservenster naar de app.

Zie HTTPS-fout met IIS Express (dotnet/AspNetCore #16892) voor het oplossen van certificaatproblemen met Visual Studio.

Linux-certificaat wordt niet vertrouwd

Controleer of het certificaat dat wordt geconfigureerd voor vertrouwen, het HTTPS-ontwikkelaarscertificaat van de gebruiker is dat door de Kestrel server wordt gebruikt.

Controleer het standaard HTTPS-ontwikkelaarscertificaat Kestrel van de huidige gebruiker op de volgende locatie:

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

Het HTTPS-certificaatbestand voor ontwikkelaars Kestrel is de SHA1-vingerafdruk. Wanneer het bestand wordt verwijderd via dotnet dev-certs https --clean, wordt het opnieuw gegenereerd wanneer dit nodig is met een andere vingerafdruk. Controleer of de vingerafdruk van het geëxporteerde certificaat overeenkomt met de volgende opdracht:

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

Als het certificaat niet overeenkomt, kan dit een van de volgende zijn:

• Een oud certificaat.
• Een ontwikkelaarscertificaat werd geëxporteerd voor de hoofdgebruiker. Voor dit geval exporteert u het certificaat.

Het basisgebruikerscertificaat kan worden gecontroleerd op:

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

IIS Express SSL-certificaat dat wordt gebruikt met Visual Studio

Als u problemen met het IIS Express-certificaat wilt oplossen, selecteert u Herstellen in het Installatieprogramma van Visual Studio. Zie dit GitHub-probleemvoor meer informatie.

Groepsbeleid voorkomt dat zelfondertekende certificaten worden vertrouwd

In sommige gevallen kan groepsbeleid voorkomen dat zelfondertekende certificaten worden vertrouwd. Zie dit GitHub-probleemvoor meer informatie.

Aanvullende informatie

• Configureer ASP.NET Core voor gebruik met proxyservers en load balancers
• Host ASP.NET Core op Linux met Nginx: HTTPS-configuratie
• SSL instellen op IIS
• Eindpunten configureren voor de ASP.NET Core Kestrel webserver
• Ondersteuning voor OWASP HSTS-browser