Erzwingen von HTTPS in ASP.NET Core

Von Rick Anderson

In diesem Dokument wird folgendes beschrieben:

• Erfordern Sie HTTPS für alle Anforderungen.
• Leitet alle HTTP-Anforderungen an HTTPS um.

Keine API kann verhindern, dass ein Client vertrauliche Daten bei der ersten Anforderung sendet.

Warnung

API-Projekte

Verwenden RequireHttpsAttribute Sie keine Web-APIs, die vertrauliche Informationen empfangen. RequireHttpsAttribute verwendet HTTP-Statuscodes, um Browser von HTTP zu HTTPS umzuleiten. API-Clients verstehen oder befolgen möglicherweise keine Umleitungen von HTTP zu HTTPS. Solche Clients können Informationen über HTTP senden. Web-APIs sollten entweder:

• Nicht auf HTTP lauschen.
• Schließen Sie die Verbindung mit dem Statuscode 400 (Ungültige Anforderung), und stellen Sie die Anforderung nicht zu.

Um die HTTP-Umleitung in einer API zu deaktivieren, legen Sie die Umgebungsvariable ASPNETCORE_URLS fest, oder verwenden Sie das Befehlszeilenflag --urls . Weitere Informationen finden Sie unter Verwenden mehrerer Umgebungen in ASP.NET Core und 5 Möglichkeiten zum Festlegen der URLs für eine ASP.NET Core-App von Andrew Lock.

HSTS- und API-Projekte

Die Standard-API-Projekte enthalten HSTS nicht, da HSTS in der Regel nur eine Browseranweisung ist. Andere Anrufer, z. B. Telefon- oder Desktop-Apps, halten sich nicht an die Anweisungen. Selbst in Browsern birgt ein einzelner authentifizierter Aufruf einer API über HTTP Risiken für unsichere Netzwerke. Der sichere Ansatz besteht darin, API-Projekte so zu konfigurieren, dass sie nur über HTTPS lauschen und reagieren.

HTTP-Umleitung zu HTTPS verursacht ERR_INVALID_REDIRECT für die CORS-Preflight-Anforderung

Anforderungen an einen Endpunkt mithilfe von UseHttpsRedirection HTTP, die an HTTPS weitergeleitet werden, schlagen mit ERR_INVALID_REDIRECT on the CORS preflight requestfehl.

API-Projekte können HTTP-Anforderungen ablehnen, anstatt UseHttpsRedirection Anforderungen an HTTPS umzuleiten.

Erzwingen von HTTPS

Es wird empfohlen, für Produktions-ASP.NET Core-Web-Apps Folgendes zu verwenden:

• HTTPS-Umleitungs-Middleware (UseHttpsRedirection), um HTTP-Anforderungen an HTTPS umzuleiten.
• HSTS-Middleware (UseHsts) zum Senden von HTTP Strict Transport Security Protocol (HSTS)-Headern an Clients.

Hinweis

Apps, die in einer Reverseproxykonfiguration bereitgestellt werden, ermöglichen es dem Proxy, die Verbindungssicherheit (HTTPS) zu verarbeiten. Wenn der Proxy auch die HTTPS-Umleitung verarbeitet, muss keine HTTPS-Umleitungs-Middleware verwendet werden. Wenn der Proxyserver auch das Schreiben von HSTS-Headern verarbeitet (z . B. native HSTS-Unterstützung in IIS 10.0 (1709) oder höher), ist die HSTS-Middleware für die App nicht erforderlich. Weitere Informationen finden Sie unter Deaktivieren von HTTPS/HSTS bei der Projekterstellung.

UseHttpsRedirection

Der folgende Code ruft in der Datei auf UseHttpsRedirectionProgram.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();

Der oben hervorgehobene Code:

• Verwendet den Standardwert HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Verwendet den Standardwert HttpsRedirectionOptions.HttpsPort (NULL), es sei denn, es wird von der Umgebungsvariable ASPNETCORE_HTTPS_PORT oder IServerAddressesFeatureüberschrieben.

Es wird empfohlen, temporäre Umleitungen anstelle dauerhafter Umleitungen zu verwenden. Das Zwischenspeichern von Links kann in Entwicklungsumgebungen zu instabilem Verhalten führen. Wenn Sie lieber einen permanenten Umleitungsstatuscode senden möchten, wenn sich die App in einer Nicht-Entwicklungsumgebung befindet, lesen Sie den Abschnitt Konfigurieren permanenter Umleitungen in der Produktion . Es wird empfohlen, HSTS zu verwenden, um Clients zu signalisieren, dass nur sichere Ressourcenanforderungen an die App gesendet werden sollen (nur in der Produktion).

Portkonfiguration

Ein Port muss für die Middleware verfügbar sein, um eine unsichere Anforderung an HTTPS umzuleiten. Wenn kein Port verfügbar ist:

• Eine Umleitung zu HTTPS erfolgt nicht.
• Die Middleware protokolliert die Warnung "Fehler beim Ermitteln des https-Ports für die Umleitung".

Geben Sie den HTTPS-Port mit einem der folgenden Ansätze an:

• Legen Sie httpsRedirectionOptions.HttpsPort fest.

• Legen Sie die https_portHosteinstellung fest:

  • In der Hostkonfiguration.

  • Durch Festlegen der Umgebungsvariablen ASPNETCORE_HTTPS_PORT .

  • Durch Hinzufügen eines Eintrags auf oberster Ebene in appsettings.json:

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

• Geben Sie mithilfe der umgebungsvariablen ASPNETCORE_URLS einen Port mit dem sicheren Schema an. Die Umgebungsvariable konfiguriert den Server. Die Middleware ermittelt indirekt den HTTPS-Port über IServerAddressesFeature. Dieser Ansatz funktioniert nicht bei Reverseproxybereitstellungen.

• Die ASP.NET Core Webvorlagen legen eine HTTPS-URL Properties/launchsettings.json sowohl für als auch Kestrel für IIS Express fest. launchsettings.json wird nur auf dem lokalen Computer verwendet.

• Konfigurieren Sie einen HTTPS-URL-Endpunkt für eine öffentliche Edgebereitstellung von Kestrel Server oder HTTP.sys Server. Die App verwendet nur einen HTTPS-Port . Die Middleware ermittelt den Port über IServerAddressesFeature.

Hinweis

Wenn eine App in einer Reverseproxykonfiguration ausgeführt wird, IServerAddressesFeature ist nicht verfügbar. Legen Sie den Port mithilfe eines der anderen In diesem Abschnitt beschriebenen Ansätze fest.

Edgebereitstellungen

Wenn Kestrel oder HTTP.sys als öffentlicher Edgeserver verwendet wird oder HTTP.sys so konfiguriert werden muss, Kestrel dass beides überwacht wird:

• Der sichere Port, an dem der Client umgeleitet wird (in der Regel 443 in der Produktion und 5001 in der Entwicklung).
• Der unsichere Port (in der Regel 80 in der Produktion und 5000 in der Entwicklung).

