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 in der ersten Anforderung sendet.

Warnung

API-Projekte

Verwenden RequireHttpsAttribute Sie nicht auf Web-APIs, die vertrauliche Informationen erhalten. RequireHttpsAttribute Verwendet HTTP-Statuscodes, um Browser von HTTP zu HTTPS umzuleiten. API-Clients verstehen 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 dem Statuscode 400 (Bad Request) und dienen 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 Methoden zum Festlegen der URLs für eine ASP.NET Core App von Andrew Lock.

HSTS- und API-Projekte

Die Standard-API-Projekte enthalten keine HSTS , da HSTS in der Regel nur eine Browseranweisung ist. Andere Anrufer, z. B. Telefon- oder Desktop-Apps, folgen nicht der Anweisung. Selbst in Browsern hat ein einzelner authentifizierter Aufruf einer API über HTTP Risiken für unsichere Netzwerke. Der sichere Ansatz besteht darin, API-Projekte zu konfigurieren, um nur über HTTPS zu hören und zu reagieren.

DIE HTTP-Umleitung zu HTTPS verursacht ERR_INVALID_REDIRECT in der CORS-Preflight-Anforderung

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

API-Projekte können HTTP-Anforderungen ablehnen und nicht zum Umleiten von Anforderungen an HTTPS verwenden UseHttpsRedirection .

Erzwingen von HTTPS

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

  • HTTPS-Umleitungs-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 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 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.AspNetCore": "Warning"
          }
        },
        "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.

  • Die ASP.NET Core Webvorlagen legen eine HTTPS-URL für Properties/launchsettings.json beide Kestrel und 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 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 muss, 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:

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

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

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, 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 ".

New ASP.NET Core Web Application dialog showing the Configure for HTTPS checkbox unselected.

Vertrauen Sie dem ASP.NET Core HTTPS-Entwicklungszertifikat auf 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 der Firefox-Richtliniendatei den folgenden JSON-Code hinzu:

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

In der vorherigen Richtliniendatei werden Firefox-vertrauenswürdige Zertifikate aus den vertrauenswürdigen Zertifikaten im Windows Zertifikatspeicher erstellt. 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 entsprechenden Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (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

Weitere Informationen finden Sie unter Konfigurieren der Vertrauensstellung des HTTPS-Zertifikats mithilfe des Firefox-Browsers in diesem Dokument, um die Richtliniendatei mithilfe des Browsers zu konfigurieren.

Vertrauen Sie dem Zertifikat mit Fedora 34

Hier finden Sie GitHub Kommentar.

Vertrauen Des Zertifikats mit anderen Verfolgern

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

Vertrauen eines HTTPS-Zertifikats aus Windows-Subsystem für Linux

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

  • Exportieren Sie das Entwicklerzertifikat in eine Datei in 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 der 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.

Beheben von Zertifikatproblemen wie z. B. Zertifikat nicht vertrauenswürdig

In diesem Abschnitt werden Hilfe bereitgestellt, wenn das HTTPS-Entwicklungszertifikat ASP.NET Core installiert und vertrauenswürdig wurde, aber Sie verfügen 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 Browserinstanzen, die geöffnet sind. Öffnen Sie ein neues Browserfenster in der App. Die Zertifikatvertrauensstellung wird von Browsern zwischengespeichert.

dotnet dev-certs https --clean Fehler

Die vorhergehenden Befehle lösen die meisten Probleme mit der Browservertrauenswürdigen Lösung. Wenn der Browser weiterhin dem Zertifikat nicht vertrauenswürdig 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. 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 als auch Current User > Personal > CertificatesCurrent User > Trusted root certification authorities > Certificates
  • Entfernen Sie alle gefundenen Zertifikate aus den Zertifizierungsstellen "Personal" und "Trusted Root". 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 Browserinstanzen, die geöffnet sind. Öffnen Sie ein neues Browserfenster in der App.

OS X – Zertifikat nicht vertrauenswürdig

  • Öffnen Sie den KeyChain-Zugriff.
  • Wählen Sie die Systemschlüsselkette aus.
  • Überprüfen Sie die Anwesenheit eines localhost-Zertifikats.
  • Überprüfen Sie, ob es ein + Symbol auf dem Symbol enthält, um anzugeben, dass sie 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 Browserinstanzen, die geöffnet sind. Öffnen Sie ein neues Browserfenster in der App.

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

Linux-Zertifikat nicht vertrauenswürdig

Überprüfen Sie, ob das zertifikat, das für die Vertrauenswürdigkeit konfiguriert ist, das vom Server verwendet Kestrel wird.

Überprüfen Sie das aktuelle HTTPS-Standard-Entwicklerzertifikat Kestrel 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 regeneriert. Ü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, könnte es eine der folgenden Sein:

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

Das Stammbenutzerzertifikat kann unter folgendes ü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" aus dem Visual Studio Installer aus. Weitere Informationen finden Sie in diesem GitHub-Issue.

Gruppenrichtlinie verhindert, dass selbst signierte Zertifikate vertrauenswürdig sind

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

Weitere Informationen

Warnung

API-Projekte

Verwenden RequireHttpsAttribute Sie nicht auf Web-APIs, die vertrauliche Informationen erhalten. RequireHttpsAttribute Verwendet HTTP-Statuscodes, um Browser von HTTP zu HTTPS umzuleiten. API-Clients verstehen 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 dem Statuscode 400 (Bad Request) und dienen 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 Methoden zum Festlegen der URLs für eine ASP.NET Core App von Andrew Lock.

HSTS- und API-Projekte

Die Standard-API-Projekte enthalten keine HSTS, da HSTS in der Regel nur eine Browseranweisung ist. Andere Anrufer, z. B. Telefon- oder Desktop-Apps, folgen nicht der Anweisung. Selbst in Browsern hat ein einzelner authentifizierter Aufruf einer API über HTTP Risiken für unsichere Netzwerke. Der sichere Ansatz besteht darin, API-Projekte zu konfigurieren, um nur über HTTPS zu hören und zu reagieren.

Erzwingen von HTTPS

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

  • HTTPS-Umleitungs-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 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 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": "Warning",
                  "Microsoft.Hosting.Lifetime": "Information"
              }
          },
          "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.

  • Legen Sie in der Entwicklung eine HTTPS-URL in launchsettings.json. 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 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:

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 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 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 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:

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. 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 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 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 benötigen, können Sie HTTPS/HSTS abmelden, wenn die App aus der Vorlage erstellt wird.

