Erzwingen von HTTPS in ASP.NET Core

Von Rick Anderson

In diesem Dokument wird gezeigt, wie:

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

Keine API kann verhindern, dass ein Client vertrauliche Daten an die erste Anforderung sendet.

Warnung

API-Projekte

Verwenden RequireHttpsAttribute Sie nicht auf 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 hören.
  • Schließen Sie die Verbindung mit Statuscode 400 (Ungültige Anforderung) und dienen Sie nicht der Anforderung.

Um die HTTP-Umleitung in einer API zu deaktivieren, legen Sie die ASPNETCORE_URLS Umgebungsvariable fest, oder verwenden Sie das --urls Befehlszeilen flag. 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 nur eine Browseranweisung ist. Andere Anrufer, z. B. Telefon- oder Desktop-Apps, befolgen die Anweisung nicht . Auch in Browsern hat ein einzelner authentifizierter Aufruf einer API über HTTP Risiken für unsichere Netzwerke. Der sichere Ansatz besteht darin, API-Projekte so zu konfigurieren, dass nur ÜBER HTTPS zu hören und darauf zu reagieren.

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

Anforderungen an einen Endpunkt mithilfe von HTTP, die an HTTPS umgeleitet werden, indem UseHttpsRedirection ein Fehler auftritt ERR_INVALID_REDIRECT on the CORS preflight request.

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

Erzwingen von HTTPS

Es wird empfohlen, die Produktion ASP.NET Core Web-Apps zu verwenden:

  • HTTPS Redirection Middleware (UseHttpsRedirection) zum Umleiten von HTTP-Anforderungen an HTTPS.
  • 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 behandeln. Wenn der Proxy auch HTTPS-Umleitung behandelt, 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 HSTS Middleware nicht von der App erforderlich. Weitere Informationen finden Sie unter "Abmelden von HTTPS/HSTS" zur Projekterstellung.

UseHttpsRedirection

Der folgende Code ruft in der Program.cs Datei aufUseHttpsRedirection:

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 vorherige hervorgehobene Code:

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 "Permanente Umleitungen konfigurieren" im Produktionsabschnitt . 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:

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

Geben Sie den HTTPS-Port mithilfe einer der folgenden Ansätze an:

  • Legen Sie httpsRedirectionOptions.HttpsPort fest.

  • Festlegen der https_portHosteinstellung:

    • In der Hostkonfiguration.

    • Durch Festlegen der ASPNETCORE_HTTPS_PORT Umgebungsvariable.

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

      {
        "https_port": 443,
        "Logging": {
          "LogLevel": {
            "Default": "Information",
            "Microsoft.AspNetCore": "Warning"
          }
        },
        "AllowedHosts": "*"
      }
      
  • Geben Sie einen Port mit dem sicheren Schema mithilfe der umgebungsvariablen ASPNETCORE_URLS an. Die Umgebungsvariable konfiguriert den Server. Die Middleware erkennt indirekt den HTTPS-Port über IServerAddressesFeature. Dieser Ansatz funktioniert nicht in Reverseproxybereitstellungen.

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

  • Konfigurieren Sie einen HTTPS-URL-Endpunkt für eine öffentliche Edgebereitstellung von Kestrel Servern oder HTTP.sys Server. Nur ein HTTPS-Port wird von der App verwendet. Die Middleware entdeckt den Port über IServerAddressesFeature.

Hinweis

Wenn eine App in einer Reverseproxykonfiguration ausgeführt wird, IServerAddressesFeature ist diese 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 öffentlich zugänglicher Edgeserver verwendet wird oder HTTP.sys so konfiguriert werden müssen, Kestrel dass beides überwacht werden kann:

  • 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).

Der unsichere Port muss vom Client zugänglich sein, damit die App eine unsichere Anforderung erhält und den Client an den sicheren Port umleitet.

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

Bereitstellungsszenarien

Jede Firewall zwischen Client und Server muss auch kommunikationsports für Datenverkehr geöffnet sein.