Auf den unsicheren Port muss der Client zugreifen können, damit die App eine unsichere Anforderung empfangen und den Client an den sicheren Port umleiten kann.

Weitere Informationen finden Sie unter Kestrel Endpunktkonfiguration oder HTTP.sys Webserverimplementierung in ASP.NET Core.

Bereitstellungsszenarien

Für jede Firewall zwischen Client und Server müssen auch Kommunikationsports für Datenverkehr geöffnet sein.

Wenn Anforderungen in einer Reverseproxykonfiguration weitergeleitet werden, verwenden Sie Middleware für weitergeleitete Header , bevor Sie HTTPS-Umleitungs-Middleware aufrufen. Die Middleware für weitergeleitete Header aktualisiert den Request.Scheme- mithilfe des Headers X-Forwarded-Proto . Die Middleware ermöglicht umleitungs-URIs und andere Sicherheitsrichtlinien, dass sie ordnungsgemäß funktionieren. Wenn die Middleware für weitergeleitete Header nicht verwendet wird, erhält die Back-End-App möglicherweise nicht das richtige Schema und landet in einer Umleitungsschleife. Eine häufige Fehlermeldung des Endbenutzers ist, dass zu viele Umleitungen aufgetreten sind.

Befolgen Sie bei der Bereitstellung in Azure App Service die Anleitung unter Tutorial: Binden eines vorhandenen benutzerdefinierten SSL-Zertifikats an Azure Web-Apps.

Optionen

Die folgenden hervorgehobenen Codeaufrufe AddHttpsRedirection zum Konfigurieren von Middlewareoptionen:

using System.Net;

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 = (int)HttpStatusCode.TemporaryRedirect;
    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();

Das Aufrufen AddHttpsRedirection ist nur erforderlich, um die Werte von HttpsPort oder RedirectStatusCodezu ändern.

Der oben hervorgehobene Code:

• Legt HttpsRedirectionOptions.RedirectStatusCode auf fest Status307TemporaryRedirect, was der Standardwert ist. Verwenden Sie die Felder der StatusCodes -Klasse für Zuweisungen zu RedirectStatusCode.
• Legt den HTTPS-Port auf 5001 fest.

Konfigurieren dauerhafter Umleitungen in der Produktion

Die Middleware sendet standardmäßig eine Status307TemporaryRedirect mit allen Umleitungen. Wenn Sie es vorziehen, einen permanenten Umleitungsstatuscode zu senden, wenn sich die App in einer Nicht-Entwicklungsumgebung befindet, schließen Sie die Konfiguration der Middlewareoptionen in eine bedingte Überprüfung für eine Nicht-Entwicklungsumgebung ein.

Beim Konfigurieren von Diensten in Program.cs:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int)HttpStatusCode.PermanentRedirect;
        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();

Alternativer Ansatz der Middleware für die HTTPS-Umleitung

Eine Alternative zur Verwendung von HTTPS-Umleitungs-Middleware (UseHttpsRedirection) ist die Verwendung von URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps kann auch den Statuscode und den Port festlegen, wenn die Umleitung ausgeführt wird. Weitere Informationen finden Sie unter Url Rewriting Middleware.

Bei der Umleitung zu HTTPS ohne zusätzliche Umleitungsregeln wird empfohlen, die in diesem Thema beschriebene HTTPS-Umleitungs-Middleware (UseHttpsRedirection) zu verwenden.

HTTP Strict Transport Security Protocol (HSTS)

Gemäß OWASP ist HTTP Strict Transport Security (HSTS) eine opt-in-Sicherheitsverbesserung, die von einer Web-App durch die Verwendung eines Antwortheaders angegeben wird. Wenn ein Browser, der HSTS unterstützt, diesen Header empfängt:

• Der Browser speichert die Konfiguration für die Domäne, die das Senden von Kommunikation über HTTP verhindert. Der Browser erzwingt die gesamte Kommunikation über HTTPS.
• Der Browser verhindert, dass der Benutzer nicht vertrauenswürdige oder ungültige Zertifikate verwendet. Der Browser deaktiviert Eingabeaufforderungen, die es einem Benutzer ermöglichen, einem solchen Zertifikat vorübergehend zu vertrauen.

Da HSTS vom Client erzwungen wird, gelten einige Einschränkungen:

• Der Client muss HSTS unterstützen.
• HSTS erfordert mindestens eine erfolgreiche HTTPS-Anforderung, um die HSTS-Richtlinie einzurichten.
• Die Anwendung muss jede HTTP-Anforderung überprüfen und die HTTP-Anforderung umleiten oder ablehnen.

ASP.NET Core implementiert HSTS mit der UseHsts Erweiterungsmethode. Der folgende Code ruft auf UseHsts , wenn sich die App nicht im Entwicklungsmodus befindet:

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 wird in der Entwicklung nicht empfohlen, da die HSTS-Einstellungen von Browsern in hohem Maße zwischengespeichert werden können. Standardmäßig UseHsts schließt die lokale Loopbackadresse aus.

Legen Sie für Produktionsumgebungen, die HTTPS zum ersten Mal implementieren, den initial-Wert HstsOptions.MaxAge mithilfe einer der TimeSpan Methoden auf einen kleinen Wert fest. Legen Sie den Wert von Stunden auf nicht mehr als einen einzelnen Tag fest, falls Sie die HTTPS-Infrastruktur auf HTTP zurücksetzen müssen. Nachdem Sie von der Nachhaltigkeit der HTTPS-Konfiguration überzeugt sind, erhöhen Sie den HSTS-Wert max-age . Ein häufig verwendeter Wert ist ein Jahr.

Der hervorgehobene Code führt Folgendes aus:

using System.Net;

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 = (int)HttpStatusCode.TemporaryRedirect;
    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();

• Legt den Preload-Parameter des Strict-Transport-Security Headers fest. Das Vorabladen ist nicht Teil der RFC HSTS-Spezifikation, wird jedoch von Webbrowsern unterstützt, um HSTS-Websites bei der neu installierten Installation vorab zu laden. Weitere Informationen finden Sie unter https://hstspreload.org/.
• Aktiviert includeSubDomain, wodurch die HSTS-Richtlinie auf Hostunterdomänen angewendet wird.
• Legt den max-age Parameter des Headers Strict-Transport-Security explizit auf 60 Tage fest. Wenn nicht festgelegt, ist der Standardwert 30 Tage. Weitere Informationen finden Sie in der Max-age-Direktive.
• Fügt example.com der Liste der auszuschließenden Hosts hinzu.

UseHsts schließt die folgenden Loopbackhosts aus:

• localhost : Die IPv4-Loopbackadresse.
• 127.0.0.1 : Die IPv4-Loopbackadresse.
• [::1] : Die IPv6-Loopbackadresse.

