Vynucení HTTPS v ASP.NET Core

David Galvan a Rick Anderson

Pokud chcete vynutit příchozí požadavky na vaše ASP.NET Core aplikace, aby používaly protokol HTTPS/TLS, můžete:

• Vyžadujte HTTPS pro všechny požadavky.
• Přesměruje všechny požadavky HTTP na HTTPS.

Žádné rozhraní API nemůže klientovi zabránit v odesílání citlivých dat při prvním požadavku.

Tento článek popisuje, jak nakonfigurovat aplikace ASP.NET Core tak, aby vyžadovaly https/TLS nebo přesměrovávají požadavky HTTP na HTTPS/TLS pro zabezpečenou interakci. Pro různé platformy jsou k dispozici kroky pro řešení problémů s nedůvěryhodnými certifikáty.

Projekty rozhraní API

Projekty, které používají webová rozhraní API, by měly:

• Neposlouchejte na protokolu HTTP.
• Ukončete připojení se stavovým kódem 400 (Chybný požadavek) a žádost neobsluhujte.

Pokud chcete v rozhraní API zakázat přesměrování protokolu HTTP, nastavte ASPNETCORE_URLS proměnnou prostředí nebo použijte příkazovou volbu --urls. Další informace najdete v tématu prostředí runtime ASP.NET Core a 8 způsobů, jak nastavit adresy URL pro aplikaci ASP.NET Core od Andrewa Locka.

Warning

Nepoužívejte RequireHttpsAttribute na webových rozhraních API, která přijímají citlivé informace. RequireHttpsAttribute používá stavové kódy HTTP k přesměrování prohlížečů z HTTP na HTTPS. Klienti rozhraní API nemusí rozumět přesměrování z HTTP na HTTPS nebo je poslouchat a můžou odesílat informace přes protokol HTTP.

Projekty HSTS a API

Zabezpečeným přístupem pro protokol HSTS (Http Strict Transport Security Protocol) je nakonfigurovat projekty rozhraní API tak, aby naslouchaly a reagovaly pouze přes PROTOKOL HTTPS.

Warning

Výchozí projekty rozhraní API nezahrnují HSTS , protože se obvykle jedná pouze o instrukce prohlížeče. Ostatní volající, například telefon nebo desktopové aplikace, nedodržují instrukce. I v rámci prohlížečů má jedno ověřené volání rozhraní API přes HTTP rizika v nezabezpečených sítích.

Přesměrování HTTP na HTTPS (ERR_INVALID_REDIRECT předběžné žádosti CORS)

Když se požadavek na koncový bod pomocí protokolu HTTP přesměruje na HTTPS s UseHttpsRedirection metodou, přesměrování selže s chybou ERR_INVALID_REDIRECT v předběžném požadavku CORS.

Projekty rozhraní API můžou odmítnout požadavky HTTP místo toho, aby metodu UseHttpsRedirection používaly k přesměrování požadavků na HTTPS.

Vyžadovat HTTPS

Pro produkční ASP.NET Core webových aplikací se doporučuje následující přístup:

• Pokud chcete přesměrovat požadavky HTTP na HTTPS, použijte middleware přesměrování HTTPS (UseHttpsRedirection).

• Pokud chcete odesílat hlavičky HSTS klientům, použijte middleware HSTS prostřednictvím metody UseHsts .

Note

Aplikace nasazené v konfiguraci reverzního proxy serveru umožňují proxy serveru zpracovávat zabezpečení připojení (HTTPS). Pokud proxy server také zpracovává přesměrování HTTPS, není nutné používat middleware přesměrování HTTPS. Pokud proxy server zpracovává také zápis hlaviček HSTS (například nativní podpora HSTS v Internetové Informační Služby (IIS) 10.0 verze 1709 nebo novější), aplikace nevyžaduje middleware HSTS. Další informace najdete v tématu Odhlášení z HTTPS/HSTS při vytváření projektu.

UseHttpsRedirection

Následující kód volá metodu UseHttpsRedirection v souboru Program.cs :

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Předchozí zvýrazněný kód:

• Používá výchozí HttpsRedirectionOptions.RedirectStatusCode vlastnost s kódem Status307TemporaryRedirect .
• Používá výchozí HttpsRedirectionOptions.HttpsPort vlastnost (předávání null), pokud není přepsána proměnnou ASPNETCORE_HTTPS_PORT prostředí nebo IServerAddressesFeature.

Doporučeným přístupem je místo trvalých přesměrování používat dočasné přesměrování. Ukládání odkazů do mezipaměti může způsobit nestabilní chování ve vývojových prostředích. Pokud dáváte přednost odeslání stavového kódu trvalého přesměrování, když je aplikace v prostředí mimoDevelopment prostředí, přečtěte si část Konfigurace trvalých přesměrování v produkčním prostředí. Pomocí HSTS signalizovat klientům, že se do aplikace mají odesílat jenom zabezpečené požadavky na prostředky (jenom v produkčním prostředí).

Konfigurace portu

Aby middleware přesměrovává nezabezpečený požadavek na HTTPS, musí být k dispozici port. Pokud není k dispozici žádný port:

• Přesměrování na HTTPS neproběhne.
• Middleware zaznamená upozornění , že se nepodařilo určit port https pro přesměrování.

Port HTTPS určete pomocí některého z následujících přístupů:

• Nastavte HttpsRedirectionOptions.HttpsPort.

• https_port Nastavení hostitele:

  • V konfiguraci hostitele.

  • Nastavením proměnné prostředí ASPNETCORE_HTTPS_PORT.

  • Přidáním položky nejvyšší úrovně do souboru appsettings.json :

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

• Označte port se zabezpečeným schématem pomocí proměnné prostředí ASPNETCORE_URLS. Proměnná prostředí konfiguruje server. Middleware nepřímo zjistí port HTTPS prostřednictvím IServerAddressesFeature. Tento přístup nefunguje v nasazeních reverzního proxy serveru.

• Webové šablony ASP.NET Core nastavily adresu URL HTTPS v souboru Properties/launchsettings.json pro Kestrel i službu IIS Express. Soubor launchsettings.json se používá pouze na místním počítači.

• Nakonfigurujte koncový bod URL adresy HTTPS pro veřejné nasazení na okraj serveru nebo serveru HTTP.sys. Aplikace používá jenom jeden port HTTPS. Middleware zjistí port přes IServerAddressesFeature.

Note

Pokud aplikace běží v konfiguraci reverzního proxy serveru, IServerAddressesFeature není dostupná. Nastavte port pomocí jednoho z dalších přístupů popsaných v této části.

Nasazení Edge

Pokud Kestrel nebo HTTP.sys slouží jako veřejný hraniční server, musí být Kestrel HTTP.sys nakonfigurované tak, aby naslouchalo na obou rozhraních:

• Zabezpečený port, ve kterém je klient přesměrován (obvykle 443 v produkčním prostředí a 5001 ve vývoji).
• Nezabezpečený port (obvykle 80 v produkčním prostředí a 5000 ve vývoji).

Nezabezpečený port musí být přístupný klientem, aby aplikace obdržela nezabezpečený požadavek a přesměrovává klienta na zabezpečený port.

Další informace najdete v tématu Kestrel Konfigurace koncového bodu nebo implementace webového serveru HTTP.sys v ASP.NET Core.

Scénáře nasazení

Každá brána firewall mezi klientem a serverem musí mít také otevřené komunikační porty pro přenos dat.

Pokud se požadavky předávají v konfiguraci reverzního proxy serveru, použijte Forwarded Headers Middleware před voláním middleware pro přesměrování HTTPS. Middleware forwarded Headers aktualizuje Request.Scheme pomocí hlavičky X-Forwarded-Proto . Middleware umožňuje, aby URI přesměrování a další bezpečnostní zásady správně fungovaly. Pokud se nepoužívá middleware forwarded headers, back-endová aplikace nemusí obdržet správné schéma a zachytit smyčku přesměrování. Běžnou chybovou zprávou koncového uživatele je příliš mnoho přesměrování.

Při nasazování do Azure App Service postupujte podle pokynů v Enable HTTPS pro vlastní doménu v Azure App Service.

Možnosti

Následující zvýrazněný kód volá metodu AddHttpsRedirection pro konfiguraci možností middlewaru:

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

