Erzwingen von HTTPS in ASP.NET Core

Von Rick Anderson

Dieses Dokument zeigt, wie Sie:

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

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

Warnung

API-Projekte

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

  • Lauschen Sie nicht auf HTTP.
  • Schließen Sie die Verbindung mit dem Statuscode 400 (Fehlerhafte Anforderung), und stellen Sie die Anforderung nicht.

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

HSTS- und API-Projekte

Die API-Standardprojekte enthalten HSTS nicht, da HSTS in der Regel eine anweisung vom Browser ist. Andere Anrufer, z. B. Telefon- oder Desktop-Apps, befolgen die Anweisung nicht. Selbst innerhalb von Browsern birgt ein einzelner authentifizierter Aufruf einer API über HTTP Risiken für unsichere Netzwerke. Der sichere Ansatz besteht in der Konfiguration von API-Projekten, um nur auf HTTPS zu lauschen und darauf zu reagieren.

Erzwingen von HTTPS

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

  • Middleware für HTTPS-Umleitung ( UseHttpsRedirection ), um HTTP-Anforderungen an HTTPS umzuleiten.
  • HSTS-Middleware (UseHsts), um HSTS-Header (HTTP Strict Transport Security Protocol) an Clients zu senden.

Hinweis

Apps, die in einer Reverseproxykonfiguration bereitgestellt werden, ermöglichen dem Proxy die Handhabung der Verbindungssicherheit (HTTPS). Wenn der Proxy auch die HTTPS-Umleitung verarbeitet, ist es nicht notwendig, middleware für die HTTPS-Umleitung zu verwenden. 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 für die App nicht erforderlich. Weitere Informationen finden Sie unter Deaktivieren von HTTPS/HSTS bei der Projekterstellung.

UseHttpsRedirection

Der folgende Code ruft UseHttpsRedirection in der Datei Program.cs auf:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Der oben hervorgehobene Code:

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

Portkonfiguration

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

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

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

  • Legen Sie HttpsRedirectionOptions.HttpsPort fest.

  • Legen Sie die https_port Hosteinstellung fest:

    • In der Hostkonfiguration.

    • Durch Festlegen der ASPNETCORE_HTTPS_PORT Umgebungsvariablen.

    • Durch Hinzufügen eines Eintrags der obersten Ebene in appsettings.json :

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

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

  • Konfigurieren Sie einen HTTPS-URL-Endpunkt für eine öffentliche Edgebereitstellung eines Servers oderHTTP.sysKestrel Server. Von der App wird nur ein HTTPS-Port 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 oderHTTP.sysals öffentlich zugänglicher Edgeserver verwendet wird oder HTTP.sys muss so konfiguriert sein, dass Kestrel Kestrel beides abhört:

  • Der sichere Port, an den 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 5.000 in der Entwicklung).

Der unsichere Port muss vom Client zugänglich sein, damit die App eine unsichere Anforderung empfangen und den Client an den sicheren Port umleiten kann.

Weitere Informationen finden Sie unter Kestrel Endpunktkonfiguration oder Implementierung des Http.sys-Webservers in ASP.NET Core .

Bereitstellungsszenarien

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

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

Befolgen Sie beim Bereitstellen Azure App Service Azure-Web-Apps die Anleitung unter Tutorial: Binden eines vorhandenen benutzerdefinierten SSL-Zertifikats an Azure-Web-Apps.

Optionen

Der folgende hervorgehobene Code ruft AddHttpsRedirection auf, um Middlewareoptionen zu konfigurieren:

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 AddHttpsRedirection Aufrufen von ist nur erforderlich, um die Werte von oder zu HttpsPort RedirectStatusCode ändern.

Der oben hervorgehobene Code:

Konfigurieren von permanenten Umleitungen in der Produktion

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

Beim Konfigurieren von Diensten in Program.cs:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int)HttpStatusCode.PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

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

    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Alternativer Ansatz der Middleware für https-Umleitung