Deaktivieren von HTTPS/HSTS bei der Projekterstellung

In einigen Back-End-Dienstszenarien, in denen die Verbindungssicherheit am öffentlichen Rand des Netzwerks behandelt wird, ist das Konfigurieren der Verbindungssicherheit auf jedem Knoten nicht erforderlich. Web-Apps, die aus den Vorlagen in Visual Studio oder dem Befehl dotnet new generiert werden, aktivieren HTTPS-Umleitung und HSTS. Für Bereitstellungen, die diese Szenarien nicht erfordern, können Sie HTTPS/HSTS deaktivieren, wenn die App aus der Vorlage erstellt wird.

So deaktivieren Sie HTTPS/HSTS:

Visual Studio

Deaktivieren Sie das Kontrollkästchen Für HTTPS konfigurieren .

.NET Core-CLI

Verwenden Sie die --no-https-Option. Beispiel:

dotnet new webapp --no-https

Vertrauen sie dem ASP.NET Core HTTPS-Entwicklungszertifikats unter Windows und macOS.

Informationen zum Firefox-Browser finden Sie im nächsten Abschnitt.

Das .NET Core SDK enthält ein HTTPS-Entwicklungszertifikat. Das Zertifikat wird im Rahmen der ersten Ausführung installiert. Erzeugt beispielsweise dotnet --info eine Variante der folgenden Ausgabe:

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.

Durch das Installieren des ASP.NET Core SDK wird das ASP.NET Core-HTTPS-Entwicklungszertifikat im lokalen Benutzerzertifikatspeicher installiert. Das Zertifikat wurde installiert, ist aber nicht vertrauenswürdig. Um dem Zertifikat zu vertrauen, führen Sie den einmaligen Schritt aus, um das dotnet-Tool dev-certs auszuführen:

dotnet dev-certs https --trust

Der folgende Befehl stellt Hilfe zum dev-certs-Tool bereit:

dotnet dev-certs https --help

Warnung

Erstellen Sie kein Entwicklungszertifikat in einer Umgebung, die verteilt wird, z. B. in einem Containerimage oder einem virtuellen Computer. Dies kann zu Spoofing und Rechteerweiterungen führen. Um dies zu verhindern, legen Sie die Umgebungsvariable DOTNET_GENERATE_ASPNET_CERTIFICATE auf fest false , bevor Sie die .NET CLI zum ersten Mal aufrufen. Dadurch wird die automatische Generierung des ASP.NET Core-Entwicklungszertifikats während der ersten Ausführung der CLI übersprungen.

Vertrauen Sie dem HTTPS-Zertifikat mit Firefox, um SEC_ERROR_INADEQUATE_KEY_USAGE Fehler zu verhindern.

Der Firefox-Browser verwendet einen eigenen Zertifikatspeicher und vertraut daher nicht den IIS Express- oder Kestrel Entwicklerzertifikaten.

Es gibt zwei Ansätze, um dem HTTPS-Zertifikat mit Firefox zu vertrauen, eine Richtliniendatei zu erstellen oder mit dem FireFox-Browser zu konfigurieren. Wenn Sie mit dem Browser konfigurieren, wird die Richtliniendatei erstellt, sodass die beiden Ansätze gleichwertig sind.

Erstellen einer Richtliniendatei zum Vertrauen des HTTPS-Zertifikats mit Firefox

Erstellen Sie eine Richtliniendatei unter:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\policies.json
• macOS: Firefox.app/Contents/Resources/distribution
• Linux: Weitere Informationen finden Sie unter Vertrauen auf das Zertifikat mit Firefox unter Linux in diesem Dokument.

Fügen Sie der Firefox-Richtliniendatei das folgende JSON hinzu:

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

Mit der vorherigen Richtliniendatei werden Firefox-Zertifikate aus den vertrauenswürdigen Zertifikaten im Windows-Zertifikatspeicher als vertrauenswürdig eingestuft. Der nächste Abschnitt bietet einen alternativen Ansatz zum Erstellen der vorherigen Richtliniendatei mithilfe des Firefox-Browsers.

Konfigurieren der Vertrauensstellung von HTTPS-Zertifikaten mithilfe des Firefox-Browsers

Legen Sie security.enterprise_roots.enabled = true die folgenden Anweisungen fest:

1. Geben Sie im FireFox-Browser ein about:config .
2. Wählen Sie Risiko annehmen und Weiter aus, wenn Sie das Risiko akzeptieren.
3. Wählen Sie Alle anzeigen aus.
4. Festgelegt security.enterprise_roots.enabled = true
5. Beenden und Neustarten von Firefox

Weitere Informationen finden Sie unter Einrichten von Zertifizierungsstellen (Certificate Authorities, CAs) in Firefox und in der Datei mozilla/policy-templates/README.

Einrichten eines Entwicklerzertifikats für Docker

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

HTTPS-Zertifikat unter Linux vertrauen

Das Einrichten von Vertrauensstellungen ist verteilungs- und browserspezifisch. Die folgenden Abschnitte enthalten Anweisungen für einige beliebte Distributionen und die Chromium Browser (Edge und Chrome) und für Firefox.

Ubuntu vertraut dem Zertifikat für die Dienst-zu-Dienst-Kommunikation.

Die folgenden Anweisungen funktionieren nicht für einige Ubuntu-Versionen, z. B. 20.04. Weitere Informationen finden Sie unter GitHub-Problem dotnet/AspNetCore.Docs #23686.

1. Installieren Sie OpenSSL 1.1.1h oder höher. Anweisungen zum Aktualisieren von OpenSSL finden Sie in Ihrer Distribution.

2. Führen Sie die folgenden Befehle aus:

   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
   

Die obenstehenden Befehle haben folgende Konsequenzen:

• Stellen Sie sicher, dass das Entwicklerzertifikat des aktuellen Benutzers erstellt wurde.
• Exportiert das Zertifikat mit erhöhten Berechtigungen, die für den ca-certificates Ordner erforderlich sind, und verwendet dabei die Umgebung des aktuellen Benutzers.
• Wenn Sie das -E Flag entfernen, wird das Stammbenutzerzertifikat exportiert und bei Bedarf generiert. Jedes neu generierte Zertifikat weist einen anderen Fingerabdruck auf. Wenn sie als Stamm ausgeführt wird und sudo-E nicht benötigt wird.

Der Pfad im vorherigen Befehl ist spezifisch für Ubuntu. Wählen Sie für andere Distributionen einen geeigneten Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (Certificate Authorities, CAs).

Vertrauenswürdiges HTTPS-Zertifikat unter Linux mit Edge oder Chrome

Für Chromium-Browser unter Linux:

• Installieren Sie die libnss3-tools für Ihre Verteilung.

• Erstellen oder überprüfen Sie, ob der $HOME/.pki/nssdb Ordner auf dem Computer vorhanden ist.