Volání AddHttpsRedirection je nezbytné pouze ke změně hodnot HttpsPort nebo RedirectStatusCode.

Předchozí zvýrazněný kód:

• HttpsRedirectionOptions.RedirectStatusCode Nastaví vlastnost na Status307TemporaryRedirect kód, což je výchozí hodnota. Použijte pole třídy StatusCodes pro přiřazení k RedirectStatusCode.
• Nastaví port HTTPS na 5001.

Konfigurace trvalých přesměrování v produkčním prostředí

Middleware ve výchozím nastavení odesílá Status307TemporaryRedirect kód se všemi přesměrováními. Pokud dáváte přednost odeslání trvalého stavového kódu přesměrování, když aplikace není v Development prostředí, zabalte konfiguraci možností middlewaru do podmíněné kontroly pro jiné Development prostředí.

Následující kód ukazuje konfiguraci služeb v souboru 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();

Alternativa middlewaru pro přesměrování HTTPS

Alternativou k použití middlewaru UseHttpsRedirection přesměrování HTTPS (s metodou) je použití middlewaru AddRedirectToHttps pro přepis adres URL (prostřednictvím metody). AddRedirectToHttps může také nastavit stavový kód a port při spuštění přesměrování. Další informace naleznete v Middlewar pro přepisování adres URL.

Pokud aplikace přesměruje na HTTPS bez požadavku na jiná pravidla přesměrování, doporučujeme použít middleware () HTTPS Redirection Middleware (UseHttpsRedirection), jak je popsáno v tomto článku.

HTTP Strict Transport Security Protocol (HSTS)

Pro OWASP je HSTS vylepšení zabezpečení výslovného souhlasu určené webovou aplikací prostřednictvím hlavičky odpovědi. Když prohlížeč, který podporuje HSTS, obdrží tuto hlavičku:

• Prohlížeč ukládá konfiguraci domény, která brání odesílání jakékoli komunikace přes protokol HTTP. Prohlížeč přinutí veškerou komunikaci přes HTTPS.
• Prohlížeč zabrání uživateli v používání nedůvěryhodných nebo neplatných certifikátů. Prohlížeč zakáže výzvy, které uživateli umožní dočasně důvěřovat takovému certifikátu.

Vzhledem k tomu, že klient vynucuje HSTS, existují určitá omezení:

• Klient musí podporovat HSTS.
• HSTS vyžaduje alespoň jedno úspěšné splnění požadavku HTTPS k nastavení zásady HSTS.
• Aplikace musí zkontrolovat každý požadavek HTTP a přesměrovat nebo odmítnout požadavek HTTP.

ASP.NET Core implementuje HSTS pomocí rozšiřující metody UseHsts. Následující kód volá UseHsts , když aplikace není ve vývojovém režimu:

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 nedoporučujeme při vývoji, protože nastavení HSTS mohou být prohlížeči snadno uložena v mezipaměti. Ve výchozím nastavení UseHsts vylučuje lokální adresu zpětné smyčky.

Pro produkční prostředí, která implementují HTTPS poprvé, nastavte počáteční HstsOptions.MaxAge hodnotu vlastnosti na malou velikost pomocí jedné z TimeSpan metod. Nastavte hodnotu od hodin na maximálně jeden den, pokud potřebujete vrátit infrastrukturu HTTPS na HTTP. Jakmile budete mít jistotu o udržitelnosti konfigurace HTTPS, zvyšte hodnotu HSTS max-age (obvykle jeden rok).

Následující zvýrazněný kód:

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

• Nastaví parametr předběžného načtení hlavičky Strict-Transport-Security . Předběžné načtení není součástí specifikace RFC 6797 HSTS. Webové prohlížeče podporují předběžné načtení webů HSTS při nové instalaci. Další informace najdete na webu https://hstspreload.org/.
• Povolí direktivu includeSubDomain , která aplikuje zásadu HSTS na subdomény hostitelů. Další informace naleznete v dokumentu RFC 6797 HSTS specifikace (oddíl 6.1.2).
• Explicitně nastaví max-age parametr hlavičky Strict-Transport-Security na 60 dnů. Pokud není nastavená, výchozí hodnota je 30 dnů. Další informace najdete max-age ve specifikaci RFC 6797 HSTS (oddíl 6.1.1).1).
• Přidá example.com do seznamu hostitelů, které chcete vyloučit.