Eine Alternative zur Verwendung der Middleware für HTTPS-Umleitung ( ) ist die Verwendung der UseHttpsRedirection URL-Umschreibungs-Middleware ( AddRedirectToHttps ). AddRedirectToHttps kann auch den Statuscode und port festlegen, wenn die Umleitung ausgeführt wird. Weitere Informationen finden Sie unter URL Rewriting Middleware.

Wenn Sie zu HTTPS umleiten, ohne dass zusätzliche Umleitungsregeln erforderlich sind, empfiehlt es sich, die in diesem Thema beschriebene Middleware zur UseHttpsRedirection HTTPS-Umleitung () zu verwenden.

HTTP Strict Transport Security Protocol (HSTS)

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

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

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

  • Der Client muss HSTS unterstützen.
  • HSTS erfordert mindestens eine erfolgreiche HTTPS-Anforderung, um die HSTS-Richtlinie zu erstellen.
  • 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 UseHsts auf, wenn sich die App nicht im Entwicklungsmodus befindet:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts wird in der Entwicklung nicht empfohlen, da die HSTS-Einstellungen von Browsern stark 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 anfänglichen Wert HstsOptions.MaxAge mithilfe einer der Methoden auf einen kleinen Wert TimeSpan fest. Legen Sie den Wert von stunden auf nicht mehr als einen Tag fest, falls Sie die HTTPS-Infrastruktur auf HTTP zurückverwenden müssen. Wenn Sie mit der HTTPS-Konfiguration vertraut sind, erhöhen Sie den HSTS-Wert. Ein häufig verwendeter max-age 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. Das Vorabladen ist nicht Teil der RFC HSTS-Spezifikation,wird jedoch von Webbrowsern unterstützt, um HSTS-Websites bei einer neu installierten Installation vorab zu laden. Weitere Informationen finden Sie unter https://hstspreload.org/.
  • Aktiviert includeSubDomain,wodurch die HSTS-Richtlinie auf Hostunterdomänen angewendet wird.
  • Legt den Parameter max-age des Headers explizit Strict-Transport-Security auf 60 Tage fest. Wenn nicht festgelegt, wird standardmäßig 30 Tage verwendet. Weitere Informationen finden Sie in der max-age-Direktive.
  • Fügt example.com der Liste der auszuschließenden Hosts hinzu.

UseHsts schließt die folgenden Loopbackhosts aus:

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

Deaktivieren von HTTPS/HSTS bei der Projekterstellung

In einigen Back-End-Dienstszenarien, in denen die Verbindungssicherheit am öffentlichen Rand des Netzwerks erfolgt, ist es nicht erforderlich, die Verbindungssicherheit auf jedem Knoten zu konfigurieren. Web-Apps, die aus den Vorlagen in Visual Studio oder aus dem Befehl dotnet new generiert werden, aktivieren die 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.

Dialogfeld ASP.NET Core Webanwendung, in dem das Kontrollkästchen Configure for HTTPS (Für HTTPS konfigurieren) deaktiviert ist.

Vertrauen Sie dem ASP.NET Core HTTPS-Entwicklungszertifikat unter Windows und macOS.

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

Die .NET Core SDK enthält ein HTTPS-Entwicklungszertifikat. Das Zertifikat wird im Rahmen der ersten Ausführung installiert. Beispielsweise erzeugt 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, ist aber nicht vertrauenswürdig. Um dem Zertifikat zu vertrauen, führen Sie den einmaligen Schritt zum Ausführen des dotnet-Tools dev-certs aus:

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 Neuverteilungsumgebung, z. B. einem Containerimage oder einem virtuellen Computer. Dies kann zu Spoofing und Rechteerweiterungen führen. Um dies zu verhindern, legen Sie die DOTNET_GENERATE_ASPNET_CERTIFICATE Umgebungsvariable auf fest, bevor Sie false die .NET CLI zum ersten Mal aufrufen. Dadurch wird die automatische Generierung des ASP.NET Core Entwicklungszertifikats während der ersten Ausführung der CLI übersprungen.

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

Der Firefox-Browser verwendet einen eigenen Zertifikatspeicher und vertraut daher nicht 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. Bei der Konfiguration mit dem Browser wird die Richtliniendatei erstellt, sodass die beiden Ansätze gleichwertig sind.