Wenn Anforderungen in einer Reverseproxykonfiguration weitergeleitet werden, verwenden Sie Forwarded Headers Middleware , bevor Sie HTTPS Redirection Middleware aufrufen. Weitergeleitete Headers Middleware aktualisiert die Request.Scheme, mithilfe der X-Forwarded-Proto Kopfzeile. Die Middleware ermöglicht umleitungs-URIs und andere Sicherheitsrichtlinien, die ordnungsgemäß funktionieren. Wenn forwarded Headers Middleware nicht verwendet wird, erhält die Back-End-App möglicherweise nicht das richtige Schema und endet in einer Umleitungsschleife. Eine allgemeine Fehlermeldung des Endbenutzers besteht darin, dass zu viele Umleitungen aufgetreten sind.

Folgen Sie beim Bereitstellen in Azure App Service den Anleitungen im Lernprogramm: 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 RedirectStatusCode.

Der vorherige hervorgehobene Code:

Konfigurieren von permanenten Umleitungen in der Produktion

Die Middleware ist standardmäßig auf das Senden einer Status307TemporaryRedirect Mit allen Umleitungen festgelegt. Wenn Sie lieber einen permanenten Umleitungsstatuscode senden möchten, wenn sich die App in einer Nicht-Entwicklungsumgebung befindet, schließen Sie die Middlewareoptionenkonfiguration in eine bedingte Überprüfung für eine Nicht-Entwicklungsumgebung um.

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 für HTTPS-Umleitungs-Middleware

Eine Alternative zur Verwendung von HTTPS Redirection Middleware () besteht darin, DIE URL-Neuschreibung von Middleware (UseHttpsRedirectionAddRedirectToHttps) zu verwenden. AddRedirectToHttps kann auch den Statuscode und den Port festlegen, wenn die Umleitung ausgeführt wird. Weitere Informationen finden Sie unter URL Rewriting Middleware.

Wenn Sie auf HTTPS umgeleitet werden, ohne dass zusätzliche Umleitungsregeln erforderlich sind, empfehlen wir die Verwendung von HTTPS-Umleitungs-Middleware (UseHttpsRedirection) in diesem Thema.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP ist HTTP Strict Transport Security (HSTS) eine Opt-In-Sicherheitsverbesserung, die von einer Web-App über die Verwendung eines Antwortheaders angegeben wird. Wenn ein Browser, der HSTS unterstützt, diesen Header erhält:

  • Der Browser speichert die Konfiguration für die Domäne, die das Senden einer 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, mit denen ein Benutzer vorübergehend einem solchen Zertifikat vertrauen kann.

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 ruft auf, wenn sich die App nicht im Entwicklungsmodus befindetUseHsts:

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 sehr zwischengespeichert werden können. Schließt standardmäßig UseHsts die lokale Loopbackadresse aus.

Legen Sie für Produktionsumgebungen, die HTTPS zum ersten Mal implementieren, den anfangs HstsOptions.MaxAge auf einen kleinen Wert mit einer der TimeSpan Methoden 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 sich auf die Nachhaltigkeit der HTTPS-Konfiguration verlassen haben, erhöhen Sie den HSTS-Wert max-age ; ein häufig verwendeter Wert ist ein Jahr.

Der folgende hervorgehobene Code:

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. Preload ist nicht Teil der RFC HSTS-Spezifikation, wird jedoch von Webbrowsern unterstützt, um HSTS-Websites auf der neu installierten Installation vorab zu laden. Weitere Informationen finden Sie unter https://hstspreload.org/.
  • Aktiviert includeSubDomain, die die HSTS-Richtlinie auf Hostdomänen anwendet.
  • Legt den max-age Parameter des Strict-Transport-Security Headers explizit auf 60 Tage fest. Wenn dies nicht festgelegt ist, werden die Standardwerte auf 30 Tage festgelegt. Weitere Informationen finden Sie in der Max-Age-Richtlinie.
  • Fügt example.com zur Liste der Hosts hinzu, die ausgeschlossen werden sollen.

