Wymuszanie protokołu HTTPS w ASP.NET Core

Przez David Galvan i Rick Anderson

W tym dokumencie pokazano, jak:

• Wymagaj protokołu HTTPS dla wszystkich żądań.
• Przekierowuje 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 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ć lub 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 ASPNETCORE_URLS zmienną środowiskową lub użyj --urls flagi wiersza polecenia. Aby uzyskać więcej informacji, zobacz Use multiple environments in ASP.NET Core and 8 ways to set the URL for an ASP.NET Core app by Andrew Lock (Używanie wielu środowisk w programie ASP.NET Core i 8 sposobów ustawiania adresów URL dla aplikacji ASP.NET Core przez andrew lock).

Usługi 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 wiąże się z ryzykiem w niezabezpieczonych sieciach. Bezpieczne podejście polega na konfigurowaniu projektów interfejsu API w celu nasłuchiwania i odpowiadania tylko 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 .ERR_INVALID_REDIRECT on the CORS preflight request

Projekty interfejsu API mogą odrzucać żądania HTTP, a nie 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ż 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 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:

• Używa wartości domyślnej HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Używa wartości domyślnej HttpsRedirectionOptions.HttpsPort (null), chyba że zostanie zastąpiona przez zmienną ASPNETCORE_HTTPS_PORTS środowiskową lub IServerAddressesFeature.

Zalecamy używanie przekierowań tymczasowych, a nie stał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 na potrzeby przekierowania".

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

• Ustaw wartość HttpsRedirectionOptions.HttpsPort.

• https_portUstaw ustawienie hosta:

  • W konfiguracji hosta.

  • Ustawiając zmienną ASPNETCORE_HTTPS_PORTS środowiskową.

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

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

• Wskaż port ze schematem bezpiecznym 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 zarówno Properties/launchsettings.json dla usług IIS Express, jak Kestrel i IIS Express. launchsettings.json jest używany tylko na komputerze lokalnym.

• Skonfiguruj punkt końcowy adresu URL HTTPS dla publicznego wdrożenia serwera lub serwera HTTP.sys brzegowegoKestrel. 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 jest przekierowywany klient (zazwyczaj 443 w środowisku produkcyjnym i 5001 w programowania).
• Niezabezpieczony port (zazwyczaj 80 w środowisku produkcyjnym i 5000 w programowania).

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 internetowego HTTP.sys w usłudze 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 przekazywanych 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 aplikacja systemu Azure 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 static Microsoft.AspNetCore.Http.StatusCodes;

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 = Status307TemporaryRedirect;
    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 konieczne tylko do zmiany wartości elementu HttpsPort lub RedirectStatusCode.

Powyższy wyróżniony kod:

• Ustawia HttpsRedirectionOptions.RedirectStatusCode wartość Status307TemporaryRedirect, która jest wartością domyślną. Użyj pól StatusCodes klasy dla przypisań do RedirectStatusCode.
• Ustawia port HTTPS na 5001.

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ć stały kod stanu przekierowania, gdy aplikacja znajduje się w środowisku nieprogramowania, zawiń konfigurację opcji oprogramowania pośredniczącego w czeku warunkowym dla środowiska nieprogramowania.

Podczas konfigurowania usług w programie Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        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 używania 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 Ponowne zapisywanie oprogramowania pośredniczącego pod adresem 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)

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 obsługującą 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 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 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 podczas programowania, ponieważ ustawienia HSTS są wysoce buforowalne 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 początkową HstsOptions.MaxAge wartość 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 static Microsoft.AspNetCore.Http.StatusCodes;

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 = Status307TemporaryRedirect;
    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 HSTS RFC, ale jest obsługiwane przez przeglądarki internetowe w celu wstępnego ładowania witryn HSTS w nowej instalacji. W celu uzyskania więcej informacji, zobacz następujący temat: 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 protokołu HTTPS/HSTS podczas tworzenia aplikacji na podstawie szablonu.

Aby zrezygnować z protokołu HTTPS/HSTS:

Program Visual Studio

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

.NET Core CLI

--no-https Użyj opcji . Na przykład

dotnet new webapp --no-https

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 tworzy 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 ufać certyfikatowi, wykonaj jednorazowy krok, aby uruchomić narzędzie dotnet dev-certs :

dotnet dev-certs https --trust

Następujące polecenie zapewnia pomoc w narzędziu dev-certs :

dotnet dev-certs https --help

Ostrzeżenie

Nie należy tworzyć certyfikatu programistycznego w środowisku, które będzie redystrybuowane, takie jak obraz kontenera lub maszyna wirtualna. Może to prowadzić do fałszowania i podniesienia uprawnień. Aby temu zapobiec, ustaw 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 dlatego nie ufa certyfikatom usług IIS Express ani Kestrel deweloperom.

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 dwa podejścia są równoważne.

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

Utwórz plik zasad (policies.json) pod adresem:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• Macos: Firefox.app/Contents/Resources/distribution
• Linux: zobacz Ufanie certyfikatowi za pomocą przeglądarki Firefox w systemie Linux w tym dokumencie.

Dodaj następujące JSpolecenie WŁĄCZONE 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ź about:config wartość 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. Zamknij i uruchom ponownie przeglądarkę Firefox

Aby uzyskać więcej informacji, zobacz Konfigurowanie urzędów certyfikacji 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 zaufania to dystrybucja i określona przeglądarka. Poniższe sekcje zawierają instrukcje dotyczące niektórych popularnych dystrybucji oraz przeglądarek Chromium (Edge i Chrome) oraz przeglądarki Firefox.

Ubuntu ufa certyfikatowi komunikacji między usługami