So deaktivieren Sie HTTPS/HSTS:

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

New ASP.NET Core Web Application dialog showing the Configure for HTTPS checkbox unselected.

Vertrauen Sie dem ASP.NET CORE HTTPS-Entwicklungszertifikat auf 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ührungserfahrung 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 verteilt wird, z. B. ein Containerimage oder einen virtuellen Computer. Dies kann dazu führen, dass Spoofing und Erhöhung von Berechtigungen ausgeführt werden. Um dies zu verhindern, legen Sie die DOTNET_GENERATE_ASPNET_CERTIFICATE Umgebungsvariable false vor dem ersten Aufrufen der .NET CLI fest. Dadurch wird die automatische Generation 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 eines HTTPS-Zertifikats mit Firefox

Erstellen Sie eine Richtliniendatei unter:

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

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

Die vorherige Richtliniendatei macht Firefox-Vertrauenszertifikate aus den vertrauenswürdigen Zertifikaten im Windows Zertifikatspeicher. Im nächsten Abschnitt wird ein alternativer Ansatz zum Erstellen der vorherigen Richtliniendatei mithilfe des Firefox-Browsers bereitgestellt.

Konfigurieren der Vertrauensstellung des HTTPS-Zertifikats 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 akzeptieren" und "Fortsetzen ", 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 derDatei mozilla/policy-templates/README.

Einrichten eines Entwicklerzertifikats für Docker

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

Vertrauen des HTTPS-Zertifikats unter Linux

Das Einrichten von Vertrauensstellung ist verteilungs- und browserspezifisch. In den folgenden Abschnitten finden Sie 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-to-Service-Kommunikation

  1. Installieren Sie OpenSSL 1.1.1h oder höher. Weitere Informationen 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 Ordner erforderlich sind, mithilfe der ca-certificates Umgebung des aktuellen Benutzers.
  • Durch Das Entfernen des Flags wird das -E Stammbenutzerzertifikat exportiert, wenn erforderlich. Jedes neu generierte Zertifikat weist einen anderen Fingerabdruck auf. 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 entsprechenden Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (CAs).

Vertrauen des HTTPS-Zertifikats unter Linux mithilfe von Edge oder Chrome

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 entsprechenden Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (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 entsprechenden Pfad aus, oder verwenden Sie den Pfad für die Zertifizierungsstellen (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

Weitere Informationen finden Sie unter Konfigurieren der Vertrauensstellung des HTTPS-Zertifikats 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 von 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 Des Zertifikats mit anderen Verfolgern

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

Vertrauen eines HTTPS-Zertifikats aus Windows-Subsystem für Linux

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

  • Exportieren Sie das Entwicklerzertifikat in eine Datei in 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 der 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.

Beheben von Zertifikatproblemen wie z. B. Zertifikat nicht vertrauenswürdig

In diesem Abschnitt werden Hilfe bereitgestellt, wenn das HTTPS-Entwicklungszertifikat ASP.NET Core installiert und vertrauenswürdig wurde, aber Sie verfügen 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 Browserinstanzen, die geöffnet sind. Öffnen Sie ein neues Browserfenster in der App. Die Zertifikatvertrauensstellung wird von Browsern zwischengespeichert.

dotnet dev-certs https --clean Fehler

Die vorhergehenden Befehle lösen die meisten Probleme mit der Browservertrauenswürdigen Lösung. 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. 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 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.

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

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 Installer aus. Weitere Informationen finden Sie in diesem GitHub-Issue.

Weitere Informationen