Wymuszanie protokołu HTTPS w ASP.NET Core

Autor: Rick Anderson

W tym dokumencie pokazano, jak:

  • Wymagaj protokołu HTTPS dla wszystkich żądań.
  • Przekieruj wszystkie żądania HTTP do protokołu HTTPS.

Żaden interfejs API nie może uniemożliwić klientowi wysyłania poufnych danych w pierwszym żądaniu.

Ostrzeżenie

Projekty interfejsu API

Nie należy używać RequireHttpsAttribute w internetowych interfejsach API, które otrzymują poufne informacje. RequireHttpsAttribute Używa kodów stanu HTTP do przekierowywania przeglądarek z protokołu HTTP do protokołu HTTPS. Klienci interfejsu API mogą nie rozumieć ani przestrzegać przekierowań z protokołu HTTP do protokołu HTTPS. Tacy klienci mogą wysyłać informacje za pośrednictwem protokołu HTTP. Internetowe interfejsy API powinny:

  • Nie nasłuchiwanie w protokole HTTP.
  • Zamknij połączenie z kodem stanu 400 (nieprawidłowe żądanie) i nie obsłuż żądanie.

Aby wyłączyć przekierowywanie HTTP w interfejsie API, ustaw zmienną ASPNETCORE_URLS środowiskową lub użyj flagi --urls wiersza polecenia. Aby uzyskać więcej informacji, zobacz Use multiple environments in ASP.NET Core and 5 ways to set the URL for an ASP.NET Core app by Andrew Lock (Używanie wielu środowisk w ASP.NET Core i 5 sposobów ustawiania adresów URL dla aplikacji ASP.NET Core przez andrew locka).

HsTS i projekty interfejsu API

Domyślne projekty interfejsu API nie obejmują usługi HSTS , ponieważ hsTS to zazwyczaj tylko instrukcja przeglądarki. Inni rozmówcy, tacy jak telefon lub aplikacje klasyczne, nie przestrzegają instrukcji. Nawet w przeglądarkach pojedyncze uwierzytelnione wywołanie interfejsu API za pośrednictwem protokołu HTTP ma zagrożenia w niezabezpieczonych sieciach. Bezpieczne podejście polega na konfigurowaniu projektów interfejsu API w celu nasłuchiwania i odpowiadania za pośrednictwem protokołu HTTPS.

Przekierowanie HTTP do protokołu HTTPS powoduje ERR_INVALID_REDIRECT w żądaniu wstępnym CORS

Żądania do punktu końcowego przy użyciu protokołu HTTP, które są przekierowywane do protokołu HTTPS przez UseHttpsRedirection niepowodzenie z powodu błędu ERR_INVALID_REDIRECT on the CORS preflight request.

Projekty interfejsu API mogą odrzucać żądania HTTP zamiast przekierowywać UseHttpsRedirection żądania do protokołu HTTPS.

Wymagaj protokołu HTTPS

Zalecamy używanie produkcyjnych aplikacji internetowych ASP.NET Core:

  • Oprogramowanie pośredniczące przekierowania HTTPS (UseHttpsRedirection) w celu przekierowania żądań HTTP do protokołu HTTPS.
  • Oprogramowanie pośredniczące HSTS (UseHsts) do wysyłania nagłówków PROTOKOŁU HSTS (HTTP Strict Transport Security Protocol) do klientów.

Uwaga

Aplikacje wdrożone w konfiguracji zwrotnego serwera proxy umożliwiają serwerowi proxy obsługę zabezpieczeń połączeń (HTTPS). Jeśli serwer proxy obsługuje również przekierowywanie HTTPS, nie ma potrzeby używania oprogramowania pośredniczącego przekierowania HTTPS. Jeśli serwer proxy obsługuje również zapisywanie nagłówków HSTS (na przykład natywna obsługa hsTS w usługach IIS 10.0 (1709) lub nowszych), oprogramowanie pośredniczące HSTS nie jest wymagane przez aplikację. Aby uzyskać więcej informacji, zobacz Rezygnacja z protokołu HTTPS/HSTS podczas tworzenia projektu.

UseHttpsRedirection

Następujące wywołania UseHttpsRedirection kodu w Program.cs pliku:

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

Powyższy wyróżniony kod:

Zalecamy używanie tymczasowych przekierowań, a nie stałych przekierowań. Buforowanie linków może spowodować niestabilne zachowanie w środowiskach deweloperskich. Jeśli wolisz wysłać trwały kod stanu przekierowania, gdy aplikacja znajduje się w środowisku nieprodukcyjnym, zobacz sekcję Konfigurowanie stałych przekierowań w środowisku produkcyjnym . Zalecamy używanie usługi HSTS do sygnalizowania klientom, że do aplikacji powinny być wysyłane tylko bezpieczne żądania zasobów (tylko w środowisku produkcyjnym).

Konfiguracja portów

Aby oprogramowanie pośredniczące przekierowywało niezabezpieczone żądanie do protokołu HTTPS, musi być dostępny port. Jeśli port nie jest dostępny:

  • Przekierowanie do protokołu HTTPS nie jest wykonywane.
  • Oprogramowanie pośredniczące rejestruje ostrzeżenie "Nie można określić portu HTTPS na potrzeby przekierowania".

Określ port HTTPS przy użyciu dowolnej z następujących metod:

  • Ustaw wartość HttpsRedirectionOptions.HttpsPort.

  • https_port Ustaw ustawienie hosta:

    • W konfiguracji hosta.

    • Ustawiając zmienną ASPNETCORE_HTTPS_PORT środowiskową.

    • Dodając wpis najwyższego poziomu w pliku appsettings.json:

      {
        "https_port": 443,
        "Logging": {
          "LogLevel": {
            "Default": "Information",
            "Microsoft.AspNetCore": "Warning"
          }
        },
        "AllowedHosts": "*"
      }
      
  • Wskaż port z bezpiecznym schematem przy użyciu zmiennej środowiskowej ASPNETCORE_URLS. Zmienna środowiskowa konfiguruje serwer. Oprogramowanie pośredniczące pośrednio odnajduje port HTTPS za pośrednictwem polecenia IServerAddressesFeature. Takie podejście nie działa we wdrożeniach zwrotnego serwera proxy.

  • Szablony sieci Web platformy ASP.NET Core ustawiają adres URL HTTPS w Properties/launchsettings.json usługach Kestrel i IIS Express. launchsettings.json jest używany tylko na komputerze lokalnym.

  • Skonfiguruj punkt końcowy adresu URL PROTOKOŁU HTTPS na potrzeby publicznego wdrożenia Kestrel serwera lub serwera HTTP.sys . Aplikacja używa tylko jednego portu HTTPS . Oprogramowanie pośredniczące odnajduje port za pośrednictwem polecenia IServerAddressesFeature.