UseHsts schließt die folgenden Loopbackhosts aus:

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

Abmelden von HTTPS/HSTS bei der Projekterstellung

In einigen Back-End-Dienstszenarien, in denen die Verbindungssicherheit am öffentlichen Rand des Netzwerks behandelt wird, ist die Konfiguration der Verbindungssicherheit bei jedem Knoten nicht erforderlich. Web-Apps, die aus den Vorlagen in Visual Studio oder aus dem dotnet neuen Befehl 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:

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

Das Dialogfeld

Vertrauen Sie dem ASP.NET Core HTTPS-Entwicklungszertifikat 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 als Teil der Ersten Ausführung installiert. Erzeugt beispielsweise dotnet --info eine Variation 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, aber es ist nicht vertrauenswürdig. Führen Sie zum Vertrauen des Zertifikats 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 neu verteilt wird, z. B. ein Containerimage oder einen virtuellen Computer. Dies kann zu Spoofing und Erhöhung von Berechtigungen führen. Um dies zu verhindern, legen Sie die DOTNET_GENERATE_ASPNET_CERTIFICATE Umgebungsvariable false vor dem erstmaligen Aufrufen der .NET CLI fest. 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. Die Konfiguration mit dem Browser erstellt die Richtliniendatei, sodass die beiden Ansätze gleichwertig sind.

Erstellen einer Richtliniendatei zum Vertrauen des HTTPS-Zertifikats mit Firefox

Erstellen einer Richtliniendatei unter:

Fügen Sie die folgende JSON-Datei zur Firefox-Richtliniendatei hinzu:

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

Die vorherige Richtliniendatei macht Firefox-vertrauenswürdige Zertifikate aus den vertrauenswürdigen Zertifikaten im Windows-Zertifikatspeicher. Der nächste Abschnitt bietet einen alternativen Ansatz zum Erstellen der vorherigen Richtliniendatei mithilfe des Firefox-Browsers.

Konfigurieren der Vertrauensstellung des HTTPS-Zertifikats mithilfe des Firefox-Browsers

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

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

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

Einrichten eines Entwicklerzertifikats für Docker

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

HTTPS-Zertifikat auf Linux vertrauen

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

Ubuntu vertrauen dem Zertifikat für die Dienst-zu-Service-Kommunikation

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

  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 wird.
  • Exportiert das Zertifikat mit erhöhten Berechtigungen, die für den ca-certificates Ordner erforderlich sind, und verwendet die Umgebung des aktuellen Benutzers.
  • Wenn Sie das -E Flag entfernen, wird das Stammbenutzerzertifikat exportiert, falls erforderlich. Jedes neu generierte Zertifikat hat einen anderen Fingerabdruck. Wenn Sie als Stamm ausgeführt werden und sudo-E nicht benötigt werden.

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

HTTPS-Zertifikat auf Linux mit Edge oder Chrome vertrauen

Für Chromium-Browser unter Linux:

  • Installieren Sie die libnss3-tools Verteilung 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 für Ubuntu spezifisch. Wählen Sie für andere Verteilungen 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 Sie dem Zertifikat 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 für Ubuntu spezifisch. Wählen Sie für andere Verteilungen einen geeigneten Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (Certificate Authorities, CAs).

  • Erstellen Sie eine JSON-Datei mit /usr/lib/firefox/distribution/policies.json den folgenden Inhalten:

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

Siehe Konfigurieren der Vertrauensstellung von HTTPS-Zertifikaten mithilfe des Firefox-Browsers in diesem Dokument, um die Richtliniendatei mithilfe des Browsers zu konfigurieren.

Vertrauen Sie dem Zertifikat mit Fedora 34

Sehen Sie sich diesen GitHub-Kommentar an.

Vertrauen Sie dem Zertifikat mit anderen Vertrommen

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

HTTPS-Zertifikat von Windows-Subsystem für Linux vertrauen