Poniższe instrukcje nie działają w przypadku niektórych wersji systemu Ubuntu, takich jak 20.04. Aby uzyskać więcej informacji, zobacz problem z usługą GitHub dotnet/AspNetCore.Docs #23686.

1. Zainstaluj program OpenSSL 1.1.1h lub nowszy. Zapoznaj się z dystrybucją, aby uzyskać instrukcje dotyczące 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.
• -E Usunięcie flagi 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

Ubuntu

W przypadku przeglądarek chromium w systemie Linux:

• libnss3-tools Zainstaluj element 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 za pomocą następującego polecenia:

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

Uwaga: Ubuntu 21.10 Firefox jest dostarczany jako pakiet przystawki, a folder instalacyjny to /snap/firefox/current/usr/lib/firefox.

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.

Red Hat Enterprise Linux

Ostrzeżenie

Poniższe instrukcje są przeznaczone tylko do celów programistycznych. Nie używaj certyfikatów wygenerowanych w tych instrukcjach dla środowiska produkcyjnego.

Te instrukcje korzystają ze starszegonarzędzia certutil Mozilla w witrynie https://firefox-source-docs.mozilla.org/security/nss/legacy/tools/nss_tools_certutil/index.html. Instrukcje mogą być aktualizowane w miarę odnajdywanego nowoczesnych narzędzi i praktyk.

Uwaga

Niewłaściwe użycie certyfikatów TLS może prowadzić do fałszowania.

Napiwek

Instrukcje dotyczące prawidłowych certyfikatów produkcyjnych można znaleźć w dokumentacji systemu RHEL. RHEL8 Certyfikaty TLS RHEL9 CertyfikatyTLS RHEL9 System certyfikatówRHEL9

Instalowanie zależności

dnf install nss-tools

Eksportowanie certyfikatu dewelopera podstawowego ASP.NET

Ważne

Zastąp ${ProjectDirectory} element katalogiem projektów. Zastąp ${CertificateName} ciąg nazwą, którą będziesz w stanie zidentyfikować w przyszłości.

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

Uwaga

Jeśli używasz narzędzia git, dodaj certyfikat do pliku ${ProjectDirectory}/.gitignore lub ${ProjectDirectory}/.git/info/exclude. Zapoznaj się z dokumentacją usługi Git, aby uzyskać informacje o tych plikach.

Napiwek

Wyeksportowany certyfikat można przenieść poza repozytorium Git i zastąpić wystąpienia ${ProjectDirectory}elementu , w poniższych instrukcjach nową lokalizacją.

Importowanie certyfikatu dewelopera podstawowego ASP.NET

Ważne

Zastąp ${UserProfile} ciąg profilem, którego zamierzasz użyć. Nie zamieniaj $HOMEzmiennej , jest to zmienna środowiskowa do katalogu użytkownika.

Przeglądarki oparte na chromium

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Mozilla Firefox

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Tworzenie aliasu do testowania za pomocą narzędzia Curl

Ważne

Jeśli planujesz przetestować program curl, nie usuwaj wyeksportowanego certyfikatu. Musisz utworzyć alias odwołujący się do niego w profilu użytkownika $SHELL

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

Czyszczenie certyfikatów programistycznych

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Uwaga

Usuń utworzony wcześniej alias curl

SUSE Linux Enterprise Server

Zobacz ten problem z usługą GitHub

Ufaj certyfikatowi za pomocą usługi Fedora 34

Zobacz:

• Ten komentarz usługi GitHub
• Fedora: używanie udostępnionych certyfikatów systemowych
• Konfigurowanie środowiska programistycznego .NET w usłudze Fedora.

Ufaj certyfikatowi z innymi dystrybucjami

Zobacz ten problem z usługą GitHub.

Ufaj certyfikatowi HTTPS z Podsystem Windows dla systemu Linux

Poniższe instrukcje nie działają w przypadku niektórych dystrybucji systemu Linux, takich jak Ubuntu 20.04. Aby uzyskać więcej informacji, zobacz problem z usługą GitHub dotnet/AspNetCore.Docs #23686.

Podsystem Windows dla systemu Linux (WSL) generuje certyfikat deweloperski z podpisem własnym HTTPS, który domyślnie nie jest zaufany w systemie Windows. Najprostszym sposobem zaufania systemu Windows do certyfikatu WSL jest skonfigurowanie programu WSL do używania tego samego certyfikatu co system Windows:

• W systemie Windows wyeksportuj certyfikat dewelopera do pliku:

  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 programu 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 za pośrednictwem. 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 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 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 w 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 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 lub Visual Studio Code.

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, jak 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 localhost 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ęku kluczy systemowych.
• Sprawdź obecność certyfikatu localhost.
• Sprawdź, czy zawiera symbol ikony + , aby wskazać, że jest 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 konfigurowany pod kątem zaufania to certyfikat 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 dotnet dev-certs https --cleanmetody , zostanie on wygenerowany ponownie, gdy będzie potrzebny 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ługi 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 w serwisie 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 w serwisie GitHub.

Dodatkowe informacje

• Konfigurowanie platformy ASP.NET Core pod kątem pracy z serwerami proxy i modułami równoważenia obciążenia
• Host ASP.NET Core w systemie Linux przy użyciu platformy Apache: konfiguracja protokołu HTTPS
• Host ASP.NET Core w systemie Linux z serwerem Nginx: konfiguracja protokołu HTTPS
• Jak skonfigurować protokół SSL w usługach IIS
• Konfigurowanie punktów końcowych dla serwera internetowego ASP.NET Core Kestrel
• Obsługa przeglądarki HSTS w programie OWASP