Uwaga

Gdy aplikacja jest uruchamiana w konfiguracji zwrotnego serwera proxy, IServerAddressesFeature nie jest dostępna. Ustaw port przy użyciu jednej z innych metod opisanych w tej sekcji.

Wdrożenia brzegowe

Jeśli Kestrel lub HTTP.sys jest używany jako publiczny serwer brzegowy lub Kestrel HTTP.sys należy skonfigurować nasłuchiwanie na obu:

  • Bezpieczny port, na którym klient jest przekierowywany (zazwyczaj 443 w środowisku produkcyjnym i 5001 w środowisku deweloperskim).
  • Niezabezpieczony port (zazwyczaj 80 w środowisku produkcyjnym i 5000 w środowisku deweloperskim).

Niezabezpieczony port musi być dostępny dla klienta, aby aplikacja odbierała niezabezpieczone żądanie i przekierowywała klienta do bezpiecznego portu.

Aby uzyskać więcej informacji, zobacz Kestrel konfiguracja punktu końcowego lub implementacja serwera internetowegoHTTP.sys w programie ASP.NET Core.

Scenariusze wdrażania

Każda zapora między klientem a serwerem musi również mieć otwarte porty komunikacyjne dla ruchu.

Jeśli żądania są przekazywane w konfiguracji zwrotnego serwera proxy , przed wywołaniem oprogramowania pośredniczącego przekierowania HTTPS użyj oprogramowania pośredniczącego przekierowania HTTPS. Oprogramowanie pośredniczące nagłówków przekazujących aktualizuje Request.Schemeelement przy użyciu nagłówka X-Forwarded-Proto . Oprogramowanie pośredniczące zezwala na poprawne działanie identyfikatorów URI przekierowania i innych zasad zabezpieczeń. Gdy oprogramowanie pośredniczące nagłówków przekazywanych nie jest używane, aplikacja zaplecza może nie odbierać poprawnego schematu i kończy się w pętli przekierowania. Typowym komunikatem o błędzie użytkownika końcowego jest to, że wystąpiło zbyt wiele przekierowań.

Podczas wdrażania w usłudze Azure App Service postępuj zgodnie ze wskazówkami w artykule Samouczek: wiązanie istniejącego niestandardowego certyfikatu SSL z usługą Azure Web Apps.

Opcje

Następujące wyróżnione wywołania AddHttpsRedirection kodu służące do konfigurowania opcji oprogramowania pośredniczącego:

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

Wywołanie AddHttpsRedirection jest niezbędne tylko do zmiany wartości elementu HttpsPort lub RedirectStatusCode.

Powyższy wyróżniony kod:

Konfigurowanie stałych przekierowań w środowisku produkcyjnym

Oprogramowanie pośredniczące domyślnie wysyła element Status307TemporaryRedirect ze wszystkimi przekierowaniami. Jeśli wolisz wysłać trwały kod stanu przekierowania, gdy aplikacja znajduje się w środowisku nieprogramowania, opakuj konfigurację opcji oprogramowania pośredniczącego w ramach sprawdzania warunkowego dla środowiska nieprogramowania.

Podczas konfigurowania usług w programie 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();

Alternatywne podejście do oprogramowania pośredniczącego przekierowania HTTPS

Alternatywą dla korzystania z oprogramowania pośredniczącego przekierowania HTTPS (UseHttpsRedirection) jest użycie oprogramowania pośredniczącego ponownego zapisywania adresów URL (AddRedirectToHttps). AddRedirectToHttps program może również ustawić kod stanu i port po wykonaniu przekierowania. Aby uzyskać więcej informacji, zobacz Artykuł Oprogramowanie pośredniczące ponownego zapisywania adresów URL.

Podczas przekierowywania do protokołu HTTPS bez wymagania dodatkowych reguł przekierowania zalecamy użycie oprogramowania pośredniczącego przekierowania HTTPS (UseHttpsRedirection) opisanego w tym temacie.

HTTP Strict Transport Security Protocol (HSTS)

Zgodnie z zasadami OWASP protokół HTTP Strict Transport Security (HSTS) to rozszerzenie zabezpieczeń , które jest określane przez aplikację internetową za pomocą nagłówka odpowiedzi. Gdy przeglądarka obsługująca usługi HSTS otrzymuje ten nagłówek:

  • Przeglądarka przechowuje konfigurację domeny, która uniemożliwia wysyłanie komunikacji za pośrednictwem protokołu HTTP. Przeglądarka wymusza całą komunikację za pośrednictwem protokołu HTTPS.
  • Przeglądarka uniemożliwia użytkownikowi używanie niezaufanych lub nieprawidłowych certyfikatów. Przeglądarka wyłącza monity, które umożliwiają użytkownikowi tymczasowe zaufanie do takiego certyfikatu.

Ponieważ usługa HSTS jest wymuszana przez klienta, ma pewne ograniczenia:

  • Klient musi obsługiwać moduł HSTS.
  • Usługa HSTS wymaga co najmniej jednego pomyślnego żądania HTTPS w celu ustanowienia zasad HSTS.
  • Aplikacja musi sprawdzić każde żądanie HTTP i przekierować lub odrzucić żądanie HTTP.

ASP.NET Core implementuje moduł HSTS za pomocą UseHsts metody rozszerzenia. Poniższy kod wywołuje UseHsts metodę , gdy aplikacja nie jest w trybie programowania:

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 nie jest zalecane w programowania, ponieważ ustawienia hsTS są wysoce buforowane przez przeglądarki. Domyślnie UseHsts wyklucza lokalny adres sprzężenia zwrotnego.

W przypadku środowisk produkcyjnych, które implementują protokół HTTPS po raz pierwszy, ustaw wartość początkową HstsOptions.MaxAge na małą przy użyciu jednej z TimeSpan metod. Ustaw wartość z godzin na nie więcej niż jeden dzień, jeśli musisz przywrócić infrastrukturę HTTPS do protokołu HTTP. Gdy masz pewność, że konfiguracja protokołu HTTPS jest zrównoważona, zwiększ wartość HSTS max-age . Często używana wartość to jeden rok.

Następujący wyróżniony kod:

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();
  • Ustawia parametr preload nagłówka Strict-Transport-Security . Wstępne ładowanie nie jest częścią specyfikacji RFC HSTS, ale jest obsługiwane przez przeglądarki internetowe do wstępnego ładowania witryn HSTS w nowej instalacji. Aby uzyskać więcej informacji, zobacz https://hstspreload.org/.
  • Włącza wartość includeSubDomain, która stosuje zasady HSTS do domen podrzędnych hosta.
  • Jawnie ustawia max-age parametr nagłówka Strict-Transport-Security na 60 dni. Jeśli nie zostanie ustawiona, wartość domyślna to 30 dni. Aby uzyskać więcej informacji, zobacz dyrektywę max-age.
  • Dodaje example.com do listy hostów do wykluczenia.