Erstellen einer Richtliniendatei zum Vertrauen des HTTPS-Zertifikats mit Firefox

Erstellen Sie eine Richtliniendatei unter:

  • Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\policies.json
  • macOS: Firefox.app/Contents/Resources/distribution
  • Linux: Weitere Informationen finden Sie in diesem Dokument unter Trust the certificate with Firefox on Linux (Vertrauen des Zertifikats mit Firefox unter Linux).

Fügen Sie der Firefox-Richtliniendatei den folgenden JSON-Code hinzu:

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

Die obige 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 beschrieben.

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

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

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

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

Einrichten eines Entwicklerzertifikats für Docker

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

Vertrauen des HTTPS-Zertifikats unter Linux

Die Vertrauensstellung ist verteilungs- und browserspezifisch. Die folgenden Abschnitte enthalten Anweisungen für einige gängige Distributionen und die Chromium Browser (Edge und Chrome) und für Firefox.

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

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

  2. Führen Sie die folgenden Befehle aus:

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

Die obenstehenden Befehle haben folgende Konsequenzen:

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

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

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

Für Chromium-Browser unter Linux:

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

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

  • Exportieren Sie das Zertifikat mit dem folgenden Befehl:

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

    Der Pfad im vorherigen Befehl ist spezifisch für Ubuntu. Wählen Sie für andere 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 ihn neu.

Vertrauen des Zertifikats mit Firefox unter Linux

  • Exportieren Sie das Zertifikat mit dem folgenden Befehl:

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

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

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

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

Eine alternative Möglichkeit zum Konfigurieren der Richtliniendatei mithilfe des Browsers finden Sie in diesem Dokument unter Konfigurieren der Vertrauensstellung eines HTTPS-Zertifikats mithilfe des Firefox-Browsers.

Vertrauen Sie dem Zertifikat mit Fedora 34.

Weitere Informationen finden Sie in diesem GitHub Kommentar.

Vertrauenswürdigkeit des Zertifikats mit anderen Distributionen

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

Vertrauenswürdiges HTTPS-Zertifikat von Windows-Subsystem für Linux

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

  • Exportieren Sie das Entwicklerzertifikat in eine Datei auf Windows:

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

    Dabei $CREDENTIAL_PLACEHOLDER$ ist ein Kennwort.

  • Importieren Sie in einem WSL-Fenster das exportierte Zertifikat 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 Zertifikat immer wieder zu exportieren. Wenn Sie das Zertifikat unter Windows aktualisieren oder neu generieren, müssen Sie möglicherweise die vorherigen Befehle erneut ausführen.

Behandeln von Zertifikatproblemen, z. B. "Zertifikat nicht vertrauenswürdig"

Dieser Abschnitt bietet Hilfe, wenn das ASP.NET Core HTTPS-Entwicklungszertifikat installiert wurde und als vertrauenswürdig eingestuftwurde. Es gibt jedoch weiterhin Browserwarnungen, dass das Zertifikat nicht vertrauenswürdig ist. Das ASP.NET Core HTTPS-Entwicklungszertifikat wird von Kestrel verwendet.

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 obigen Befehle lösen die meisten Probleme mit der Browservertrauensstellung. Wenn der Browser dem Zertifikat weiterhin nicht vertraut, befolgen Sie die folgenden plattformspezifischen Vorschläge.

Docker: Zertifikat nicht vertrauenswürdig

  • Löschen Sie den Ordner C:\Users { USER}\AppData\Roaming\ASP.NET\Https.
  • Bereinigen Sie die Lösung. Löschen Sie die Ordner bin und obj.
  • Starten Sie das Entwicklungstool neu. 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 vorhanden sein. Current User > Personal > Certificates``Current User > Trusted root certification authorities > Certificates
  • Entfernen Sie alle gefundenen Zertifikate aus persönlichen und vertrauenswürdigen Stammzertifizierungsstellen. Entfernen Sie nicht das IIS Express localhost-Zertifikats.
  • Führen Sie die folgenden Befehle aus:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

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

OS X – Zertifikat nicht vertrauenswürdig

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

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

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