UseHsts vylučuje následující hostitele zpětné smyčky:

• localhost: Adresa zpětné smyčky IPv4.
• 127.0.0.1: Adresa zpětné smyčky IPv4.
• [::1]: Adresa zpětné smyčky IPv6.

Odhlášení z HTTPS/HSTS při vytváření projektu

V některých scénářích back-endové služby, kdy se zabezpečení připojení zpracovává na veřejném okraji sítě, není potřeba konfigurovat zabezpečení připojení v každém uzlu. Webové aplikace vygenerované ze šablon v sadě Visual Studio nebo z nového příkazu dotnet umožňují přesměrování HTTPS a HSTS. U nasazení, která nevyžadují tyto scénáře, můžete při vytváření aplikace ze šablony vyjádřit výslovný nesouhlas s https/HSTS.

Odhlášení z HTTPS/HSTS:

Visual Studio

Při vytváření nové webové aplikace ASP.NET Core zrušte výběr možnosti Konfigurovat pro HTTPS:

.NET

Použijte možnost --no-https s příkazem dotnet new webapp , například:

dotnet new webapp --no-https

Důvěřovat vývojovému certifikátu ASP.NET Core HTTPS

Sada .NET SDK obsahuje vývojový certifikát HTTPS. Certifikát se nainstaluje jako součást prvního spuštění. Příkaz například dotnet --info vytvoří variantu následujícího výstupu:

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.

Instalace sady .NET SDK nainstaluje vývojový certifikát ASP.NET Core HTTPS do místního úložiště certifikátů uživatele. Certifikát je nainstalovaný, ale není důvěryhodný. Pokud chcete certifikátu důvěřovat, spusťte nástroj jednorázově dotnet dev-certs :

dotnet dev-certs https --trust

Následující příkaz poskytuje nápovědu k nástroji dotnet dev-certs :

dotnet dev-certs https --help

Warning

Nevytvávejte vývojový certifikát v prostředí plánovaném pro redistribuci, jako je image kontejneru nebo virtuální počítač. Tento scénář může vést k falšování identity a zvýšení oprávnění. Pokud chcete této situaci zabránit, nastavte proměnnou prostředí DOTNET_GENERATE_ASPNET_CERTIFICATE na false před prvním voláním rozhraní příkazového řádku .NET. Tento přístup přeskočí automatické generování ASP.NET Core vývojového certifikátu během prvního spuštění rozhraní příkazového řádku.

Nastavení vývojářského certifikátu pro Docker

Pokud chcete nakonfigurovat certifikát vývojáře pro Docker, přečtěte si téma GitHub problém s dotnet/aspnetcore.docs #6199 - Pokud nastavení vývojového certifikátu při použití Dockeru ve vývoji.

Aspekty specifické pro Linux

Distribuce Linuxu se podstatně liší v tom, jak označují certifikáty jako důvěryhodné.

Očekává dotnet dev-certs se, že nástroj bude široce použitelný, ale oficiální podpora je k dispozici pouze pro Ubuntu a Fedora. Cílem podpory je zajistit důvěru v prohlížeče Firefox a Chromium (Microsoft Edge, Chrome a Chromium).

Dependencies

• Pokud chcete vytvořit důvěryhodnost OpenSSL, openssl nástroj musí být v cestě.
• Pokud chcete vytvořit vztah důvěryhodnosti prohlížeče (například v Microsoft Edge nebo Firefoxu), musí být nástroj certutil na cestě.

Důvěryhodnost OpenSSL

Pokud je certifikát pro vývoj ASP.NET Core důvěryhodný, exportuje se certifikát do složky v domovském adresáři aktuálního uživatele. Pokud chcete, aby openSSL (a klienti, kteří ji využívají), získali tuto složku, musíte nastavit proměnnou SSL_CERT_DIR prostředí. Proměnnou v jedné relaci můžete nastavit spuštěním příkazu, jako export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs je (přesná hodnota je ve výstupu, když --verbose se předá) nebo přidáním konfiguračního souboru (specifického pro distribuci a prostředí) (například .profile).