UseHsts wyklucza następujące hosty sprzężenia zwrotnego:

  • localhost : adres sprzężenia zwrotnego IPv4.
  • 127.0.0.1 : adres sprzężenia zwrotnego IPv4.
  • [::1] : adres sprzężenia zwrotnego IPv6.

Rezygnacja z protokołu HTTPS/HSTS podczas tworzenia projektu

W niektórych scenariuszach usługi zaplecza, w których zabezpieczenia połączeń są obsługiwane na publicznej krawędzi sieci, konfigurowanie zabezpieczeń połączeń w każdym węźle nie jest wymagane. Aplikacje internetowe generowane na podstawie szablonów w programie Visual Studio lub z nowego polecenia dotnet umożliwiają przekierowywanie HTTPS i hsTS. W przypadku wdrożeń, które nie wymagają tych scenariuszy, możesz zrezygnować z korzystania z protokołu HTTPS/HSTS podczas tworzenia aplikacji na podstawie szablonu.

Aby zrezygnować z protokołu HTTPS/HSTS:

Usuń zaznaczenie pola wyboru Konfiguruj dla protokołu HTTPS .

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

Ufaj certyfikatowi programistycznemu ASP.NET Core HTTPS w systemach Windows i macOS

Aby zapoznać się z przeglądarką Firefox, zobacz następną sekcję.

Zestaw SDK platformy .NET Core zawiera certyfikat dewelopera HTTPS. Certyfikat jest instalowany w ramach pierwszego uruchomienia. Na przykład dotnet --info generuje odmianę następujących danych wyjściowych:

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.

Zainstalowanie zestawu .NET Core SDK powoduje zainstalowanie certyfikatu dewelopera ASP.NET Core HTTPS w magazynie certyfikatów użytkownika lokalnego. Certyfikat został zainstalowany, ale nie jest zaufany. Aby zaufać certyfikatowi, wykonaj jednorazowy krok, aby uruchomić narzędzie dotnet dev-certs :

dotnet dev-certs https --trust

Następujące polecenie zapewnia pomoc dotyczącą dev-certs narzędzia:

dotnet dev-certs https --help

Ostrzeżenie

Nie należy tworzyć certyfikatu programistycznego w środowisku, które zostanie ponownie dystrybuowane, na przykład obraz kontenera lub maszyna wirtualna. Może to prowadzić do fałszowania i podniesienia uprawnień. Aby temu zapobiec, należy ustawić zmienną DOTNET_GENERATE_ASPNET_CERTIFICATE środowiskową na false wartość przed wywołaniem interfejsu wiersza polecenia platformy .NET po raz pierwszy. Spowoduje to pominięcie automatycznego generowania certyfikatu deweloperskiego ASP.NET Core podczas pierwszego uruchomienia interfejsu wiersza polecenia.

Ufaj certyfikatowi HTTPS za pomocą przeglądarki Firefox, aby zapobiec błędowi SEC_ERROR_INADEQUATE_KEY_USAGE

Przeglądarka Firefox używa własnego magazynu certyfikatów i w związku z tym nie ufa certyfikatom usług IIS Express ani Kestrel certyfikatom dewelopera.

Istnieją dwa podejścia do zaufania certyfikatowi HTTPS za pomocą przeglądarki Firefox, utworzenia pliku zasad lub skonfigurowania za pomocą przeglądarki FireFox. Skonfigurowanie za pomocą przeglądarki powoduje utworzenie pliku zasad, więc te dwa podejścia są równoważne.

Tworzenie pliku zasad w celu zaufania certyfikatowi HTTPS za pomocą przeglądarki Firefox

Utwórz plik zasad pod adresem:

Dodaj następujące polecenie JSWŁ. do pliku zasad przeglądarki Firefox:

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

Powyższy plik zasad sprawia, że certyfikaty zaufania Firefox z zaufanych certyfikatów w magazynie certyfikatów systemu Windows. W następnej sekcji przedstawiono alternatywne podejście do tworzenia poprzedniego pliku zasad przy użyciu przeglądarki Firefox.

Konfigurowanie zaufania certyfikatu HTTPS przy użyciu przeglądarki Firefox

Ustaw security.enterprise_roots.enabled = true przy użyciu następujących instrukcji:

  1. Wprowadź ciąg about:config w przeglądarce FireFox.
  2. Wybierz pozycję Zaakceptuj ryzyko i kontynuuj , jeśli zaakceptujesz ryzyko.
  3. Wybierz pozycję Pokaż wszystko
  4. Ustawić security.enterprise_roots.enabled = true
  5. Zamykanie i ponowne uruchamianie przeglądarki Firefox

Aby uzyskać więcej informacji, zobacz Konfigurowanie urzędów certyfikacji (CA) w przeglądarce Firefox i plik mozilla/policy-templates/README.

Jak skonfigurować certyfikat dewelopera dla platformy Docker

Zobacz ten problem z usługą GitHub.

Ufaj certyfikatowi HTTPS w systemie Linux

Ustanawianie relacji zaufania jest specyficzne dla dystrybucji i przeglądarki. Poniższe sekcje zawierają instrukcje dotyczące niektórych popularnych dystrybucji i przeglądarek Chromium (Edge i Chrome) oraz przeglądarki Firefox.

Ubuntu ufa certyfikatowi komunikacji między usługami

  1. Zainstaluj program OpenSSL 1.1.1h lub nowszy. Zapoznaj się z dystrybucją, aby uzyskać instrukcje dotyczące sposobu aktualizowania biblioteki OpenSSL.

  2. Uruchom następujące polecenia:

    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
    

Poprzednie polecenia:

  • Upewnij się, że został utworzony certyfikat dewelopera bieżącego użytkownika.
  • Eksportuje certyfikat z podwyższonymi uprawnieniami wymaganymi dla ca-certificates folderu przy użyciu środowiska bieżącego użytkownika.
  • Usunięcie flagi -E eksportuje certyfikat użytkownika głównego, generując go w razie potrzeby. Każdy nowo wygenerowany certyfikat ma inny odcisk palca. W przypadku uruchamiania jako użytkownik główny sudo i -E nie są potrzebne.

Ścieżka w poprzednim poleceniu jest specyficzna dla systemu Ubuntu. W przypadku innych dystrybucji wybierz odpowiednią ścieżkę lub użyj ścieżki dla urzędów certyfikacji.