Linux-Zertifikat nicht vertrauenswürdig

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

Überprüfen Sie das https-Entwicklerstandardzertifikat des aktuellen Benutzers Kestrel an folgendem Speicherort:

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

Die Kestrel HTTPS-Entwicklerzertifikatdatei ist der SHA1-Fingerabdruck. Wenn die Datei über gelöscht dotnet dev-certs https --clean 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 eines der folgenden Sein:

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

Das Stammbenutzerzertifikat kann unter folgendem Code ü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 im installationsprogramm für Visual Studio die Option Reparieren aus. Weitere Informationen finden Sie in diesem GitHub-Issue.

Zusätzliche Informationen

Warnung

API-Projekte

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

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

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

HSTS- und API-Projekte

Die STANDARD-API-Projekte enthalten HSTS nicht, da HSTS in der Regel nur eine Browseranweisung ist. Andere Anrufer, z. B. Telefon- oder Desktop-Apps, befolgen die Anweisungen nicht. Selbst innerhalb von Browsern birgt ein einzelner authentifizierter Aufruf einer API über HTTP Risiken in unsicheren Netzwerken. Der sichere Ansatz besteht darin, API-Projekte so zu konfigurieren, dass sie nur über HTTPS lauschen und darauf reagieren.

Erzwingen von HTTPS

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

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

Hinweis

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

UseHttpsRedirection

Der folgende Code ruft UseHttpsRedirection in der Startup -Klasse auf:

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

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

Portkonfiguration

Ein Port muss verfügbar sein, damit die Middleware eine unsichere Anforderung an HTTPS umleitet. Wenn kein Port verfügbar ist:

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

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

  • Legen Sie HttpsRedirectionOptions.HttpsPortfest.

  • Legen Sie die https_port Hosteinstellung fest:

    • In der Hostkonfiguration.

    • Durch Festlegen der ASPNETCORE_HTTPS_PORT Umgebungsvariablen.

    • Durch Hinzufügen eines Eintrags der obersten Ebene in appsettings.json :

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

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

  • Konfigurieren Sie einen HTTPS-URL-Endpunkt für eine öffentlich zugängliche Edgebereitstellung von Kestrel Server oder HTTP.sys Server. Von der App wird nur ein HTTPS-Port verwendet. Die Middleware ermittelt den Port über IServerAddressesFeature .

Hinweis

Wenn eine App in einer Reverseproxykonfiguration ausgeführt wird, IServerAddressesFeature ist nicht verfügbar. Legen Sie den Port mit einem 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 für das Kestrel Lauschen auf beides konfiguriert werden muss:

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

Auf den unsicheren Port muss der Client zugreifen können, damit die App eine unsichere Anforderung empfängt und den Client an den sicheren Port umleitet.

Weitere Informationen finden Sie unter Kestrel Endpunktkonfiguration oder Implementierung des Http.sys-Webservers in ASP.NET Core .

Bereitstellungsszenarien

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

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

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

Optionen

Der folgende hervorgehobene Code ruft AddHttpsRedirection auf, um Middlewareoptionen zu konfigurieren:

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 von ist nur erforderlich, um die Werte von oder zu HttpsPort RedirectStatusCode ändern.

Der vorangehende hervorgehobene Code:

Konfigurieren permanenter Umleitungen in der Produktion

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

Beim Konfigurieren von Diensten in Startup.cs:

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

Alternativer Ansatz der HTTPS-Umleitungs-Middleware

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

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

HTTP Strict Transport Security Protocol (HSTS)

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

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

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

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

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

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

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

    app.UseRouting();

    app.UseAuthorization();

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

UseHsts wird in der Entwicklung nicht empfohlen, da die HSTS-Einstellungen von Browsern stark zwischengespeichert werden können. Standardmäßig UseHsts schließt die lokale Loopbackadresse aus.