Das Windows-Subsystem für Linux (WSL) generiert ein selbstsigniertes HTTPS-Entwicklungszertifikat. So konfigurieren Sie den Windows-Zertifikatspeicher, um dem WSL-Zertifikat zu vertrauen:

  • Exportieren sie das Entwicklerzertifikat in eine Datei unter Windows:

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

    Wo $CREDENTIAL_PLACEHOLDER$ ist ein Kennwort.

  • Importieren Sie in einem WSL-Fenster das exportierte Zertifikat in 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 Exportieren des Zertifikats über und über. Wenn Sie das Zertifikat unter Windows aktualisieren oder neu erstellen, müssen Sie möglicherweise die vorherigen Befehle erneut ausführen.

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

Dieser Abschnitt stellt Hilfe bereit, wenn das ASP.NET Core HTTPS-Entwicklungszertifikat installiert und vertrauenswürdig ist. Sie verfügen jedoch weiterhin über Browserwarnungen, dass das Zertifikat nicht vertrauenswürdig ist. Das ASP.NET Core HTTPS-Entwicklungszertifikat wird von Kestrel.

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

Die vorherigen Befehle lösen die meisten Probleme mit der Browservertrauensstellung. Wenn der Browser weiterhin dem Zertifikat nicht vertraut ist, folgen Sie den plattformspezifischen Vorschlägen, die folgen.

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 sowohl unter als auch Current User > Personal > CertificatesCurrent User > Trusted root certification authorities > Certificates
  • Entfernen Sie alle gefundenen Zertifikate aus den Zertifizierungsstellen "Persönlich" und "Vertrauenswürdige 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 den Schlüsselbundzugriff.
  • Wählen Sie die Systemschlüsselkette 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 für die Vertrauenswürdigkeit konfigurierte Zertifikat das HTTPS-Entwicklerzertifikat des Benutzers ist, das vom Kestrel Server verwendet wird.

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

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 eine der folgenden Aktionen handelt:

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

Das Stammbenutzerzertifikat kann unter:

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" aus dem Visual Studio-Installationsprogramm aus. Weitere Informationen finden Sie in diesem GitHub-Issue.

Gruppenrichtlinie verhindert, dass selbstsignierte Zertifikate vertrauenswürdig sind

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

Zusätzliche Informationen

Warnung

API-Projekte

Verwenden RequireHttpsAttribute Sie nicht auf 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 hören.
  • Schließen Sie die Verbindung mit Statuscode 400 (Ungültige Anforderung) und dienen Sie nicht der Anforderung.

Um die HTTP-Umleitung in einer API zu deaktivieren, legen Sie die ASPNETCORE_URLS Umgebungsvariable fest, oder verwenden Sie das --urls Befehlszeilen flag. 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 nur eine Browseranweisung ist. Andere Anrufer, z. B. Telefon- oder Desktop-Apps, befolgen die Anweisung nicht . Auch in Browsern hat ein einzelner authentifizierter Aufruf einer API über HTTP Risiken für unsichere Netzwerke. Der sichere Ansatz besteht darin, API-Projekte so zu konfigurieren, dass nur ÜBER HTTPS zu hören und darauf zu reagieren.

Erzwingen von HTTPS

Es wird empfohlen, die Produktion ASP.NET Core Web-Apps zu verwenden:

  • HTTPS Redirection Middleware (UseHttpsRedirection) zum Umleiten von HTTP-Anforderungen an HTTPS.
  • HSTS Middleware (UseHsts) zum Senden von HTTP Strict Transport Security Protocol (HSTS)-Headern an Clients.

Hinweis

Apps, die in einer Reverseproxykonfiguration bereitgestellt wurden, ermöglichen es dem Proxy, Verbindungssicherheit (HTTPS) zu behandeln. Wenn der Proxy auch die HTTPS-Umleitung behandelt, muss https Redirection Middleware nicht verwendet werden. Wenn der Proxyserver auch das Schreiben von HSTS-Headern behandelt (z. B. native HSTS-Unterstützung in IIS 10.0 (1709) oder höher), ist HSTS Middleware nicht von der App erforderlich. Weitere Informationen finden Sie unter "Abmelden von HTTPS/HSTS" zur 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 vorherige hervorgehobene Code:

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 einen dauerhaften Umleitungsstatuscode senden möchten, wenn sich die App in einer Nichtentwicklungsumgebung befindet, finden Sie im Abschnitt " Konfigurieren dauerhafter Umleitungen im Produktionsabschnitt ". Wir empfehlen die Verwendung von HSTS , 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:

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