Ufaj certyfikatowi HTTPS w systemie Linux przy użyciu przeglądarki Edge lub Chrome

W przypadku przeglądarek chromium w systemie Linux:

  • Zainstaluj program libnss3-tools dla dystrybucji.

  • Utwórz lub sprawdź, $HOME/.pki/nssdb czy folder istnieje na maszynie.

  • Wyeksportuj certyfikat za pomocą następującego polecenia:

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

    Ścieżka w poprzednim poleceniu jest specyficzna dla systemu Ubuntu. W przypadku innych dystrybucji wybierz odpowiednią ścieżkę lub użyj ścieżki dla urzędów certyfikacji.

  • Uruchom następujące polecenia:

    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
    
  • Zamknij i uruchom ponownie przeglądarkę.

Ufaj certyfikatowi za pomocą przeglądarki Firefox w systemie Linux

  • Wyeksportuj certyfikat za pomocą następującego polecenia:

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

    Ścieżka w poprzednim poleceniu jest specyficzna dla systemu Ubuntu. W przypadku innych dystrybucji wybierz odpowiednią ścieżkę lub użyj ścieżki dla urzędów certyfikacji (CA).

  • JSUtwórz plik ON pod adresem /usr/lib/firefox/distribution/policies.json z następującą zawartością:

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

Zobacz Konfigurowanie zaufania certyfikatu HTTPS przy użyciu przeglądarki Firefox w tym dokumencie, aby uzyskać alternatywny sposób konfigurowania pliku zasad przy użyciu przeglądarki.

Ufaj certyfikatowi za pomocą usługi Fedora 34

Zobacz ten komentarz w usłudze GitHub.

Ufaj certyfikatowi za pomocą innych dystrybucji

Zobacz ten problem z usługą GitHub.

Ufaj certyfikatowi HTTPS z podsystemu Windows dla systemu Linux

Podsystem Windows dla systemu Linux (WSL) generuje certyfikat programowania z podpisem własnym HTTPS. Aby skonfigurować magazyn certyfikatów systemu Windows w celu zaufania certyfikatowi WSL:

  • Wyeksportuj certyfikat dewelopera do pliku w systemie Windows:

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

    Gdzie $CREDENTIAL_PLACEHOLDER$ jest hasłem.

  • W oknie programu WSL zaimportuj wyeksportowany certyfikat w wystąpieniu WSL:

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

Poprzednie podejście to jednorazowa operacja na certyfikat i rozkład WSL. Jest to łatwiejsze niż eksportowanie certyfikatu za pośrednictwem i ponad. W przypadku zaktualizowania lub ponownego wygenerowania certyfikatu w oknach może być konieczne ponowne uruchomienie powyższych poleceń.

Rozwiązywanie problemów z certyfikatami, takich jak certyfikat nie jest zaufany

Ta sekcja zawiera pomoc, gdy certyfikat dewelopera ASP.NET Core HTTPS został zainstalowany i zaufany, ale nadal masz ostrzeżenia przeglądarki, że certyfikat nie jest zaufany. Certyfikat dewelopera ASP.NET Core HTTPS jest używany przez program Kestrel.

Aby naprawić certyfikat IIS Express, zobacz ten problem z usługą Stackoverflow .

Wszystkie platformy — certyfikat nie jest zaufany

Uruchom następujące polecenia:

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

Zamknij wszystkie otwarte wystąpienia przeglądarki. Otwórz nowe okno przeglądarki w aplikacji. Zaufanie certyfikatów jest buforowane przez przeglądarki.

dotnet dev-certs https --clean Fail

Powyższe polecenia rozwiązują większość problemów z zaufaniem przeglądarki. Jeśli przeglądarka nadal nie ufa certyfikatowi, postępuj zgodnie z poniższymi sugestiami dotyczącymi platformy.

Docker — certyfikat nie jest zaufany

  • Usuń folder C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
  • Wyczyść rozwiązanie. Usuń pojemnik i foldery obj .
  • Uruchom ponownie narzędzie programistyczne. Na przykład Visual Studio, Visual Studio Code lub Visual Studio dla komputerów Mac.

Windows — certyfikat nie jest zaufany

  • Sprawdź certyfikaty w magazynie certyfikatów. Powinien istnieć localhost certyfikat o przyjaznej ASP.NET Core HTTPS development certificate nazwie zarówno w obszarze Current User > Personal > Certificates , jak i Current User > Trusted root certification authorities > Certificates
  • Usuń wszystkie znalezione certyfikaty zarówno z osobistych, jak i zaufanych głównych urzędów certyfikacji. Nie usuwaj certyfikatu hosta lokalnego usług IIS Express.
  • Uruchom następujące polecenia:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Zamknij wszystkie otwarte wystąpienia przeglądarki. Otwórz nowe okno przeglądarki w aplikacji.

OS X — certyfikat nie jest zaufany

  • Otwórz pozycję KeyChain Access.
  • Wybierz pęk kluczy systemowych.
  • Sprawdź obecność certyfikatu localhost.
  • Sprawdź, czy zawiera + symbol na ikonie, aby wskazać, że jest on zaufany dla wszystkich użytkowników.
  • Usuń certyfikat z łańcucha kluczy systemowych.
  • Uruchom następujące polecenia:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Zamknij wszystkie otwarte wystąpienia przeglądarki. Otwórz nowe okno przeglądarki w aplikacji.