Legen Sie für Produktionsumgebungen, die HTTPS zum ersten Mal implementieren, die anfängliche HstsOptions.MaxAge mithilfe einer der Methoden auf einen kleinen Wert TimeSpan fest. Legen Sie den Wert von Stunden auf maximal einen Tag fest, falls Sie die HTTPS-Infrastruktur auf HTTP zurücksetzen müssen. Wenn Sie sicher sind, dass die HTTPS-Konfiguration sinnvoll ist, 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. Das Vorabladen ist nicht Teil der RFC HSTS-Spezifikation,wird aber von Webbrowsern unterstützt, um HSTS-Websites bei einer neu installierten Installation vorab zu laden. Weitere Informationen finden Sie unter https://hstspreload.org/.
  • Aktiviert includeSubDomain,wodurch die HSTS-Richtlinie auf Hostunterdomänen angewendet wird.
  • Legt den Parameter des Headers explizit max-age auf Strict-Transport-Security 60 Tage fest. Wenn diese Einstellung nicht festgelegt ist, wird standardmäßig 30 Tage verwendet. Weitere Informationen finden Sie in der max-age-Direktive.
  • Fügt example.com der Liste der auszuschließende Hosts hinzu.

UseHsts schließt die folgenden Loopbackhosts aus:

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

Deaktivieren von HTTPS/HSTS bei der Projekterstellung

In einigen Back-End-Dienstszenarien, in denen die Verbindungssicherheit am öffentlichen Rand des Netzwerks behandelt wird, ist die Konfiguration der Verbindungssicherheit auf jedem Knoten nicht erforderlich. Web-Apps, die aus den Vorlagen in Visual Studio oder aus dem Befehl dotnet new generiert werden, aktivieren die HTTPS-Umleitung und HSTS. Für Bereitstellungen, für die diese Szenarien nicht erforderlich sind, 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.

Dialogfeld "Neue ASP.NET Core Webanwendung", in dem das Kontrollkästchen Für HTTPS konfigurieren deaktiviert angezeigt wird.

Vertrauen Sie dem ASP.NET Core HTTPS-Entwicklungszertifikat unter Windows und macOS.

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

Die .NET Core SDK enthält ein HTTPS-Entwicklungszertifikat. Das Zertifikat wird im Rahmen der ersten Ausführung installiert. Erzeugt z. B. 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, ist aber nicht vertrauenswürdig. Um dem Zertifikat zu vertrauen, führen Sie den einmaligen Schritt aus, um das Dotnet-Tool dev-certs auszuführen:

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

Warnung

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

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

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

Es gibt zwei Ansätze, um dem HTTPS-Zertifikat mit Firefox zu vertrauen: Erstellen einer Richtliniendatei oder Konfigurieren mit dem FireFox-Browser. Beim Konfigurieren mit dem Browser wird die Richtliniendatei erstellt, sodass die beiden Ansätze gleichwertig sind.

Erstellen einer Richtliniendatei für das Vertrauenswürdigkeits-HTTPS-Zertifikat mit Firefox

Erstellen Sie eine Richtliniendatei unter:

  • Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\policies.json
  • macOS: Firefox.app/Contents/Resources/distribution
  • Linux: Weitere Informationen finden Sie in diesem Dokument unter Vertrauenswürdigkeit des Zertifikats mit Firefox unter Linux.

Fügen Sie der Firefox-Richtliniendatei den folgenden JSON-Code hinzu:

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

Mit der obigen Richtliniendatei werden Firefox-Zertifikaten aus den vertrauenswürdigen Zertifikaten im Windows Zertifikatspeicher vertraut. 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 mithilfe der folgenden Anweisungen fest:

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

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

Einrichten eines Entwicklerzertifikats für Docker

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

Vertrauenswürdiges HTTPS-Zertifikat unter Linux

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

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

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

  2. Führen Sie die folgenden Befehle aus:

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

Die obenstehenden Befehle haben folgende Konsequenzen:

  • Stellen Sie sicher, dass das Entwicklerzertifikat des aktuellen Benutzers erstellt wird.
  • Exportiert das Zertifikat mit erhöhten Berechtigungen, die für den Ordner erforderlich ca-certificates sind, unter Verwendung der Umgebung des aktuellen Benutzers.
  • Wenn Sie das -E Flag entfernen, wird das Stammbenutzerzertifikat exportiert und bei Bedarf generiert. Jedes neu generierte Zertifikat verfügt über einen anderen Fingerabdruck. Wenn als Root ausgeführt wird, sudo werden und -E nicht benötigt.

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

