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 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 UseHttpsRedirection , kończą się niepowodzeniem w ERR_INVALID_REDIRECT żądaniu wstępnym CORS.
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_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_portUstaw 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 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.jsondla usług IIS Express, jak Kestrel i IIS Express.launchsettings.jsonjest 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 artykule.
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. 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-ageparametr nagłówkaStrict-Transport-Securityna 60 dni. Jeśli nie zostanie ustawiona, wartość domyślna to 30 dni. Aby uzyskać więcej informacji, zobacz dyrektywę max-age. - Dodaje
example.comdo 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:
Usuń zaznaczenie pola wyboru Konfiguruj dla protokołu 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 zapewnia pomoc w 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, openssl narzędzie musi znajdować się w ścieżce.
Aby ustanowić zaufanie przeglądarki (na przykład w przeglądarce Edge lub Firefox), certutil narzędzie musi znajdować się w ścieżce.
Zaufanie protokołu OpenSSL
Gdy certyfikat dewelopera ASP.NET Core jest zaufany, jest eksportowany do folderu w katalogu bieżącego użytkownika home . Aby program OpenSSL (i klienci, którzy go używają), pobierz ten folder, musisz ustawić zmienną SSL_CERT_DIR środowiskową. 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 znajdować się w danych wyjściowych po --verbose przekazaniu) lub dodając do niego plik konfiguracji (specyficzny dla dystrybucji i powłoki) (na przykład .profile).
Jest to wymagane, aby narzędzia takie jak curl ufały certyfikatowi programistycznemu. Alternatywnie możesz przekazać -CAfile lub -CApath do każdego curl wywołania.
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 przechodzi w nieprawidłowy stan (na przykład jeśli dotnet dev-certs https --clean nie można go usunąć), często można ustawić elementy właściwe przy użyciu c_rehash narzędzia.
Przesłonięcia
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 zmienią się, narzędzie nie będzie wiedziało o certyfikatach w poprzednich lokalizacjach (na przykład w celu ich wyczyszczenia).
Korzystanie z programu sudo
Podobnie jak na innych platformach, certyfikaty programistyczne są przechowywane i zaufane oddzielnie dla każdego użytkownika. W związku z tym, jeśli uruchomisz dotnet dev-certs go jako inny użytkownik (na przykład przy użyciu sudo), jest to użytkownik (na przykład root), który będzie ufać 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 obsługiwane 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.
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ć
localhostcertyfikat o przyjaznejASP.NET Core HTTPS development certificatenazwie zarówno w obszarze, jakCurrent User > Personal > CertificatesiCurrent 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 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
Uwaga
Jeśli używasz zestawu .NET 9 SDK lub nowszego, zobacz zaktualizowane procedury systemu Linux w wersji .NET 9 tego artykułu.
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 UseHttpsRedirection , kończą się niepowodzeniem w ERR_INVALID_REDIRECT żądaniu wstępnym CORS.
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_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_portUstaw 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 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.jsondla usług IIS Express, jak Kestrel i IIS Express.launchsettings.jsonjest 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 artykule.
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. 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-ageparametr nagłówkaStrict-Transport-Securityna 60 dni. Jeśli nie zostanie ustawiona, wartość domyślna to 30 dni. Aby uzyskać więcej informacji, zobacz dyrektywę max-age. - Dodaje
example.comdo 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:
Usuń zaznaczenie pola wyboru Konfiguruj dla protokołu 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ć dotnet dev-certs narzędzie:
dotnet dev-certs https --trust
Następujące polecenie zapewnia pomoc w 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.
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 artykule.
Dodaj następujący kod JSON 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:
- Wprowadź
about:configwartość w przeglądarce FireFox. - Wybierz pozycję Zaakceptuj ryzyko i kontynuuj , jeśli zaakceptujesz ryzyko.
- Wybierz pozycję Pokaż wszystko
- Zbiór
security.enterprise_roots.enabled=true - 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.
Zainstaluj program OpenSSL 1.1.1h lub nowszy. Zapoznaj się z dystrybucją, aby uzyskać instrukcje dotyczące aktualizowania biblioteki OpenSSL.
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-certificatesfolderu przy użyciu środowiska bieżącego użytkownika. -EUsunię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łównysudoi-Enie 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:
libnss3-toolsZainstaluj element dla dystrybucji.Utwórz lub sprawdź,
$HOME/.pki/nssdbczy 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.crtZamknij 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 .
Utwórz plik JSON pod
/usr/lib/firefox/distribution/policies.jsonadresem 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 artykule, aby uzyskać alternatywny sposób konfigurowania pliku zasad przy użyciu przeglądarki.
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$ --trustGdzie
$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ć
localhostcertyfikat o przyjaznejASP.NET Core HTTPS development certificatenazwie zarówno w obszarze, jakCurrent User > Personal > CertificatesiCurrent 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 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
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 5 ways to set the URL for an ASP.NET Core app by Andrew Lock (Używanie wielu środowisk w środowisku ASP.NET Core i 5 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.
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 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:
- 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_portUstaw 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": "Warning", "Microsoft.Hosting.Lifetime": "Information" } }, "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.
W programowania ustaw adres URL HTTPS w pliku
launchsettings.json. Włącz protokół HTTPS, gdy jest używany program IIS Express.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:
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 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 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 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 artykule.
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:
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 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 kod powoduje:
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 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. 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-ageparametr nagłówkaStrict-Transport-Securityna 60 dni. Jeśli nie zostanie ustawiona, wartość domyślna to 30 dni. Aby uzyskać więcej informacji, zobacz dyrektywę max-age. - Dodaje
example.comdo 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:
Usuń zaznaczenie pola wyboru Konfiguruj dla protokołu 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 uruchomienie dotnet new webapp po raz pierwszy powoduje wygenerowanie odmiany następujących danych wyjściowych:
Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https
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 zapewnia pomoc w 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.
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 dalszej części tego artykułu.
Dodaj następujący kod JSON 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:
- Wprowadź
about:configwartość w przeglądarce FireFox. - Wybierz pozycję Zaakceptuj ryzyko i kontynuuj , jeśli zaakceptujesz ryzyko.
- Wybierz pozycję Pokaż wszystko.
- Ustaw wartość
security.enterprise_roots.enabled=true. - 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
Zainstaluj program OpenSSL 1.1.1h lub nowszy. Zapoznaj się z dystrybucją, aby uzyskać instrukcje dotyczące aktualizowania biblioteki OpenSSL.
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.
- Wyeksportuj certyfikat z podwyższonymi uprawnieniami wymaganymi dla
ca-certificatesfolderu przy użyciu środowiska bieżącego użytkownika. - Usuń flagę
-E, aby wyeksportować 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łównysudoi-Enie 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:
libnss3-toolsZainstaluj element dla dystrybucji.Utwórz lub sprawdź,
$HOME/.pki/nssdbczy 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.crtZamknij 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 .
Utwórz plik JSON pod
/usr/lib/firefox/distribution/policies.jsonadresem 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 artykule, aby uzyskać alternatywny sposób konfigurowania pliku zasad przy użyciu przeglądarki.
Ufaj certyfikatowi za pomocą usługi Fedora 34
Firefox w fedora
echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js
echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg
echo "{
\"policies\": {
\"Certificates\": {
\"Install\": [
\"aspnetcore-localhost-https.crt\"
]
}
}
}" > policies.json
dotnet dev-certs https -ep localhost.crt --format PEM
sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt
rm localhost.crt
Ufaj aplikacji 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 Podsystem 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 do 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$
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 (niepowodzenie: dotnet dev-certs https --clean)
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 programy 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ć
localhostcertyfikat o przyjaznejASP.NET Core HTTPS development certificatenazwie zarówno w obszarze, jakCurrent User > Personal > CertificatesiCurrent 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. Zaufanie certyfikatu jest buforowane przez przeglądarki.
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. Zaufanie certyfikatu jest buforowane przez przeglądarki.
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.
Dodatkowe informacje
Uwaga
Jeśli używasz zestawu .NET 9 SDK lub nowszego, zobacz zaktualizowane procedury systemu Linux w wersji .NET 9 tego artykułu.
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 UseHttpsRedirection , kończą się niepowodzeniem w ERR_INVALID_REDIRECT żądaniu wstępnym CORS.
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_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_portUstaw 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 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.jsondla usług IIS Express, jak Kestrel i IIS Express.launchsettings.jsonjest 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 artykule.
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. 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-ageparametr nagłówkaStrict-Transport-Securityna 60 dni. Jeśli nie zostanie ustawiona, wartość domyślna to 30 dni. Aby uzyskać więcej informacji, zobacz dyrektywę max-age. - Dodaje
example.comdo 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:
Usuń zaznaczenie pola wyboru Konfiguruj dla protokołu 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ć dotnet dev-certs narzędzie:
dotnet dev-certs https --trust
Następujące polecenie zapewnia pomoc w 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.
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 artykule.
Dodaj następujący kod JSON 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:
- Wprowadź
about:configwartość w przeglądarce FireFox. - Wybierz pozycję Zaakceptuj ryzyko i kontynuuj , jeśli zaakceptujesz ryzyko.
- Wybierz pozycję Pokaż wszystko
- Zbiór
security.enterprise_roots.enabled=true - 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.
Zainstaluj program OpenSSL 1.1.1h lub nowszy. Zapoznaj się z dystrybucją, aby uzyskać instrukcje dotyczące aktualizowania biblioteki OpenSSL.
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-certificatesfolderu przy użyciu środowiska bieżącego użytkownika. -EUsunię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łównysudoi-Enie 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:
libnss3-toolsZainstaluj element dla dystrybucji.Utwórz lub sprawdź,
$HOME/.pki/nssdbczy 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.crtZamknij 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 .
Utwórz plik JSON pod
/usr/lib/firefox/distribution/policies.jsonadresem 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 artykule, aby uzyskać alternatywny sposób konfigurowania pliku zasad przy użyciu przeglądarki.
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$ --trustGdzie
$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ć
localhostcertyfikat o przyjaznejASP.NET Core HTTPS development certificatenazwie zarówno w obszarze, jakCurrent User > Personal > CertificatesiCurrent 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 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
Uwaga
Jeśli używasz zestawu .NET 9 SDK lub nowszego, zobacz zaktualizowane procedury systemu Linux w wersji .NET 9 tego artykułu.
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 UseHttpsRedirection , kończą się niepowodzeniem w ERR_INVALID_REDIRECT żądaniu wstępnym CORS.
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_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_portUstaw 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 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.jsondla usług IIS Express, jak Kestrel i IIS Express.launchsettings.jsonjest 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 artykule.
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. 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-ageparametr nagłówkaStrict-Transport-Securityna 60 dni. Jeśli nie zostanie ustawiona, wartość domyślna to 30 dni. Aby uzyskać więcej informacji, zobacz dyrektywę max-age. - Dodaje
example.comdo 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:
Usuń zaznaczenie pola wyboru Konfiguruj dla protokołu 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ć dotnet dev-certs narzędzie:
dotnet dev-certs https --trust
Następujące polecenie zapewnia pomoc w 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.
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 artykule.
Dodaj następujący kod JSON 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:
- Wprowadź
about:configwartość w przeglądarce FireFox. - Wybierz pozycję Zaakceptuj ryzyko i kontynuuj , jeśli zaakceptujesz ryzyko.
- Wybierz pozycję Pokaż wszystko
- Zbiór
security.enterprise_roots.enabled=true - 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.
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 obsługiwane 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.
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.
Zainstaluj program OpenSSL 1.1.1h lub nowszy. Zapoznaj się z dystrybucją, aby uzyskać instrukcje dotyczące aktualizowania biblioteki OpenSSL.
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-certificatesfolderu przy użyciu środowiska bieżącego użytkownika. -EUsunię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łównysudoi-Enie 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:
libnss3-toolsZainstaluj element dla dystrybucji.Utwórz lub sprawdź,
$HOME/.pki/nssdbczy 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.crtZamknij 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 .
Utwórz plik JSON pod
/usr/lib/firefox/distribution/policies.jsonadresem 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 artykule, aby uzyskać alternatywny sposób konfigurowania pliku zasad przy użyciu przeglądarki.
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$ --trustGdzie
$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ć
localhostcertyfikat o przyjaznejASP.NET Core HTTPS development certificatenazwie zarówno w obszarze, jakCurrent User > Personal > CertificatesiCurrent 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 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