• Exportieren Sie das Zertifikat mit dem folgenden Befehl:

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

  Der Pfad im vorherigen Befehl ist spezifisch für Ubuntu. Wählen Sie für andere Distributionen einen geeigneten Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (Certificate Authorities, CAs).

• Führen Sie die folgenden Befehle aus:

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

• Beenden Sie den Browser, und starten Sie den Browser neu.

Vertrauen Des Zertifikats mit Firefox unter Linux

• Exportieren Sie das Zertifikat mit dem folgenden Befehl:

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

  Der Pfad im vorherigen Befehl ist spezifisch für Ubuntu. Wählen Sie für andere Distributionen einen geeigneten Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (Certificate Authorities, CAs).

• Erstellen Sie unter eine JSON-Datei /usr/lib/firefox/distribution/policies.json mit folgendem Inhalt:

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

Eine alternative Möglichkeit zum Konfigurieren der Richtliniendatei mithilfe des Browsers Firefox finden Sie unter Konfigurieren der Vertrauensstellung von HTTPS-Zertifikaten mit dem Firefox-Browser .

Vertrauen Sie dem Zertifikat mit Fedora 34

Thema

• Dieser GitHub-Kommentar
• Fedora: Verwenden von freigegebenen Systemzertifikaten
• Richten Sie eine .NET-Entwicklungsumgebung auf Fedora ein.

Vertrauenswürdiges Zertifikat mit anderen Distributionen

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

Https-Zertifikat aus Windows-Subsystem für Linux vertrauen

Die folgenden Anweisungen funktionieren nicht für einige Linux-Distributionen, z. B. Ubuntu 20.04. Weitere Informationen finden Sie unter GitHub-Problem dotnet/AspNetCore.Docs #23686.

Die Windows-Subsystem für Linux (WSL) generiert ein selbstsigniertes HTTPS-Entwicklungszertifikat, das in Windows standardmäßig nicht vertrauenswürdig ist. Die einfachste Möglichkeit, Windows dem WSL-Zertifikat zu vertrauen, besteht darin, WSL so zu konfigurieren, dass dasselbe Zertifikat wie Windows verwendet wird:

• Exportieren Sie unter Windows das Entwicklerzertifikat in eine Datei:

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

  Dabei $CREDENTIAL_PLACEHOLDER$ ist ein Kennwort.

• Importieren Sie in einem WSL-Fenster das exportierte Zertifikat für die WSL-Instanz:

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

Der vorherige Ansatz ist ein einmaliger Vorgang pro Zertifikat und pro WSL-Verteilung. Es ist einfacher, als das Zertifikat immer wieder zu exportieren. Wenn Sie das Zertifikat in Windows aktualisieren oder neu generieren, müssen Sie möglicherweise die oben genannten Befehle erneut ausführen.

Behandeln von Zertifikatproblemen, z. B. zertifikat nicht vertrauenswürdig

Dieser Abschnitt bietet Hilfe, wenn das ASP.NET Core HTTPS-Entwicklungszertifikats installiert und vertrauenswürdig ist. Sie erhalten jedoch weiterhin Browserwarnungen, dass das Zertifikat nicht vertrauenswürdig ist. Das ASP.NET Core HTTPS-Entwicklungszertifikats wird von Kestrelverwendet.

Informationen zum Reparieren des IIS Express Zertifikats finden Sie in diesem Stackoverflow-Problem.

Alle Plattformen: Zertifikat nicht vertrauenswürdig

Führen Sie die folgenden Befehle aus:

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

Schließen Sie alle geöffneten Browserinstanzen. Öffnen Sie ein neues Browserfenster für die App. Die Zertifikatvertrauensstellung wird von Browsern zwischengespeichert.

dotnet dev-certs https --clean schlägt fehl

Mit den obigen Befehlen werden die meisten Probleme mit der Browservertrauensstellung behoben. Wenn der Browser dem Zertifikat immer noch nicht vertraut, befolgen Sie die folgenden plattformspezifischen Vorschläge.

Docker: Zertifikat nicht vertrauenswürdig

• Löschen Sie den Ordner C:\Users{USER}\AppData\Roaming\ASP.NET\https .
• Bereinigen Sie die Lösung. Löschen Sie die Ordner bin und obj.
• Starten Sie das Entwicklungstool neu. Beispielsweise Visual Studio, Visual Studio Code oder Visual Studio für Mac.

Windows: Zertifikat nicht vertrauenswürdig

• Überprüfen Sie die Zertifikate im Zertifikatspeicher. Es sollte ein localhost Zertifikat mit dem ASP.NET Core HTTPS development certificate Anzeigenamen sowohl unter Current User > Personal > Certificates als auch Current User > Trusted root certification authorities > Certificates
• Entfernen Sie alle gefundenen Zertifikate von persönlichen und vertrauenswürdigen Stammzertifizierungsstellen. Entfernen Sie das IIS Express localhost-Zertifikat nicht.
• Führen Sie die folgenden Befehle aus:

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

Schließen Sie alle geöffneten Browserinstanzen. Öffnen Sie ein neues Browserfenster für die App.

OS X: Zertifikat nicht vertrauenswürdig

• Öffnen Sie KeyChain Access.
• Wählen Sie die Schlüsselkette System aus.
• Überprüfen Sie, ob ein localhost-Zertifikat vorhanden ist.
• Überprüfen Sie, ob es ein + Symbol auf dem Symbol enthält, um anzugeben, dass es für alle Benutzer vertrauenswürdig ist.
• Entfernen Sie das Zertifikat aus der Systemschlüsselkette.
• Führen Sie die folgenden Befehle aus:

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

Schließen Sie alle geöffneten Browserinstanzen. Öffnen Sie ein neues Browserfenster für die App.