Geben Sie den HTTPS-Port mithilfe einer der folgenden Ansätze an:

  • Legen Sie httpsRedirectionOptions.HttpsPort fest.

  • Festlegen der https_portHosteinstellung:

    • In der Hostkonfiguration.

    • Indem Sie die ASPNETCORE_HTTPS_PORT Umgebungsvariable festlegen.

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

      {
          "https_port": 443,
          "Logging": {
              "LogLevel": {
                  "Default": "Information",
                  "Microsoft": "Warning",
                  "Microsoft.Hosting.Lifetime": "Information"
              }
          },
          "AllowedHosts": "*"
      }
      
  • Geben Sie einen Port mit dem sicheren Schema mit der ASPNETCORE_URLS Umgebungsvariable an. Die Umgebungsvariable konfiguriert den Server. Die Middleware entdeckt indirekt den HTTPS-Port über IServerAddressesFeature. Dieser Ansatz funktioniert nicht in 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 Servern oder HTTP.sys Server. Nur ein HTTPS-Port wird von der App verwendet. Die Middleware entdeckt 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 müssen, Kestrel dass beides zu hören ist:

  • 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).

Der unsichere Port muss vom Client zugänglich sein, damit die App eine unsichere Anforderung erhält 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

Jede Firewall zwischen dem Client und dem Server muss auch kommunikationsports für den Datenverkehr geöffnet sein.

Wenn Anforderungen in einer Reverseproxykonfiguration weitergeleitet werden, verwenden Sie Forwarded Header Middleware vor dem Aufrufen von HTTPS-Umleitungs-Middleware. Weitergeleitete Header-Middleware aktualisiert die Request.Scheme, mithilfe der X-Forwarded-Proto Kopfzeile. Die Middleware ermöglicht die Umleitung von URIs und anderen Sicherheitsrichtlinien, ordnungsgemäß zu funktionieren. Wenn Forwarded Headers Middleware nicht verwendet wird, erhält die Back-End-App möglicherweise kein richtiges Schema und endet in einer Umleitungsschleife. Eine allgemeine Fehlermeldung des Endbenutzers ist, dass zu viele Umleitungen aufgetreten sind.

Folgen Sie beim Bereitstellen in Azure App Service den Anleitungen im Lernprogramm: Binden Sie ein vorhandenes benutzerdefiniertes SSL-Zertifikat 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;
    });
}

Der Aufruf AddHttpsRedirection ist nur erforderlich, um die Werte von HttpsPort oder RedirectStatusCode.

Der vorherige hervorgehobene Code:

Konfigurieren von dauerhaften Umleitungen in der Produktion

Die Middleware ist standardmäßig für das Senden einer Status307TemporaryRedirect Datei mit allen Umleitungen festgelegt. Wenn Sie einen dauerhaften Umleitungsstatuscode senden möchten, wenn sich die App in einer Nicht-Entwicklungsumgebung befindet, umschließen Sie die Middlewareoptionen-Konfiguration in einer bedingten Überprüfung für eine Nichtentwicklungsumgebung.

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

HTTPS Redirection Middleware alternativer Ansatz

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