Zobacz Błąd HTTPS przy użyciu programu IIS Express (dotnet/AspNetCore #16892), aby rozwiązać problemy z certyfikatami w programie Visual Studio.

Certyfikat systemu Linux nie jest zaufany

Sprawdź, czy certyfikat skonfigurowany pod kątem zaufania to certyfikat dewelopera HTTPS użytkownika, który będzie używany przez Kestrel serwer.

Sprawdź domyślny certyfikat dewelopera Kestrel HTTPS bieżącego użytkownika w następującej lokalizacji:

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

Plik certyfikatu dewelopera Kestrel HTTPS to odcisk palca SHA1. Gdy plik zostanie usunięty za pośrednictwem metody dotnet dev-certs https --clean, zostanie on wygenerowany ponownie w razie potrzeby przy użyciu innego odcisku palca. Sprawdź odcisk palca wyeksportowanego certyfikatu zgodny z następującym poleceniem:

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

Jeśli certyfikat nie jest zgodny, może to być jeden z następujących elementów:

  • Stary certyfikat.
  • Wyeksportowano certyfikat dewelopera dla użytkownika głównego. W tym przypadku wyeksportuj certyfikat.

Certyfikat użytkownika głównego można sprawdzić pod adresem:

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

Certyfikat SSL usługi IIS Express używany w programie Visual Studio

Aby rozwiązać problemy z certyfikatem IIS Express, wybierz pozycję Napraw w instalatorze programu Visual Studio. Aby uzyskać więcej informacji, zobacz ten problem z usługą GitHub.

Zasady grupy uniemożliwiają zaufane certyfikaty z podpisem własnym

W niektórych przypadkach zasady grupy mogą uniemożliwić zaufane certyfikaty z podpisem własnym. Aby uzyskać więcej informacji, zobacz ten problem z usługą GitHub.

Dodatkowe informacje

Ostrzeżenie

Projekty interfejsu API

Nie używaj RequireHttpsAttribute w internetowych interfejsach API, które odbierają poufne informacje. RequireHttpsAttribute używa kodów stanu HTTP do przekierowywania przeglądarek z protokołu HTTP do protokołu HTTPS. Klienci interfejsu API mogą nie rozumieć ani przestrzegać przekierowań z protokołu HTTP do protokołu HTTPS. Tacy klienci mogą wysyłać informacje za pośrednictwem protokołu HTTP. Interfejsy API sieci Web powinny być:

  • Nie nasłuchiwanie przy użyciu protokołu HTTP.
  • Zamknij połączenie z kodem stanu 400 (nieprawidłowe żądanie) i nie obsłuż żądania.

Aby wyłączyć przekierowywanie HTTP w interfejsie API, ustaw ASPNETCORE_URLS zmienną środowiskową lub użyj flagi --urls wiersza polecenia. Aby uzyskać więcej informacji, zobacz Use multiple environments in ASP.NET Core and 5 ways to set the URL for an ASP.NET Core app by Andrew Lock (Używanie wielu środowisk w ASP.NET Core i 5 sposobów ustawiania adresów URL aplikacji ASP.NET Core przez andrew lock).

HsTS i projekty interfejsu API

Domyślne projekty interfejsu API nie obejmują usługi HSTS, ponieważ hsTS to zazwyczaj tylko instrukcja przeglądarki. Inne osoby wywołujące, takie jak telefon lub aplikacje klasyczne, nie przestrzegają instrukcji. Nawet w przeglądarkach pojedyncze uwierzytelnione wywołanie interfejsu API za pośrednictwem protokołu HTTP ma ryzyko związane z niezabezpieczonymi sieciami. Bezpieczne podejście polega na konfigurowaniu projektów interfejsu API w celu nasłuchiwania i odpowiadania za pośrednictwem protokołu HTTPS.

Wymagaj protokołu HTTPS

Zalecamy korzystanie z produkcyjnych aplikacji internetowych ASP.NET Core:

  • Oprogramowanie pośredniczące przekierowania HTTPS (UseHttpsRedirection) w celu przekierowania żądań HTTP do protokołu HTTPS.
  • Oprogramowanie pośredniczące HSTS (UseHsts) do wysyłania nagłówków protokołu HTTP Strict Transport Security Protocol (HSTS) do klientów.

Uwaga

Aplikacje wdrożone w konfiguracji zwrotnego serwera proxy umożliwiają serwerowi proxy obsługę zabezpieczeń połączeń (HTTPS). Jeśli serwer proxy obsługuje również przekierowywanie HTTPS, nie ma potrzeby używania oprogramowania pośredniczącego przekierowania HTTPS. Jeśli serwer proxy obsługuje również pisanie nagłówków HSTS (na przykład natywna obsługa hsTS w usługach IIS 10.0 (1709) lub nowszych, oprogramowanie pośredniczące HSTS nie jest wymagane przez aplikację. Aby uzyskać więcej informacji, zobacz Rezygnacja z protokołu HTTPS/HSTS podczas tworzenia projektu.

UseHttpsRedirection

Następujące wywołania UseHttpsRedirection kodu w Startup klasie:

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

Powyższy wyróżniony kod:

Zalecamy używanie tymczasowych przekierowań, a nie trwałych przekierowań. Buforowanie łączy może spowodować niestabilne zachowanie w środowiskach deweloperskich. Jeśli wolisz wysłać stały kod stanu przekierowania, gdy aplikacja znajduje się w środowisku nieprodukcyjnym, zobacz sekcję Konfigurowanie stałych przekierowań w środowisku produkcyjnym . Zalecamy używanie usługi HSTS do sygnalizowania klientom, że do aplikacji powinny być wysyłane tylko bezpieczne żądania zasobów (tylko w środowisku produkcyjnym).

Konfiguracja portów

Port musi być dostępny dla oprogramowania pośredniczącego w celu przekierowania niezabezpieczonego żądania do protokołu HTTPS. Jeśli port nie jest dostępny:

  • Przekierowanie do protokołu HTTPS nie występuje.
  • Oprogramowanie pośredniczące rejestruje ostrzeżenie "Nie można określić portu https do przekierowania".

Określ port HTTPS przy użyciu dowolnego z następujących metod:

  • Ustaw wartość HttpsRedirectionOptions.HttpsPort.

  • https_port Ustaw ustawienie hosta:

    • W konfiguracji hosta.

    • Ustawiając zmienną środowiskową ASPNETCORE_HTTPS_PORT .

    • Dodając wpis najwyższego poziomu w pliku appsettings.json:

      {
          "https_port": 443,
          "Logging": {
              "LogLevel": {
                  "Default": "Information",
                  "Microsoft": "Warning",
                  "Microsoft.Hosting.Lifetime": "Information"
              }
          },
          "AllowedHosts": "*"
      }
      
  • Wskaż port z bezpiecznym schematem przy użyciu zmiennej środowiskowej ASPNETCORE_URLS. Zmienna środowiskowa konfiguruje serwer. Oprogramowanie pośredniczące pośrednio odnajduje port HTTPS za pośrednictwem metody IServerAddressesFeature. Takie podejście nie działa we wdrożeniach odwrotnego serwera proxy.

  • W programowania ustaw adres URL HTTPS w pliku launchsettings.json. Włącz protokół HTTPS, gdy jest używana usługa IIS Express.

  • Skonfiguruj punkt końcowy adresu URL HTTPS na potrzeby publicznego wdrożenia Kestrel serwera lub serweraHTTP.sys . Aplikacja używa tylko jednego portu HTTPS . Oprogramowanie pośredniczące odnajduje port za pośrednictwem polecenia IServerAddressesFeature.

Uwaga

Gdy aplikacja jest uruchamiana w konfiguracji zwrotnego serwera proxy, IServerAddressesFeature nie jest dostępna. Ustaw port przy użyciu jednego z innych metod opisanych w tej sekcji.

Wdrożenia brzegowe

Jeśli Kestrel lub HTTP.sys jest używany jako publiczny serwer brzegowy lub Kestrel HTTP.sys należy skonfigurować nasłuchiwanie obu tych elementów:

  • Bezpieczny port, na którym jest przekierowywany klient (zazwyczaj 443 w środowisku produkcyjnym i 5001 w programowania).
  • Niezabezpieczony port (zazwyczaj 80 w środowisku produkcyjnym i 5000 w rozwoju).

Niezabezpieczony port musi być dostępny przez klienta, aby aplikacja odbierała niezabezpieczone żądanie i przekierowywała klienta do bezpiecznego portu.

Aby uzyskać więcej informacji, zobacz Kestrel konfiguracja punktu końcowego lub implementacja serwera internetowegoHTTP.sys w ASP.NET Core.

Scenariusze wdrażania

Każda zapora między klientem a serwerem musi również mieć otwarte porty komunikacyjne dla ruchu.

Jeśli żądania są przekazywane w konfiguracji zwrotnego serwera proxy, użyj oprogramowania pośredniczącego Nagłówki przekazywane przed wywołaniem oprogramowania pośredniczącego przekierowania HTTPS. Oprogramowanie pośredniczące nagłówków przekazywane aktualizuje Request.Schemeelement przy użyciu nagłówka X-Forwarded-Proto . Oprogramowanie pośredniczące zezwala na poprawne działanie identyfikatorów URI przekierowania i innych zasad zabezpieczeń. Gdy oprogramowanie pośredniczące nagłówków przekazywanych nie jest używane, aplikacja zaplecza może nie odbierać poprawnego schematu i kończy się w pętli przekierowania. Typowy komunikat o błędzie użytkownika końcowego polega na tym, że wystąpiło zbyt wiele przekierowań.

Podczas wdrażania w usłudze Azure App Service postępuj zgodnie ze wskazówkami w artykule Samouczek: wiązanie istniejącego niestandardowego certyfikatu SSL z usługą Azure Web Apps.

Opcje

Następujące wyróżnione wywołania AddHttpsRedirection kodu służące do konfigurowania opcji oprogramowania pośredniczącego:

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

Wywołanie AddHttpsRedirection jest konieczne tylko do zmiany wartości lub HttpsPortRedirectStatusCode.

Powyższy wyróżniony kod:

Konfigurowanie trwałych przekierowań w środowisku produkcyjnym

Oprogramowanie pośredniczące domyślnie wysyła element Status307TemporaryRedirect ze wszystkimi przekierowaniami. Jeśli wolisz wysłać stały kod stanu przekierowania, gdy aplikacja znajduje się w środowisku nieprogramowania, owiń konfigurację opcji oprogramowania pośredniczącego w czeku warunkowym dla środowiska nieprogramowania.

Podczas konfigurowania usług w programie 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;
        });
    }
}