Vertrauenswürdiges HTTPS-Zertifikat unter Linux mithilfe von Edge oder Chrome

Für Chromium-Browser unter Linux:

  • Installieren Sie für libnss3-tools Ihre Distribution.

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

  • Exportieren Sie das Zertifikat mit dem folgenden Befehl:

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

    Der Pfad im vorherigen Befehl ist spezifisch für Ubuntu. Wählen Sie für andere 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.

Vertrauenswürdigkeit des Zertifikats mit Firefox unter Linux

  • Exportieren Sie das Zertifikat mit dem folgenden Befehl:

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

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

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

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

Eine alternative Möglichkeit zum Konfigurieren der Richtliniendatei mithilfe des Browsers finden Sie in diesem Dokument unter Konfigurieren der Vertrauensstellung eines HTTPS-Zertifikats mithilfe des Firefox-Browsers.

Vertrauenswürdigkeit des Zertifikats mit Fedora 34

Weitere Informationen finden Sie in diesem GitHub Kommentar.

Vertrauenswürdigkeit des Zertifikats mit anderen Distributionen

Weitere Informationen finden Sie im entsprechenden GitHub-Issue.

Vertrauenswürdiges HTTPS-Zertifikat von Windows-Subsystem für Linux

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

  • Exportieren Sie das Entwicklerzertifikat in eine Datei auf Windows:

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

    Dabei $CREDENTIAL_PLACEHOLDER$ ist ein Kennwort.

  • Importieren Sie in einem WSL-Fenster das exportierte Zertifikat 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 Zertifikat immer wieder zu exportieren. Wenn Sie das Zertifikat unter Windows aktualisieren oder neu generieren, müssen Sie möglicherweise die vorherigen Befehle erneut ausführen.

Behandeln von Zertifikatproblemen wie z.B. "Zertifikat nicht vertrauenswürdig"

Dieser Abschnitt bietet Hilfe, wenn das ASP.NET Core HTTPS-Entwicklungszertifikat installiert wurde und als vertrauenswürdig eingestuftwurde. Es gibt jedoch weiterhin Browserwarnungen, dass das Zertifikat nicht vertrauenswürdig ist. Das ASP.NET Core HTTPS-Entwicklungszertifikat wird von Kestrel verwendet.

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 obigen Befehle lösen die meisten Probleme mit der Browservertrauensstellung. Wenn der Browser dem Zertifikat weiterhin nicht vertraut, befolgen Sie die folgenden plattformspezifischen Vorschläge.

Docker: Zertifikat nicht vertrauenswürdig

  • Löschen Sie den Ordner C:\Users { USER}\AppData\Roaming\ASP.NET\Https.
  • Bereinigen Sie die Lösung. Löschen Sie die Ordner bin und obj.
  • Starten Sie das Entwicklungstool neu. 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 vorhanden sein. Current User > Personal > Certificates``Current User > Trusted root certification authorities > Certificates
  • Entfernen Sie alle gefundenen Zertifikate aus persönlichen und vertrauenswürdigen Stammzertifizierungsstellen. Entfernen Sie nicht das IIS Express localhost-Zertifikats.
  • Führen Sie die folgenden Befehle aus:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

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

OS X – Zertifikat nicht vertrauenswürdig

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

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

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

Linux-Zertifikat nicht vertrauenswürdig

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

Überprüfen Sie das https-Entwicklerstandardzertifikat des aktuellen Benutzers Kestrel an folgendem Speicherort:

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

Die Kestrel HTTPS-Entwicklerzertifikatdatei ist der SHA1-Fingerabdruck. Wenn die Datei über gelöscht dotnet dev-certs https --clean 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 eines der folgenden Sein:

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

Das Stammbenutzerzertifikat kann unter folgendem Code überprüft werden:

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

IIS Express MIT Visual Studio verwendetes SSL-Zertifikat

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

Zusätzliche Informationen