Beim Umleiten auf HTTPS ohne Anforderung für zusätzliche Umleitungsregeln empfehlen wir die Verwendung von HTTPS-Umleitungs-Middleware () inUseHttpsRedirection diesem Thema beschrieben.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP ist HTTP Strict Transport Security (HSTS) eine Opt-In-Sicherheitsverbesserung, die von einer Web-App über die Verwendung eines Antwortheaders angegeben wird. Wenn ein Browser, der HSTS unterstützt, diese Kopfzeile empfängt:

  • Der Browser speichert die Konfiguration für die Domäne, die verhindert, dass eine Kommunikation über HTTP gesendet wird. 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, mit denen ein Benutzer vorübergehend ein solches Zertifikat vertrauen kann.

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

  • Der Client muss HSTS unterstützen.
  • HSTS erfordert mindestens eine erfolgreiche HTTPS-Anforderung zum Einrichten der HSTS-Richtlinie.
  • 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, wenn sich die App nicht im Entwicklungsmodus befindetUseHsts:

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 sehr zwischengespeichert werden können. Standardmäßig UseHsts wird die lokale Loopbackadresse ausgeschlossen.

Legen Sie für Produktionsumgebungen, die HTTPS zum ersten Mal implementieren, einen kleinen HstsOptions.MaxAge Wert mit einer der TimeSpan Methoden fest. Legen Sie den Wert von Stunden auf keinen einzelnen Tag fest, wenn Sie die HTTPS-Infrastruktur auf HTTP zurücksetzen müssen. Nachdem Sie sich auf die Nachhaltigkeit der HTTPS-Konfiguration verlassen haben, erhöhen Sie den HSTS-Wert max-age ; ein häufig verwendeter Wert ist ein Jahr.

Der folgende Code führt folgende Aktionen aus:

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 der Strict-Transport-Security Kopfzeile fest. Preload ist nicht Teil der RFC HSTS-Spezifikation, wird jedoch von Webbrowsern unterstützt, um HSTS-Websites neu zu laden. Weitere Informationen finden Sie unter https://hstspreload.org/.
  • Aktiviert includeSubDomain, die die HSTS-Richtlinie auf Hostdomänen anwendet.
  • Legt den max-age Parameter der Strict-Transport-Security Kopfzeile explizit auf 60 Tage fest. Wenn nicht festgelegt, wird die Standardeinstellung auf 30 Tage festgelegt. Weitere Informationen finden Sie in der Max-Age-Richtlinie.
  • Fügt example.com der Liste der Hosts hinzu, die ausgeschlossen werden sollen.

UseHsts schließt die folgenden Loopbackhosts aus:

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

Abmelden von HTTPS/HSTS bei der Projekterstellung

In einigen Back-End-Dienstszenarien, in denen die Verbindungssicherheit am öffentlichen Rand des Netzwerks behandelt wird, ist die Konfiguration der Verbindungssicherheit bei jedem Knoten nicht erforderlich. Web-Apps, die aus den Vorlagen in Visual Studio oder aus dem dotnet neuen Befehl 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:

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

Das Dialogfeld

Vertrauen Sie dem ASP.NET Core HTTPS-Entwicklungszertifikat 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 als Teil der Ersten Ausführung installiert. Erzeugt beispielsweise dotnet --info eine Variation 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, aber es ist nicht vertrauenswürdig. Führen Sie zum Vertrauen des Zertifikats 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 neu verteilt wird, z. B. ein Containerimage oder einen virtuellen Computer. Dies kann zu Spoofing und Erhöhung von Berechtigungen führen. Um dies zu verhindern, legen Sie die DOTNET_GENERATE_ASPNET_CERTIFICATE Umgebungsvariable false vor dem erstmaligen Aufrufen der .NET CLI fest. 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. Die Konfiguration mit dem Browser erstellt die Richtliniendatei, sodass die beiden Ansätze gleichwertig sind.

Erstellen einer Richtliniendatei zum Vertrauen des HTTPS-Zertifikats mit Firefox

Erstellen einer Richtliniendatei unter:

Fügen Sie die folgende JSON-Datei zur Firefox-Richtliniendatei hinzu:

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

Die vorherige Richtliniendatei macht Firefox-vertrauenswürdige Zertifikate aus den vertrauenswürdigen Zertifikaten im Windows-Zertifikatspeicher. Der nächste Abschnitt bietet einen alternativen Ansatz zum Erstellen der vorherigen Richtliniendatei mithilfe des Firefox-Browsers.