Alternatywne podejście do oprogramowania pośredniczącego przekierowania HTTPS

Alternatywą dla korzystania z oprogramowania pośredniczącego przekierowania HTTPS (UseHttpsRedirection) jest użycie oprogramowania pośredniczącego ponownego zapisywania adresów URL (AddRedirectToHttps). AddRedirectToHttps może również ustawić kod stanu i port po wykonaniu przekierowania. Aby uzyskać więcej informacji, zobacz Adres URL Ponowne zapisywanie oprogramowania pośredniczącego.

Podczas przekierowywania do protokołu HTTPS bez wymagania dodatkowych reguł przekierowania zalecamy użycie oprogramowania pośredniczącego przekierowania HTTPS (UseHttpsRedirection) opisanego w tym temacie.

HTTP Strict Transport Security Protocol (HSTS)

Na program OWASP protokół HTTP Strict Transport Security (HSTS) to rozszerzenie zabezpieczeń , które jest określane przez aplikację internetową za pomocą nagłówka odpowiedzi. Gdy przeglądarka, która obsługuje moduł HSTS , otrzymuje ten nagłówek:

  • Przeglądarka przechowuje konfigurację domeny, która uniemożliwia wysyłanie komunikacji za pośrednictwem protokołu HTTP. Przeglądarka wymusza całą komunikację za pośrednictwem protokołu HTTPS.
  • Przeglądarka uniemożliwia użytkownikowi używanie niezaufanych lub nieprawidłowych certyfikatów. Przeglądarka wyłącza monity, które umożliwiają użytkownikowi tymczasowe zaufanie do takiego certyfikatu.

Ponieważ usługa HSTS jest wymuszana przez klienta, ma pewne ograniczenia:

  • Klient musi obsługiwać moduł HSTS.
  • Usługa HSTS wymaga co najmniej jednego pomyślnego żądania HTTPS w celu ustanowienia zasad HSTS.
  • Aplikacja musi sprawdzić każde żądanie HTTP i przekierować lub odrzucić żądanie HTTP.

ASP.NET Core implementuje usługę HSTS za pomocą UseHsts metody rozszerzenia. Następujący kod wywołuje, UseHsts gdy aplikacja nie jest w trybie programowania:

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 nie jest zalecane w programowania, ponieważ ustawienia hsTS są wysoce buforowane przez przeglądarki. Domyślnie UseHsts wyklucza lokalny adres sprzężenia zwrotnego.

W przypadku środowisk produkcyjnych, które implementują protokół HTTPS po raz pierwszy, ustaw wartość początkową HstsOptions.MaxAge na małą przy użyciu jednej z TimeSpan metod. Ustaw wartość z godzin na nie więcej niż jeden dzień, jeśli musisz przywrócić infrastrukturę HTTPS do protokołu HTTP. Po przekonaniu o zrównoważonym rozwoju konfiguracji protokołu HTTPS zwiększ wartość HSTS max-age ; często używana wartość to jeden rok.

Następujący kod:

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;
    });
}
  • Ustawia parametr wstępnego ładowania nagłówka Strict-Transport-Security . Wstępne ładowanie nie jest częścią specyfikacji HSTS RFC, ale jest obsługiwane przez przeglądarki internetowe do wstępnego ładowania witryn HSTS w nowej instalacji. Aby uzyskać więcej informacji, zobacz https://hstspreload.org/.
  • Włącza wartość includeSubDomain, która stosuje zasady HSTS do poddomeny hosta.
  • Jawnie ustawia max-age parametr nagłówka Strict-Transport-Security na 60 dni. Jeśli nie zostanie ustawiona, wartość domyślna to 30 dni. Aby uzyskać więcej informacji, zobacz dyrektywę max-age.
  • Dodaje example.com do listy hostów do wykluczenia.