Tento přístup je nutný k tomu, aby nástroje, jako je curl důvěryhodnost vývojového certifikátu, důvěřovaly. Alternativně můžete předat -CAfile nebo -CApath do každého jednotlivého curl vyvolání.

Note

V závislosti na používané hlavní verzi vyžaduje verzi 1.1.1h nebo novější nebo 3.0.0 nebo novější.

Pokud se vztah důvěryhodnosti OpenSSL dostane do špatného stavu (například pokud dotnet dev-certs https --clean se mu nepodaří odebrat), můžete situaci často vyřešit pomocí nástroje c_rehash .

Overrides

Pokud používáte jiný prohlížeč s vlastním úložištěm Služby zabezpečení sítě (NSS), můžete pomocí DOTNET_DEV_CERTS_NSSDB_PATHS proměnné prostředí určit seznam adresářů NSS oddělených dvojtečky (například adresář obsahující cert9.db). Umístění vývojového certifikátu pak můžete přidat do seznamu v proměnné.

Pokud uložíte certifikáty, kterým má OpenSSL důvěřovat v určitém adresáři, můžete použít DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY proměnnou prostředí k označení umístění certifikátu.

Warning

Pokud nastavíte některou z proměnných, nezapomeňte při každé aktualizaci vztahu důvěryhodnosti nastavit stejné hodnoty. Pokud se hodnoty změní, nástroj neví o certifikátech v bývalých umístěních (například během čištění certifikátu).

Použití sudo

Stejně jako na jiných platformách se vývojové certifikáty ukládají a jsou samostatně důvěryhodné pro každého uživatele.

Pokud běžíte dotnet dev-certs jako jiný uživatel (například pomocí sudo), pak tento konkrétní uživatel (například root) důvěřuje vývojovému certifikátu.

Důvěřovat certifikátu HTTPS v Linuxu pomocí linux-dev-certs

Linux-dev-certs je opensourcový globální nástroj .NET podporovaný komunitou, který poskytuje pohodlný způsob, jak vytvořit a důvěřovat vývojářskému certifikátu v Linuxu. Microsoft nástroj neudržuje ani nepodporuje.

Následující příkazy nainstalují nástroj a vytvoří důvěryhodný vývojářský certifikát:

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

Další informace nebo hlášení problémů najdete v úložišti GitHubu linux-dev-certs.

SUSE Linux Enterprise Server (SLES Linux)

Pokud vaše konfigurace zahrnuje SUSE Linux Enterprise Server, přečtěte si problém s GitHub dotnet/aspnetcore.docs #28292 - Trust HTTPS certificate on SLES.

Řešení potíží s certifikáty (certifikát není důvěryhodný)

Když je někdy ASP.NET Core vývojový certifikát HTTPS instalovaný a důvěryhodný, prohlížeč upozorní, že certifikát je nedůvěryhodný. Následující části obsahují nápovědu k řešení tohoto problému.

Certifikát pro vývoj ASP.NET Core HTTPS používá Kestrel.

Pokud chcete opravit certifikát SLUŽBY IIS Express, přečtěte si téma Problém s stack overflow #20036984 / odpověď #20048613 - Jak obnovím chybějící certifikát SSL služby IIS Express?

Všechny platformy – certifikát není důvěryhodný.

U všech platforem zkuste vyřešit problémy s nedůvěryhodným certifikátem pomocí následujícího postupu:

1. Spusťte následující příkazy:

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

2. Zavřete všechny otevřené instance prohlížeče a otevřete aplikaci v novém okně prohlížeče.

   Mezipaměť prohlížeče ukládá, jestli je certifikát důvěryhodný. Proces zavření/otevření pomáhá aktualizovat nastavení mezipaměti prohlížeče pro certifikáty.

Příkazy dotnet dev-certs https obvykle řeší většinu problémů s důvěryhodností prohlížeče. Pokud příkaz dotnet dev-certs https --clean selže a prohlížeč stále certifikátu nedůvěřuje, vyzkoušejte návrhy specifické pro platformu v následujících částech.

Docker – certifikát není důvěryhodný