Informationen zur Problembehandlung von Zertifikatproblemen mit Visual Studio finden Sie unter HTTPS-Fehler mithilfe von IIS Express (dotnet/AspNetCore #16892).

Linux-Zertifikat nicht vertrauenswürdig

Überprüfen Sie, ob das zertifikat, das für die Vertrauensstellung konfiguriert wird, das HTTPS-Entwicklerzertifikat des Benutzers ist, das Kestrel vom Server verwendet wird.

Überprüfen Sie das https-Standardentwicklerzertifikat Kestrel des aktuellen Benutzers am folgenden Speicherort:

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

Die HTTPS-Entwicklerzertifikatdatei Kestrel ist der SHA1-Fingerabdruck. Wenn die Datei über dotnet dev-certs https --cleangelöscht wird, wird sie bei Bedarf mit einem anderen Fingerabdruck neu generiert. Überprüfen Sie, ob der Fingerabdruck des exportierten Zertifikats mit dem folgenden Befehl übereinstimmt:

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

Wenn das Zertifikat nicht übereinstimmt, kann es eine der folgenden Sein:

• Ein altes Zertifikat.
• Ein exportiertes Entwicklerzertifikat für den Stammbenutzer. Exportieren Sie in diesem Fall das Zertifikat.

Das Stammbenutzerzertifikat kann unter überprüft werden:

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

IIS Express SSL-Zertifikat, das mit Visual Studio verwendet wird

Um Probleme mit dem IIS Express Zertifikat zu beheben, wählen Sie reparieren im Visual Studio-Installationsprogramm aus. Weitere Informationen finden Sie in diesem GitHub-Issue.

Gruppenrichtlinien verhindern, dass selbstsignierte Zertifikate als vertrauenswürdig eingestuft werden

In einigen Fällen kann die Gruppenrichtlinie verhindern, dass selbstsignierte Zertifikate als vertrauenswürdig eingestuft werden. Weitere Informationen finden Sie in diesem GitHub-Issue.

Zusätzliche Informationen

• Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich
• Hosten ASP.NET Core unter Linux mit Apache: HTTPS-Konfiguration
• Host ASP.NET Core unter Linux mit Nginx: HTTPS-Konfiguration
• Einrichten von SSL unter IIS
• Konfigurieren von Endpunkten für den -Webserver in ASP.NET Core
• OWASP HSTS-Browserunterstützung

Warnung

API-Projekte

Verwenden Sie RequireHttpsAttributenicht für Web-APIs, die vertrauliche Informationen empfangen. RequireHttpsAttribute verwendet HTTP-Statuscodes, um Browser von HTTP zu HTTPS umzuleiten. API-Clients verstehen oder befolgen möglicherweise keine Umleitungen von HTTP zu HTTPS. Solche Clients können Informationen über HTTP senden. Web-APIs sollten entweder:

• Nicht auf HTTP lauschen.
• Schließen Sie die Verbindung mit dem Statuscode 400 (ungültige Anforderung), und stellen Sie die Anforderung nicht zu.

Um die HTTP-Umleitung in einer API zu deaktivieren, legen Sie die Umgebungsvariable ASPNETCORE_URLS fest, oder verwenden Sie das Befehlszeilenflag --urls . Weitere Informationen finden Sie unter Verwenden mehrerer Umgebungen in ASP.NET Core und 5 Möglichkeiten zum Festlegen der URLs für eine ASP.NET Core-App von Andrew Lock.

HSTS- und API-Projekte

Die Standard-API-Projekte enthalten HSTS nicht, da HSTS im Allgemeinen eine reine Browseranweisung ist. Andere Anrufer, z. B. Telefon- oder Desktop-Apps, halten sich nicht an die Anweisungen. Selbst in Browsern birgt ein einzelner authentifizierter Aufruf einer API über HTTP Risiken für unsichere Netzwerke. Der sichere Ansatz besteht darin, API-Projekte so zu konfigurieren, dass sie nur über HTTPS lauschen und reagieren.

Erzwingen von HTTPS

Es wird empfohlen, für Produktions-ASP.NET Core-Web-Apps Folgendes zu verwenden:

• HTTPS-Umleitungs-Middleware (UseHttpsRedirection), um HTTP-Anforderungen an HTTPS umzuleiten.
• HSTS-Middleware (UseHsts) zum Senden von HTTP Strict Transport Security Protocol (HSTS)-Headern an Clients.

Hinweis

Apps, die in einer Reverseproxykonfiguration bereitgestellt werden, ermöglichen es dem Proxy, die Verbindungssicherheit (HTTPS) zu verarbeiten. Wenn der Proxy auch die HTTPS-Umleitung verarbeitet, muss keine HTTPS-Umleitungs-Middleware verwendet werden. Wenn der Proxyserver auch das Schreiben von HSTS-Headern verarbeitet (z . B. native HSTS-Unterstützung in IIS 10.0 (1709) oder höher), ist die HSTS-Middleware für die App nicht erforderlich. Weitere Informationen finden Sie unter Deaktivieren von HTTPS/HSTS bei der Projekterstellung.

UseHttpsRedirection

Der folgende Code ruft in der Startup -Klasse aufUseHttpsRedirection:

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

Der oben hervorgehobene Code:

• Verwendet den Standardwert HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Verwendet den Standardwert HttpsRedirectionOptions.HttpsPort (NULL), es sei denn, es wird von der Umgebungsvariable ASPNETCORE_HTTPS_PORT oder IServerAddressesFeatureüberschrieben.

Es wird empfohlen, temporäre Umleitungen anstelle dauerhafter Umleitungen zu verwenden. Das Zwischenspeichern von Links kann in Entwicklungsumgebungen zu instabilem Verhalten führen. Wenn Sie lieber einen permanenten Umleitungsstatuscode senden möchten, wenn sich die App in einer Nicht-Entwicklungsumgebung befindet, lesen Sie den Abschnitt Konfigurieren permanenter Umleitungen in der Produktion . Es wird empfohlen, HSTS zu verwenden, um Clients zu signalisieren, dass nur sichere Ressourcenanforderungen an die App gesendet werden sollen (nur in der Produktion).

Portkonfiguration

Ein Port muss für die Middleware verfügbar sein, um eine unsichere Anforderung an HTTPS umzuleiten. Wenn kein Port verfügbar ist:

• Eine Umleitung zu HTTPS erfolgt nicht.
• Die Middleware protokolliert die Warnung "Fehler beim Ermitteln des https-Ports für die Umleitung".

Geben Sie den HTTPS-Port mit einem der folgenden Ansätze an:

• Legen Sie httpsRedirectionOptions.HttpsPort fest.

• Legen Sie die https_portHosteinstellung fest:

  • In der Hostkonfiguration.

  • Durch Festlegen der Umgebungsvariablen ASPNETCORE_HTTPS_PORT .

  • Durch Hinzufügen eines Eintrags auf oberster Ebene in appsettings.json:

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

• Geben Sie mithilfe der umgebungsvariablen ASPNETCORE_URLS einen Port mit dem sicheren Schema an. Die Umgebungsvariable konfiguriert den Server. Die Middleware ermittelt indirekt den HTTPS-Port über IServerAddressesFeature. Dieser Ansatz funktioniert nicht bei Reverseproxybereitstellungen.

• Legen Sie in der Entwicklung eine HTTPS-URL in launchsettings.jsonfest. Aktivieren Sie HTTPS, wenn IIS Express verwendet wird.

• Konfigurieren Sie einen HTTPS-URL-Endpunkt für eine öffentliche Edgebereitstellung von Kestrel Server oder HTTP.sys Server. Die App verwendet nur einen HTTPS-Port . Die Middleware ermittelt den Port über IServerAddressesFeature.

Hinweis

Wenn eine App in einer Reverseproxykonfiguration ausgeführt wird, IServerAddressesFeature ist nicht verfügbar. Legen Sie den Port mithilfe eines der anderen In diesem Abschnitt beschriebenen Ansätze fest.

Edgebereitstellungen

Wenn Kestrel oder HTTP.sys als öffentlicher Edgeserver verwendet wird oder HTTP.sys konfiguriert werden muss, Kestrel um auf beiden zu lauschen:

• Der sichere Port, an dem der Client umgeleitet wird (in der Regel 443 in der Produktion und 5001 in der Entwicklung).
• Der unsichere Port (in der Regel 80 in der Produktion und 5000 in der Entwicklung).

Auf den unsicheren Port muss der Client zugreifen können, damit die App eine unsichere Anforderung empfangen und den Client an den sicheren Port umleiten kann.

Weitere Informationen finden Sie unter Kestrel Endpunktkonfiguration oder HTTP.sys Webserverimplementierung in ASP.NET Core.

Bereitstellungsszenarien

Für jede Firewall zwischen Client und Server müssen auch Kommunikationsports für Datenverkehr geöffnet sein.

Wenn Anforderungen in einer Reverseproxykonfiguration weitergeleitet werden, verwenden Sie Middleware für weitergeleitete Header , bevor Sie HTTPS-Umleitungs-Middleware aufrufen. Die Middleware für weitergeleitete Header aktualisiert den Request.Scheme- mithilfe des Headers X-Forwarded-Proto . Die Middleware ermöglicht umleitungs-URIs und andere Sicherheitsrichtlinien, dass sie ordnungsgemäß funktionieren. Wenn die Middleware für weitergeleitete Header nicht verwendet wird, erhält die Back-End-App möglicherweise nicht das richtige Schema und landet in einer Umleitungsschleife. Eine häufige Fehlermeldung des Endbenutzers ist, dass zu viele Umleitungen aufgetreten sind.

Befolgen Sie bei der Bereitstellung in Azure App Service die Anleitung unter Tutorial: Binden eines vorhandenen benutzerdefinierten SSL-Zertifikats an Azure Web-Apps.

Optionen

Die folgenden hervorgehobenen Codeaufrufe AddHttpsRedirection zum Konfigurieren von Middlewareoptionen:

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

Das Aufrufen AddHttpsRedirection ist nur erforderlich, um die Werte von HttpsPort oder RedirectStatusCodezu ändern.

Der oben hervorgehobene Code:

• Legt HttpsRedirectionOptions.RedirectStatusCode auf fest Status307TemporaryRedirect, was der Standardwert ist. Verwenden Sie die Felder der StatusCodes -Klasse für Zuweisungen zu RedirectStatusCode.
• Legt den HTTPS-Port auf 5001 fest.

Konfigurieren dauerhafter Umleitungen in der Produktion

Die Middleware sendet standardmäßig eine Status307TemporaryRedirect mit allen Umleitungen. Wenn Sie es vorziehen, einen permanenten Umleitungsstatuscode zu senden, wenn sich die App in einer Nicht-Entwicklungsumgebung befindet, schließen Sie die Konfiguration der Middlewareoptionen in eine bedingte Überprüfung für eine Nicht-Entwicklungsumgebung ein.

Beim Konfigurieren von Diensten in 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;
        });
    }
}