UseHsts wyklucza następujące hosty sprzężenia zwrotnego:

  • localhost : adres sprzężenia zwrotnego IPv4.
  • 127.0.0.1 : adres sprzężenia zwrotnego IPv4.
  • [::1] : adres sprzężenia zwrotnego protokołu IPv6.

Rezygnacja z protokołu HTTPS/HSTS podczas tworzenia projektu

W niektórych scenariuszach usługi zaplecza, w których zabezpieczenia połączeń są obsługiwane na publicznej krawędzi sieci, konfigurowanie zabezpieczeń połączeń w każdym węźle nie jest wymagane. Aplikacje internetowe generowane na podstawie szablonów w programie Visual Studio lub z nowego polecenia dotnet umożliwiają przekierowywanie HTTPS i hsTS. W przypadku wdrożeń, które nie wymagają tych scenariuszy, możesz zrezygnować z protokołu HTTPS/HSTS po utworzeniu aplikacji na podstawie szablonu.

Aby zrezygnować z protokołu HTTPS/HSTS:

Usuń zaznaczenie pola wyboru Konfiguruj dla protokołu HTTPS .

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

Ufaj certyfikatowi programistycznemu ASP.NET Core HTTPS w systemach Windows i macOS

Aby zapoznać się z przeglądarką Firefox, zobacz następną sekcję.

Zestaw SDK platformy .NET Core zawiera certyfikat dewelopera HTTPS. Certyfikat jest instalowany w ramach pierwszego uruchomienia. Na przykład dotnet --info generuje odmianę następujących danych wyjściowych:

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.

Zainstalowanie zestawu .NET Core SDK powoduje zainstalowanie certyfikatu dewelopera ASP.NET Core HTTPS w magazynie certyfikatów użytkownika lokalnego. Certyfikat został zainstalowany, ale nie jest zaufany. Aby zaufać certyfikatowi, wykonaj jednorazowy krok, aby uruchomić narzędzie dotnet dev-certs :

dotnet dev-certs https --trust

Następujące polecenie zapewnia pomoc dotyczącą dev-certs narzędzia:

dotnet dev-certs https --help

Ostrzeżenie

Nie należy tworzyć certyfikatu programistycznego w środowisku, które zostanie ponownie dystrybuowane, na przykład obraz kontenera lub maszyna wirtualna. Może to prowadzić do fałszowania i podniesienia uprawnień. Aby temu zapobiec, należy ustawić zmienną DOTNET_GENERATE_ASPNET_CERTIFICATE środowiskową na false wartość przed wywołaniem interfejsu wiersza polecenia platformy .NET po raz pierwszy. Spowoduje to pominięcie automatycznego generowania certyfikatu deweloperskiego ASP.NET Core podczas pierwszego uruchomienia interfejsu wiersza polecenia.

Ufaj certyfikatowi HTTPS za pomocą przeglądarki Firefox, aby zapobiec błędowi SEC_ERROR_INADEQUATE_KEY_USAGE

Przeglądarka Firefox używa własnego magazynu certyfikatów i w związku z tym nie ufa certyfikatom usług IIS Express ani Kestrel certyfikatom dewelopera.

Istnieją dwa podejścia do zaufania certyfikatowi HTTPS za pomocą przeglądarki Firefox, utworzenia pliku zasad lub skonfigurowania za pomocą przeglądarki FireFox. Skonfigurowanie za pomocą przeglądarki powoduje utworzenie pliku zasad, więc te dwa podejścia są równoważne.

Tworzenie pliku zasad w celu zaufania certyfikatowi HTTPS za pomocą przeglądarki Firefox

Utwórz plik zasad pod adresem:

Dodaj następujące polecenie JSWŁ. do pliku zasad przeglądarki Firefox:

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

Powyższy plik zasad sprawia, że certyfikaty zaufania Firefox z zaufanych certyfikatów w magazynie certyfikatów systemu Windows. W następnej sekcji przedstawiono alternatywne podejście do tworzenia poprzedniego pliku zasad przy użyciu przeglądarki Firefox.

Konfigurowanie zaufania certyfikatu HTTPS przy użyciu przeglądarki Firefox

Ustaw security.enterprise_roots.enabled = true przy użyciu następujących instrukcji:

  1. Wprowadź ciąg about:config w przeglądarce FireFox.
  2. Wybierz pozycję Zaakceptuj ryzyko i kontynuuj , jeśli zaakceptujesz ryzyko.
  3. Wybierz pozycję Pokaż wszystko
  4. Ustawić security.enterprise_roots.enabled = true
  5. Zamykanie i ponowne uruchamianie przeglądarki Firefox

Aby uzyskać więcej informacji, zobacz Konfigurowanie urzędów certyfikacji (CA) w przeglądarce Firefox i plik mozilla/policy-templates/README.

Jak skonfigurować certyfikat dewelopera dla platformy Docker

Zobacz ten problem z usługą GitHub.

Ufaj certyfikatowi HTTPS w systemie Linux

Ustanawianie relacji zaufania jest specyficzne dla dystrybucji i przeglądarki. Poniższe sekcje zawierają instrukcje dotyczące niektórych popularnych dystrybucji i przeglądarek Chromium (Edge i Chrome) oraz przeglądarki Firefox.

Ubuntu ufa certyfikatowi komunikacji między usługami

  1. Zainstaluj program OpenSSL 1.1.1h lub nowszy. Zapoznaj się z dystrybucją, aby uzyskać instrukcje dotyczące sposobu aktualizowania biblioteki OpenSSL.

  2. Uruchom następujące polecenia:

    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
    

Poprzednie polecenia:

  • Upewnij się, że został utworzony certyfikat dewelopera bieżącego użytkownika.
  • Eksportuje certyfikat z podwyższonymi uprawnieniami wymaganymi dla ca-certificates folderu przy użyciu środowiska bieżącego użytkownika.
  • Usunięcie flagi -E eksportuje certyfikat użytkownika głównego, generując go w razie potrzeby. Każdy nowo wygenerowany certyfikat ma inny odcisk palca. W przypadku uruchamiania jako użytkownik główny sudo i -E nie są potrzebne.

Ścieżka w poprzednim poleceniu jest specyficzna dla systemu Ubuntu. W przypadku innych dystrybucji wybierz odpowiednią ścieżkę lub użyj ścieżki dla urzędów certyfikacji.

Ufaj certyfikatowi HTTPS w systemie Linux przy użyciu przeglądarki Edge lub Chrome