Konfigurieren der Vertrauensstellung des HTTPS-Zertifikats mithilfe des Firefox-Browsers

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

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

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

Einrichten eines Entwicklerzertifikats für Docker

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

HTTPS-Zertifikat auf Linux vertrauen

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

Ubuntu vertrauen dem Zertifikat für die Dienst-zu-Service-Kommunikation

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

  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 wird.
  • Exportiert das Zertifikat mit erhöhten Berechtigungen, die für den ca-certificates Ordner erforderlich sind, und verwendet die Umgebung des aktuellen Benutzers.
  • Wenn Sie das -E Flag entfernen, wird das Stammbenutzerzertifikat exportiert, falls erforderlich. Jedes neu generierte Zertifikat hat einen anderen Fingerabdruck. Wenn Sie als Stamm ausgeführt werden und sudo-E nicht benötigt werden.

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

HTTPS-Zertifikat auf Linux mit Edge oder Chrome vertrauen

Für Chromium-Browser unter Linux:

  • Installieren Sie die libnss3-tools Verteilung 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 für Ubuntu spezifisch. Wählen Sie für andere Verteilungen 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 Sie dem Zertifikat 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 für Ubuntu spezifisch. Wählen Sie für andere Verteilungen einen geeigneten Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (Certificate Authorities, CAs).

  • Erstellen Sie eine JSON-Datei mit /usr/lib/firefox/distribution/policies.json den folgenden Inhalten:

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

Siehe Konfigurieren der Vertrauensstellung von HTTPS-Zertifikaten mithilfe des Firefox-Browsers in diesem Dokument, um die Richtliniendatei mithilfe des Browsers zu konfigurieren.

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 .

Vertrauen Sie dem Zertifikat mit anderen Vertrommen

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

HTTPS-Zertifikat von Windows-Subsystem für Linux vertrauen

Das Windows-Subsystem für Linux (WSL) generiert ein selbstsigniertes HTTPS-Entwicklungszertifikat. So konfigurieren Sie den Windows-Zertifikatspeicher, um dem WSL-Zertifikat zu vertrauen:

  • Exportieren sie das Entwicklerzertifikat in eine Datei unter Windows:

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

    Wo $CREDENTIAL_PLACEHOLDER$ ist ein Kennwort.

  • Importieren Sie in einem WSL-Fenster das exportierte Zertifikat in 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 Exportieren des Zertifikats über und über. Wenn Sie das Zertifikat unter Windows aktualisieren oder neu erstellen, müssen Sie möglicherweise die vorherigen Befehle erneut ausführen.

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

Dieser Abschnitt stellt Hilfe bereit, wenn das ASP.NET Core HTTPS-Entwicklungszertifikat installiert und vertrauenswürdig ist. Sie verfügen jedoch weiterhin über Browserwarnungen, dass das Zertifikat nicht vertrauenswürdig ist. Das ASP.NET Core HTTPS-Entwicklungszertifikat wird von Kestrel.

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

Die vorherigen Befehle lösen die meisten Probleme mit der Browservertrauensstellung. Wenn der Browser weiterhin dem Zertifikat nicht vertraut ist, folgen Sie den plattformspezifischen Vorschlägen, die folgen.

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 sowohl unter als auch Current User > Personal > CertificatesCurrent User > Trusted root certification authorities > Certificates
  • Entfernen Sie alle gefundenen Zertifikate aus den Zertifizierungsstellen "Persönlich" und "Vertrauenswürdige 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 den Schlüsselbundzugriff.
  • Wählen Sie die Systemschlüsselkette 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 für die Vertrauenswürdigkeit konfigurierte Zertifikat das HTTPS-Entwicklerzertifikat des Benutzers ist, das vom Kestrel Server verwendet wird.

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

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 eine der folgenden Aktionen handelt:

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

Das Stammbenutzerzertifikat kann unter:

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" aus dem Visual Studio-Installationsprogramm aus. Weitere Informationen finden Sie in diesem GitHub-Issue.

Zusätzliche Informationen