Alternativer Ansatz der Middleware für die HTTPS-Umleitung

Eine Alternative zur Verwendung von HTTPS-Umleitungs-Middleware (UseHttpsRedirection) ist die Verwendung von URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps kann auch den Statuscode und den Port festlegen, wenn die Umleitung ausgeführt wird. Weitere Informationen finden Sie unter Url Rewriting Middleware.

Bei der Umleitung zu HTTPS ohne zusätzliche Umleitungsregeln wird empfohlen, die in diesem Thema beschriebene HTTPS-Umleitungs-Middleware (UseHttpsRedirection) zu verwenden.

HTTP Strict Transport Security Protocol (HSTS)

Gemäß OWASP ist HTTP Strict Transport Security (HSTS) eine Opt-In-Sicherheitserweiterung, die von einer Web-App durch die Verwendung eines Antwortheaders angegeben wird. Wenn ein Browser, der HSTS unterstützt, diesen Header empfängt:

• Der Browser speichert die Konfiguration für die Domäne, die das Senden von Kommunikation über HTTP verhindert. Der Browser erzwingt die gesamte Kommunikation über HTTPS.
• Der Browser verhindert, dass der Benutzer nicht vertrauenswürdige oder ungültige Zertifikate verwendet. Der Browser deaktiviert Eingabeaufforderungen, die es einem Benutzer ermöglichen, einem solchen Zertifikat vorübergehend zu vertrauen.

Da HSTS vom Client erzwungen wird, gibt es einige Einschränkungen:

• Der Client muss HSTS unterstützen.
• HSTS erfordert mindestens eine erfolgreiche HTTPS-Anforderung, um die HSTS-Richtlinie einzurichten.
• Die Anwendung muss jede HTTP-Anforderung überprüfen und die HTTP-Anforderung umleiten oder ablehnen.

ASP.NET Core implementiert HSTS mit der UseHsts Erweiterungsmethode. Der folgende Code wird aufgerufen UseHsts , wenn sich die App nicht im Entwicklungsmodus befindet:

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 wird in der Entwicklung nicht empfohlen, da die HSTS-Einstellungen von Browsern in hohem Maße zwischengespeichert werden können. Standardmäßig UseHsts wird die lokale Loopbackadresse ausgeschlossen.

Legen Sie für Produktionsumgebungen, die HTTPS zum ersten Mal implementieren, den initialen HstsOptions.MaxAge Wert mithilfe einer der TimeSpan Methoden auf einen kleinen Wert fest. Legen Sie den Wert von Stunden auf nicht mehr als einen einzelnen Tag fest, falls Sie die HTTPS-Infrastruktur auf HTTP zurücksetzen müssen. Nachdem Sie von der Nachhaltigkeit der HTTPS-Konfiguration überzeugt sind, erhöhen Sie den HSTS-Wert max-age ; ein häufig verwendeter Wert ist ein Jahr.

Der folgende Code

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

• Legt den Preload-Parameter des Headers Strict-Transport-Security fest. Preload ist nicht Teil der RFC-HSTS-Spezifikation, wird aber von Webbrowsern unterstützt, um HSTS-Websites bei der Neuinstallation vorab zu laden. Weitere Informationen finden Sie unter https://hstspreload.org/.
• Aktiviert includeSubDomain, das die HSTS-Richtlinie auf Hostunterdomänen anwendet.
• Legt den max-age Parameter des Headers Strict-Transport-Security explizit auf 60 Tage fest. Wenn nicht festgelegt, wird der Standardwert auf 30 Tage festgelegt. Weitere Informationen finden Sie in der Max-Age-Anweisung.
• Fügt example.com der Liste der auszuschließenden Hosts hinzu.

UseHsts schließt die folgenden Loopbackhosts aus:

• localhost : Die IPv4-Loopbackadresse.
• 127.0.0.1 : Die IPv4-Loopbackadresse.
• [::1] : Die IPv6-Loopbackadresse.

Deaktivieren von HTTPS/HSTS bei der Projekterstellung