Pokud používáte Docker, zkuste problém vyřešit pomocí následujících kroků:

1. Odstraňte složku C:\Users{USER}\AppData\Roaming\ASP.NET\Https.

2. Vyčistěte řešení. Odstraňte složky bin a obj.

3. Restartujte nástroj pro vývoj. Například Visual Studio nebo Visual Studio Code.

Windows – certifikát není důvěryhodný

Pokud pracujete v Windows, proveďte následující kroky pro řešení potíží:

1. Zkontrolujte certifikáty v úložišti certifikátů. Vyhledejte certifikát localhost s popisným názvem ASP.NET Core HTTPS development certificate ve dvou složkách:

   • Osobní certifikáty aktuálního > uživatele >
   • Certifikáty důvěryhodných kořenových certifikačních autorit > aktuálního uživatele >

2. Odeberte všechny certifikáty z osobních i důvěryhodných kořenových certifikačních autorit.

   Important

   Neodstraňujte certifikát místního hostitele služby IIS Express.

3. Spusťte následující příkazy:

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

4. Zavřete všechny otevřené instance prohlížeče a otevřete aplikaci v novém okně prohlížeče.

OS X – certifikát není důvěryhodný

Pokud pracujete s OS X, zkuste problém vyřešit pomocí následujícího postupu:

1. Otevřete KeyChain Access a pak vyberte systémový klíček.

2. Zkontrolujte přítomnost certifikátu localhost.

3. Potvrďte, že certifikát zobrazuje symbol plus (+) na ikoně, který označuje, že certifikát je důvěryhodný pro všechny uživatele.

4. Odeberte certifikát ze systémové klíčenky.

5. Spusťte následující příkazy:

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

6. Zavřete všechny otevřené instance prohlížeče a otevřete aplikaci v novém okně prohlížeče.

Další informace o řešení potíží s certifikáty s Visual Studio najdete v tématu GitHub problém s dotnet/aspnetcore #16892) - HTTPS chyba pomocí služby IIS Express.

Linux – certifikát není důvěryhodný

Pokud používáte Linux, při řešení potíží s nedůvěryhodným certifikátem postupujte takto:

1. Ověřte, že certifikát, který prošetřujete, je certifikát vývojáře HTTPS uživatele plánovaný pro použití serverem Kestrel .

2. Zkontrolujte výchozí certifikát vývojáře Kestrel HTTPS aktuálního uživatele v následujícím umístění:

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

   Soubor certifikátu vývojáře Kestrel HTTPS je kryptografický otisk SHA1. Při odstranění souboru pomocí dotnet dev-certs https --clean příkazu se soubor vygeneruje v případě potřeby pomocí jiného kryptografického otisku.

3. Spuštěním následujícího příkazu ověřte, že kryptografický otisk exportovaného certifikátu odpovídá:

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

   Pokud kryptografický otisk certifikátu neodpovídá, prozkoumejte následující podmínky:

   • Zkontrolujte, jestli je certifikát starý.

   • Zkontrolujte, jestli je certifikát exportovaným certifikátem vývojáře pro kořenového uživatele.

     • Pokud ano, exportujte certifikát.

4. Zkontrolujte kořenový uživatelský certifikát v následující složce:

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

Certifikát SSL služby IIS Express používaný se sadou Visual Studio

Pokud chcete vyřešit problémy s certifikátem IIS Express, v instalačním programu Visual Studio vyberte Repair. Další informace najdete v tématu GitHub problém s dotnet/aspnetcore #16892) - HTTPS chyba pomocí služby IIS Express.

Zásady skupiny brání důvěryhodnosti certifikátů podepsaných svým držitelem

V některých případech můžou zásady skupiny bránit důvěryhodnosti certifikátů podepsaných svým držitelem. Další informace najdete v tématu GitHub problém s dotnet/aspnetcore #21173 - Chyba důvěřovat vývojářskému certifikátu HTTPS.

Související obsah

• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení
• Hostování ASP.NET Core v Linuxu pomocí Nginx: Konfigurace HTTPS
• Nastavení SSL ve službě IIS 7 nebo novější
• Konfigurace koncových bodů pro Kestrel webový server
• Podpora prohlížeče OWASP HSTS