Wymuszanie protokołu HTTPS w ASP.NET Core

Przez David Galvan i Rick Anderson

W tym artykule 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 używaj w webowych 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 albo:

• Nie nasłuchuj na 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ą środowiskową ASPNETCORE_URLS lub użyj flagi wiersza poleceń --urls. 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 programy dzwoniące, takie jak aplikacje telefoniczne lub komputerowe, 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 HTTPS przez UseHttpsRedirection, kończą się niepowodzeniem podczas żądania wstępnego CORS w ERR_INVALID_REDIRECT.

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

Wymagaj protokołu HTTPS

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

• Oprogramowanie pośredniczące do przekierowywania poprzez HTTPS (UseHttpsRedirection) służy do przekierowywania żądań HTTP na HTTPS.
• Oprogramowanie middleware 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ą obsługę bezpieczeństwa połączeń (HTTPS) przez serwer proxy. 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), middleware HSTS nie jest wymagane przez aplikację. Aby uzyskać więcej informacji, zobacz Rezygnacja z protokołu HTTPS/HSTS podczas tworzenia projektu.

UseHttpsRedirection

W poniższym kodzie wywoływane jest UseHttpsRedirection w pliku Program.cs.

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_PORT ś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_port Ustaw ustawienie hosta:

  • W konfiguracji hosta.

  • Ustawiając zmienną ASPNETCORE_HTTPS_PORT środowiskową.

  • Dodając wpis najwyższego poziomu w 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. Podejście to nie działa we wdrożeniach reverse proxy.

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

• Skonfiguruj punkt końcowy URL HTTPS dla wdrożenia brzegowego serwera publicznego Kestrel 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 odwróconego serwera proxy, IServerAddressesFeature nie jest dostępna. Ustaw port przy użyciu jednej z innych metod opisanych w tej sekcji.

Wdrożenia na brzegu sieci

Jeśli Kestrel albo HTTP.sys jest używany jako publiczny serwer brzegowy, Kestrel lub HTTP.sys musi być skonfigurowany do nasłuchiwania na obu:

• Bezpieczny port, na który jest przekierowywany klient (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 przez klienta, aby aplikacja odbierała niezabezpieczone żądanie i przekierowywała klienta do bezpiecznego portu.

Aby uzyskać więcej informacji, zobacz Kestrel konfigurację punktu końcowego lub implementację serwera sieciowego HTTP.sys w ASP.NET Core.

Scenariusze wdrażania

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

Jeśli żądania są przekazywane w konfiguracji zwrotnego serwera proxy, użyj oprogramowania pośredniczącego nagłówków przekazywanych przed wywołaniem oprogramowania pośredniczącego przekierowania HTTPS. Oprogramowanie pośredniczące aktualizuje element Request.Scheme 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 pośrednik do przekazywania nagłówków nie jest używany, aplikacja zaplecza może nie odbierać poprawnego schematu, co prowadzi do 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 Samouczku: wiązanie istniejącego niestandardowego certyfikatu SSL z usługą Azure Web Apps.

Opcje

Następujący wyróżniony kod wywołuje AddHttpsRedirection, aby skonfigurować ustawienia 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 na Status307TemporaryRedirect, co 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 Status307TemporaryRedirect przy wszystkich przekierowaniach. Jeśli wolisz wysłać stały kod stanu przekierowania, gdy aplikacja znajduje się w środowisku innym niż deweloperskie, zawiń konfigurację opcji middleware w sprawdzenie warunkowe dla tego środowiska.

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 środowiska 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 może również ustawić kod stanu i port podczas wykonywania przekierowania. Aby uzyskać więcej informacji, zobacz Middleware do przepisania 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 artykule.

HTTP Strict Transport Security Protocol (HSTS)

Według programu OWASP, HTTP Strict Transport Security (HSTS) jest opcjonalnym rozszerzeniem zabezpieczeń określonym przez aplikację internetową przy użyciu 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 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 gdy aplikacja nie jest w trybie deweloperskim:

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 zalecany w środowisku produkcyjnym, ponieważ ustawienia HSTS są łatwo zapamiętywane w pamięci podręcznej przez przeglądarki. Domyślnie UseHsts wyklucza lokalny adres pętli zwrotnej.

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 preładowania nagłówka Strict-Transport-Security. Wstępne ładowanie nie jest częścią specyfikacji RFC HSTS, ale jest obsługiwane przez przeglądarki internetowe, aby wstępnie ładować witryny HSTS podczas świeżej instalacji. Aby uzyskać więcej informacji, zobacz https://hstspreload.org/.
• Włącza includeSubDomain, co stosuje politykę HSTS do poddomen 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 pętli zwrotnej:

• localhost : adres pętli zwrotnej IPv4.
• 127.0.0.1 : adres pętli zwrotnej IPv4.
• [::1] : adres pętli zwrotnej 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 polecenia dotnet new 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:

Visual Studio

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

.NET CLI (Interfejs wiersza polecenia .NET)

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

dotnet new webapp --no-https

Ufaj certyfikatowi programistycznemu ASP.NET Core HTTPS

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ć dotnet dev-certs narzędzie:

dotnet dev-certs https --trust

Następujące polecenie dostarcza informacje o narzędziu dotnet 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.

Jak skonfigurować certyfikat dewelopera dla platformy Docker

Zobacz ten problem z usługą GitHub.

Zagadnienia specyficzne dla systemu Linux

Dystrybucje systemu Linux różnią się znacząco w sposobie oznaczania certyfikatów jako zaufanych. Chociaż dotnet dev-certs oczekuje się, że będzie szeroko stosowany, jest on oficjalnie obsługiwany tylko w systemach Ubuntu i Fedora, a w szczególności ma na celu zapewnienie zaufania do przeglądarek Firefox i Chromium (Edge, Chrome i Chromium).

Zależności

Aby ustanowić zaufanie OpenSSL, narzędzie openssl musi znajdować się w ścieżce.

Aby uzyskać zaufanie przeglądarki (na przykład w Edge lub Firefox), narzędzie certutil musi znajdować się w ścieżce.

Zaufanie protokołu OpenSSL

Gdy certyfikat dewelopera ASP.NET Core jest zaufany, jest eksportowany do folderu w katalogu głównym bieżącego użytkownika. Aby OpenSSL i klienci, którzy go używają, rozpoznawały ten folder, musisz ustawić zmienną środowiskową SSL_CERT_DIR. Możesz to zrobić w jednej sesji, uruchamiając polecenie takie jak export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (dokładna wartość będzie widoczna w danych wyjściowych po przekazaniu --verbose), lub dodając je do pliku konfiguracyjnego specyficznego dla dystrybucji i powłoki (na przykład .profile).

Jest to wymagane, aby narzędzia takie jak curl ufały certyfikatowi programistycznemu. Możesz także alternatywnie przekazać -CAfile lub -CApath do każdego wywołania curl.

Należy pamiętać, że wymaga to wersji 1.1.1h lub nowszej lub 3.0.0 lub nowszej, w zależności od używanej wersji głównej.

Jeśli zaufanie OpenSSL znajduje się w złym stanie (na przykład jeśli dotnet dev-certs https --clean nie można go usunąć), często można naprawić sytuację przy użyciu narzędzia c_rehash.

Nadpisania

Jeśli używasz innej przeglądarki z własnym magazynem usług zabezpieczeń sieci (NSS), możesz użyć DOTNET_DEV_CERTS_NSSDB_PATHS zmiennej środowiskowej, aby określić rozdzielaną dwukropkami listę katalogów NSS (na przykład katalog zawierający cert9.db) do którego ma zostać dodany certyfikat deweloperski.

Jeśli przechowujesz certyfikaty, którym program OpenSSL ma ufać w określonym katalogu, możesz użyć zmiennej środowiskowej DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY , aby wskazać, gdzie jest.

Ostrzeżenie

Jeśli ustawisz jedną z tych zmiennych, ważne jest, aby były ustawione na te same wartości przy każdej aktualizacji zaufania. Jeśli lokalizacje zostaną zmienione, narzędzie nie będzie wiedziało o certyfikatach w poprzednich lokalizacjach (na przykład w celu ich usunięcia).

Korzystanie z programu sudo

Podobnie jak na innych platformach, certyfikaty programistyczne są przechowywane i uważane za zaufane oddzielnie dla każdego użytkownika. W związku z tym, jeśli uruchomisz dotnet dev-certs jako inny użytkownik (na przykład przy użyciu sudo), to ten użytkownik (na przykład ) zaufa certyfikatowi programistycznemu.

Ufaj certyfikatowi HTTPS w systemie Linux za pomocą certyfikatów linux-dev-certs

linux-dev-certs to narzędzie globalne typu open source, obsługiwane przez społeczność, które zapewnia wygodny sposób tworzenia i zaufania certyfikatowi dewelopera w systemie Linux. Narzędzie nie jest utrzymywane ani obsługiwane przez firmę Microsoft.

Następujące polecenia instalują narzędzie i tworzą zaufany certyfikat dewelopera:

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

Aby uzyskać więcej informacji lub zgłosić problemy, zobacz repozytorium GitHub linux-dev-certs.

SUSE Linux Enterprise Server

Zobacz ten problem z usługą GitHub

Rozwiązywanie problemów z certyfikatami, takich jak brak zaufania do certyfikatu

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 programisty ASP.NET Core HTTPS jest używany przez Kestrel.

Aby naprawić certyfikat usług IIS Express, zobacz ten wątek na 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 do certyfikatu jest buforowane przez przeglądarki.

dotnet dev-certs https --clean Nie powiodło się

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ń foldery bin i 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ć certyfikat localhost o przyjaznej nazwie ASP.NET Core HTTPS development certificate zarówno pod Current User > Personal > Certificates jak i Current User > Trusted root certification authorities > Certificates
• Usuń wszystkie znalezione certyfikaty zarówno z osobistych, jak i z zaufanych głównych urzędów certyfikacyjnych. 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 KeyChain Access.
• Wybierz pęk 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. Upewnij się, że odcisk palca wyeksportowanego certyfikatu jest 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.
• Dla użytkownika głównego został wyeksportowany certyfikat dewelopera. 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ą zaufanie do certyfikatów z podpisem własnym

W niektórych przypadkach zasady grupy mogą uniemożliwić zaufanie certyfikatom samopodpisanym. 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 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