In einigen Back-End-Dienstszenarien, in denen die Verbindungssicherheit am öffentlichen Rand des Netzwerks behandelt wird, ist das Konfigurieren der Verbindungssicherheit auf jedem Knoten nicht erforderlich. Web-Apps, die aus den Vorlagen in Visual Studio oder dem Befehl dotnet new generiert werden, aktivieren HTTPS-Umleitung und HSTS. Für Bereitstellungen, die diese Szenarien nicht erfordern, können Sie HTTPS/HSTS deaktivieren, wenn die App aus der Vorlage erstellt wird.

So deaktivieren Sie HTTPS/HSTS:

Visual Studio

Deaktivieren Sie das Kontrollkästchen Für HTTPS konfigurieren .

.NET Core-CLI

Verwenden Sie die --no-https-Option. Beispiel:

dotnet new webapp --no-https

Vertrauen sie dem ASP.NET Core HTTPS-Entwicklungszertifikats unter Windows und macOS.

Informationen zum Firefox-Browser finden Sie im nächsten Abschnitt.

Das .NET Core SDK enthält ein HTTPS-Entwicklungszertifikat. Das Zertifikat wird im Rahmen der ersten Ausführung installiert. Erzeugt beispielsweise dotnet --info eine Variante der folgenden Ausgabe:

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.

Durch das Installieren des ASP.NET Core SDK wird das ASP.NET Core-HTTPS-Entwicklungszertifikat im lokalen Benutzerzertifikatspeicher installiert. Das Zertifikat wurde installiert, ist aber nicht vertrauenswürdig. Um dem Zertifikat zu vertrauen, führen Sie den einmaligen Schritt aus, um das dotnet-Tool dev-certs auszuführen:

dotnet dev-certs https --trust

Der folgende Befehl stellt Hilfe zum dev-certs-Tool bereit:

dotnet dev-certs https --help

Warnung

Erstellen Sie kein Entwicklungszertifikat in einer Umgebung, die verteilt wird, z. B. in einem Containerimage oder einem virtuellen Computer. Dies kann zu Spoofing und Rechteerweiterungen führen. Um dies zu verhindern, legen Sie die Umgebungsvariable DOTNET_GENERATE_ASPNET_CERTIFICATE auf fest false , bevor Sie die .NET CLI zum ersten Mal aufrufen. Dadurch wird die automatische Generierung des ASP.NET Core-Entwicklungszertifikats während der ersten Ausführung der CLI übersprungen.

Vertrauen Sie dem HTTPS-Zertifikat mit Firefox, um SEC_ERROR_INADEQUATE_KEY_USAGE Fehler zu verhindern.

Der Firefox-Browser verwendet einen eigenen Zertifikatspeicher und vertraut daher nicht den IIS Express- oder Kestrel Entwicklerzertifikaten.

Es gibt zwei Ansätze, um dem HTTPS-Zertifikat mit Firefox zu vertrauen, eine Richtliniendatei zu erstellen oder mit dem FireFox-Browser zu konfigurieren. Wenn Sie mit dem Browser konfigurieren, wird die Richtliniendatei erstellt, sodass die beiden Ansätze gleichwertig sind.

Erstellen einer Richtliniendatei zum Vertrauen des HTTPS-Zertifikats mit Firefox

Erstellen Sie eine Richtliniendatei unter:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\policies.json
• macOS: Firefox.app/Contents/Resources/distribution
• Linux: Weitere Informationen finden Sie unter Vertrauen auf das Zertifikat mit Firefox unter Linux in diesem Dokument.

Fügen Sie der Firefox-Richtliniendatei das folgende JSON hinzu:

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

Mit der vorherigen Richtliniendatei werden Firefox-Zertifikate aus den vertrauenswürdigen Zertifikaten im Windows-Zertifikatspeicher als vertrauenswürdig eingestuft. Der nächste Abschnitt bietet einen alternativen Ansatz zum Erstellen der vorherigen Richtliniendatei mithilfe des Firefox-Browsers.

Konfigurieren der Vertrauensstellung von HTTPS-Zertifikaten mithilfe des Firefox-Browsers

Legen Sie security.enterprise_roots.enabled = true die folgenden Anweisungen fest:

1. Geben Sie im FireFox-Browser ein about:config .
2. Wählen Sie Risiko annehmen und Weiter aus, wenn Sie das Risiko akzeptieren.
3. Wählen Sie Alle anzeigen aus.
4. Festgelegt security.enterprise_roots.enabled = true
5. Beenden und Neustarten von Firefox

Weitere Informationen finden Sie unter Einrichten von Zertifizierungsstellen (Certificate Authorities, CAs) in Firefox und in der Datei mozilla/policy-templates/README.

Einrichten eines Entwicklerzertifikats für Docker

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

HTTPS-Zertifikat unter Linux vertrauen

Das Einrichten von Vertrauensstellungen ist verteilungs- und browserspezifisch. Die folgenden Abschnitte enthalten Anweisungen für einige beliebte Distributionen und die Chromium Browser (Edge und Chrome) und für Firefox.

Ubuntu vertraut dem Zertifikat für die Dienst-zu-Dienst-Kommunikation.

1. Installieren Sie OpenSSL 1.1.1h oder höher. Anweisungen zum Aktualisieren von OpenSSL finden Sie in Ihrer Distribution.

2. Führen Sie die folgenden Befehle aus:

   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
   

Die obenstehenden Befehle haben folgende Konsequenzen:

• Stellen Sie sicher, dass das Entwicklerzertifikat des aktuellen Benutzers erstellt wurde.
• Exportiert das Zertifikat mit erhöhten Berechtigungen, die für den ca-certificates Ordner erforderlich sind, und verwendet dabei die Umgebung des aktuellen Benutzers.
• Wenn Sie das -E Flag entfernen, wird das Stammbenutzerzertifikat exportiert und bei Bedarf generiert. Jedes neu generierte Zertifikat weist einen anderen Fingerabdruck auf. Wenn sie als Stamm ausgeführt wird und sudo-E nicht benötigt wird.

Der Pfad im vorherigen Befehl ist spezifisch für Ubuntu. Wählen Sie für andere Distributionen einen geeigneten Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (Certificate Authorities, CAs).

Vertrauenswürdiges HTTPS-Zertifikat unter Linux mit Edge oder Chrome

Für Chromium-Browser unter Linux:

• Installieren Sie die libnss3-tools für Ihre Verteilung.

• Erstellen oder überprüfen Sie, ob der $HOME/.pki/nssdb Ordner auf dem Computer vorhanden ist.

• Exportieren Sie das Zertifikat mit dem folgenden Befehl:

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

  Der Pfad im vorherigen Befehl ist spezifisch für Ubuntu. Wählen Sie für andere Distributionen einen geeigneten Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (Certificate Authorities, CAs).

• Führen Sie die folgenden Befehle aus:

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