W przypadku przeglądarek chromium w systemie Linux:

  • Zainstaluj program libnss3-tools dla dystrybucji.

  • Utwórz lub sprawdź, $HOME/.pki/nssdb czy folder istnieje na maszynie.

  • Wyeksportuj certyfikat za pomocą następującego polecenia:

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

    Ścieżka w poprzednim poleceniu jest specyficzna dla systemu Ubuntu. W przypadku innych dystrybucji wybierz odpowiednią ścieżkę lub użyj ścieżki dla urzędów certyfikacji.

  • Uruchom następujące polecenia:

    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
    
  • Zamknij i uruchom ponownie przeglądarkę.

Ufaj certyfikatowi za pomocą przeglądarki Firefox w systemie Linux

  • Wyeksportuj certyfikat za pomocą następującego polecenia:

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

    Ścieżka w poprzednim poleceniu jest specyficzna dla systemu Ubuntu. W przypadku innych dystrybucji wybierz odpowiednią ścieżkę lub użyj ścieżki dla urzędów certyfikacji.

  • JSUtwórz plik ON pod /usr/lib/firefox/distribution/policies.json adresem z następującą zawartością:

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

Zobacz Konfigurowanie zaufania certyfikatu HTTPS przy użyciu przeglądarki Firefox w tym dokumencie, aby uzyskać alternatywny sposób konfigurowania pliku zasad przy użyciu przeglądarki.

Ufaj certyfikatowi przy użyciu usługi Fedora 34

Firefox w fedorze

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

Zaufanie dotnet-to-dotnet w usłudze Fedora

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

Aby uzyskać więcej informacji, zobacz ten komentarz w usłudze GitHub .

Ufaj certyfikatowi z innymi dystrybucjami

Zobacz ten problem z usługą GitHub.

Ufaj certyfikatowi HTTPS z podsystemu Windows dla systemu Linux

Podsystem Windows dla systemu Linux (WSL) generuje certyfikat deweloperski z podpisem własnym HTTPS. Aby skonfigurować magazyn certyfikatów systemu Windows w celu zaufania certyfikatowi WSL:

  • Wyeksportuj certyfikat dewelopera do pliku w systemie Windows:

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

    Gdzie $CREDENTIAL_PLACEHOLDER$ jest hasłem.

  • W oknie programu WSL zaimportuj wyeksportowany certyfikat w wystąpieniu programu WSL:

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

Powyższe podejście to jednorazowa operacja na certyfikat i dystrybucję WSL. Jest to łatwiejsze niż eksportowanie certyfikatu przez i ponad. W przypadku zaktualizowania lub ponownego wygenerowania certyfikatu w systemie Windows może być konieczne ponowne uruchomienie powyższych poleceń.

Rozwiązywanie problemów z certyfikatami, takich jak certyfikat niezauwierzyny

Ta sekcja zawiera pomoc, gdy certyfikat dewelopera ASP.NET Core HTTPS został zainstalowany i zaufany, ale nadal masz ostrzeżenia przeglądarki, że certyfikat nie jest zaufany. Certyfikat dewelopera ASP.NET Core HTTPS jest używany przez Kestrelprogram .

Aby naprawić certyfikat usług IIS Express, zobacz ten problem z usługą Stackoverflow .

Wszystkie platformy — certyfikat nie jest zaufany

Uruchom następujące polecenia:

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

Zamknij wszystkie otwarte wystąpienia przeglądarki. Otwórz nowe okno przeglądarki dla aplikacji. Zaufanie certyfikatu jest buforowane przez przeglądarki.

dotnet dev-certs https --clean Fail

Powyższe polecenia rozwiązują większość problemów z zaufaniem przeglądarki. Jeśli przeglądarka nadal nie ufa certyfikatowi, postępuj zgodnie z następującymi sugestiami dotyczącymi platformy.

Docker — certyfikat nie jest zaufany

  • Usuń folder C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
  • Wyczyść rozwiązanie. Usuń pojemnik i foldery obj .
  • Uruchom ponownie narzędzie programistyczne. Na przykład Visual Studio, Visual Studio Code lub Visual Studio dla komputerów Mac.

Windows — certyfikat nie jest zaufany

  • Sprawdź certyfikaty w magazynie certyfikatów. Certyfikat powinien mieć przyjazną localhostASP.NET Core HTTPS development certificate nazwę w obszarze Current User > Personal > Certificates i Current User > Trusted root certification authorities > Certificates
  • Usuń wszystkie znalezione certyfikaty zarówno z osobistych, jak i zaufanych głównych urzędów certyfikacji. Nie usuwaj certyfikatu hosta lokalnego usług IIS Express.
  • Uruchom następujące polecenia:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Zamknij wszystkie otwarte wystąpienia przeglądarki. Otwórz nowe okno przeglądarki dla aplikacji.

OS X — certyfikat nie jest zaufany

  • Otwórz pozycję KeyChain Access.
  • Wybierz pęk kluczy systemowych.
  • Sprawdź obecność certyfikatu hosta lokalnego.
  • Sprawdź, czy zawiera + symbol na ikonie, aby wskazać, że jest on zaufany dla wszystkich użytkowników.
  • Usuń certyfikat z łańcucha kluczy systemowych.
  • Uruchom następujące polecenia:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Zamknij wszystkie otwarte wystąpienia przeglądarki. Otwórz nowe okno przeglądarki dla aplikacji.

Zobacz Błąd HTTPS przy użyciu usług IIS Express (dotnet/AspNetCore #16892), aby rozwiązać problemy z certyfikatami w programie Visual Studio.

Certyfikat systemu Linux nie jest zaufany

Sprawdź, czy certyfikat konfigurowany pod kątem zaufania jest certyfikatem dewelopera Kestrel HTTPS użytkownika, który będzie używany przez serwer.

Sprawdź domyślny certyfikat dewelopera Kestrel HTTPS bieżącego użytkownika w następującej lokalizacji:

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

Plik certyfikatu dewelopera Kestrel HTTPS to odcisk palca SHA1. Gdy plik zostanie usunięty za pośrednictwem polecenia dotnet dev-certs https --clean, zostanie on wygenerowany ponownie w razie potrzeby przy użyciu innego odcisku palca. Sprawdź odcisk palca wyeksportowanego certyfikatu zgodny z następującym poleceniem:

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

Jeśli certyfikat nie jest zgodny, może to być jeden z następujących elementów:

  • Stary certyfikat.
  • Wyeksportowany certyfikat dewelopera dla użytkownika głównego. W tym przypadku wyeksportuj certyfikat.

Certyfikat użytkownika głównego można sprawdzić pod adresem:

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

Certyfikat SSL usług IIS Express używany w programie Visual Studio

Aby rozwiązać problemy z certyfikatem usług IIS Express, wybierz pozycję Napraw w instalatorze programu Visual Studio. Aby uzyskać więcej informacji, zobacz ten problem z usługą GitHub.

Dodatkowe informacje