• Beenden Sie den Browser, und starten Sie den Browser neu.

Vertrauen Des Zertifikats mit Firefox unter Linux

• Exportieren Sie das Zertifikat mit dem folgenden Befehl:

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

  Der Pfad im vorherigen Befehl ist spezifisch für Ubuntu. Wählen Sie für andere Distributionen einen geeigneten Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (Certificate Authorities, CAs).

• Erstellen Sie unter eine JSON-Datei /usr/lib/firefox/distribution/policies.json mit folgendem Inhalt:

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

Eine alternative Möglichkeit zum Konfigurieren der Richtliniendatei mithilfe des Browsers Firefox finden Sie unter Konfigurieren der Vertrauensstellung von HTTPS-Zertifikaten mit dem Firefox-Browser .

Vertrauen Sie dem Zertifikat mit Fedora 34

Firefox auf 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

Vertrauen Sie dotnet-to-dotnet auf Fedora

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

Weitere Informationen finden Sie in diesem GitHub-Kommentar .

Vertrauenswürdiges Zertifikat mit anderen Distributionen

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

Https-Zertifikat aus Windows-Subsystem für Linux vertrauen

Die Windows-Subsystem für Linux (WSL) generiert ein selbstsigniertes HTTPS-Entwicklungszertifikat. So konfigurieren Sie den Windows-Zertifikatspeicher so, dass er dem WSL-Zertifikat vertraut:

• Exportieren Sie das Entwicklerzertifikat in eine Datei unter Windows:

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

  Dabei $CREDENTIAL_PLACEHOLDER$ ist ein Kennwort.

• Importieren Sie in einem WSL-Fenster das exportierte Zertifikat für die WSL-Instanz:

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

Der vorherige Ansatz ist ein einmaliger Vorgang pro Zertifikat und pro WSL-Verteilung. Es ist einfacher, als das Zertifikat immer wieder zu exportieren. Wenn Sie das Zertifikat in Windows aktualisieren oder neu generieren, müssen Sie möglicherweise die oben genannten Befehle erneut ausführen.

Behandeln von Zertifikatproblemen, z. B. zertifikat nicht vertrauenswürdig

Dieser Abschnitt bietet Hilfe, wenn das ASP.NET Core HTTPS-Entwicklungszertifikats installiert und vertrauenswürdig ist. Sie erhalten jedoch weiterhin Browserwarnungen, dass das Zertifikat nicht vertrauenswürdig ist. Das ASP.NET Core HTTPS-Entwicklungszertifikats wird von Kestrelverwendet.

Informationen zum Reparieren des IIS Express-Zertifikats finden Sie in diesem Stackoverflow-Problem.

Alle Plattformen : Zertifikat nicht vertrauenswürdig

Führen Sie die folgenden Befehle aus:

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

Schließen Sie alle geöffneten Browserinstanzen. Öffnen Sie ein neues Browserfenster für die App. Die Zertifikatvertrauensstellung wird von Browsern zwischengespeichert.

dotnet dev-certs https --clean Fails

Mit den vorherigen Befehlen werden die meisten Probleme mit der Browservertrauensstellung behoben. Wenn der Browser dem Zertifikat weiterhin nicht vertraut, befolgen Sie die folgenden plattformspezifischen Vorschläge.

Docker : Zertifikat nicht vertrauenswürdig

• Löschen Sie den Ordner C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Bereinigen Sie die Lösung. Löschen Sie die Ordner bin und obj.
• Starten Sie das Entwicklungstool neu. Beispiel: Visual Studio, Visual Studio Code oder Visual Studio für Mac.

Windows: Zertifikat nicht vertrauenswürdig

• Überprüfen Sie die Zertifikate im Zertifikatspeicher. Es sollte ein localhost Zertifikat mit dem ASP.NET Core HTTPS development certificate Anzeigenamen unter Current User > Personal > Certificates und vorhanden sein. Current User > Trusted root certification authorities > Certificates
• Entfernen Sie alle gefundenen Zertifikate von persönlichen und vertrauenswürdigen Stammzertifizierungsstellen. Entfernen Sie das IIS Express localhost-Zertifikat nicht.
• Führen Sie die folgenden Befehle aus:

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

Schließen Sie alle geöffneten Browserinstanzen. Öffnen Sie ein neues Browserfenster für die App.

OS X: Zertifikat nicht vertrauenswürdig

• Öffnen Sie KeyChain Access.
• Wählen Sie den Systemschlüsselbund aus.
• Überprüfen Sie, ob ein localhost-Zertifikat vorhanden ist.
• Überprüfen Sie, ob es ein + Symbol auf dem Symbol enthält, um anzugeben, dass es für alle Benutzer vertrauenswürdig ist.
• Entfernen Sie das Zertifikat aus dem Systemschlüsselbund.
• Führen Sie die folgenden Befehle aus:

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

Schließen Sie alle geöffneten Browserinstanzen. Öffnen Sie ein neues Browserfenster für die App.

Informationen zur Problembehandlung von Zertifikatproblemen mit Visual Studio finden Sie unter HTTPS-Fehler mit IIS Express (dotnet/AspNetCore #16892).

Linux-Zertifikat nicht vertrauenswürdig

Vergewissern Sie sich, dass das zertifikat, das für die Vertrauensstellung konfiguriert wird, das HTTPS-Entwicklerzertifikat des Benutzers ist, das Kestrel vom Server verwendet wird.

Überprüfen Sie das aktuelle HTTPS-Standard-Entwicklerzertifikat Kestrel des Benutzers am folgenden Speicherort:

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

Die HTTPS-Entwicklerzertifikatdatei Kestrel ist der SHA1-Fingerabdruck. Wenn die Datei über dotnet dev-certs https --cleangelöscht wird, wird sie bei Bedarf mit einem anderen Fingerabdruck neu generiert. Überprüfen Sie den Fingerabdruck des exportierten Zertifikats mit dem folgenden Befehl:

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

Wenn das Zertifikat nicht übereinstimmt, kann es sich um folgendes handeln:

• Ein altes Zertifikat.
• Ein exportiertes Entwicklerzertifikat für den Stammbenutzer. Exportieren Sie in diesem Fall das Zertifikat.

Das Stammbenutzerzertifikat kann unter überprüft werden:

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

IIS Express SSL-Zertifikat, das mit Visual Studio verwendet wird

Um Probleme mit dem IIS Express-Zertifikat zu beheben, wählen Sie reparieren im Visual Studio-Installationsprogramm aus. Weitere Informationen finden Sie in diesem GitHub-Issue.

Zusätzliche Informationen

• Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich
• Hosten ASP.NET Core unter Linux mit Apache: HTTPS-Konfiguration
• Hosten ASP.NET Core unter Linux mit Nginx: HTTPS-Konfiguration
• Einrichten von SSL unter IIS
• OWASP HSTS-Browserunterstützung
• dotnet dev-certs