Vynutilit HTTPS v ASP.NET Core

  • Článek
  • 14 min ke čtení

Autor: Rick Anderson

V tomto dokumentu se dozvíte, jak:

  • Vyžadovat protokol HTTPS pro všechny požadavky.
  • Přesměrovat všechny požadavky HTTP na HTTPS.

Žádné rozhraní API nemůže klientovi zabránit v posílání citlivých dat na první požadavek.

Upozornění

Projekty API

Nepoužívejte RequireHttpsAttribute pro webová rozhraní API, která přijímají citlivé informace. RequireHttpsAttribute pomocí stavových kódů HTTP přesměruje prohlížeče z HTTP na HTTPS. Klienti rozhraní API nemusí pochopit nebo dodržovat přesměrování z HTTP na HTTPS. Tito klienti mohou odesílat informace prostřednictvím protokolu HTTP. Webové rozhraní API by mělo mít jednu z těchto:

  • Neslouchat na HTTP.
  • Ukončete připojení se stavovým kódem 400 (chybný požadavek) a neobsluhuje požadavek.

Chcete-li zakázat přesměrování protokolu HTTP v rozhraní API, nastavte ASPNETCORE_URLS proměnnou prostředí nebo použijte --urls příznak příkazového řádku. další informace najdete v tématech Používání více prostředí v ASP.NET Core a 5 způsobů nastavení adres url pro aplikaci ASP.NET Core pomocí Andrew Lock.

Projekty HSTS a API

Výchozí projekty API neobsahují HSTS , protože HSTS je všeobecně pouze instrukcí prohlížeče. Další volající, jako jsou telefony nebo desktopové aplikace, nedodržují pokyny. I v prohlížečích má jedno ověřované volání rozhraní API přes protokol HTTP rizika v nezabezpečených sítích. Bezpečným přístupem je nakonfigurovat projekty API tak, aby naslouchaly jenom a reagovaly přes HTTPS.

Vyžadovat protokol HTTPS

doporučujeme, aby provozní ASP.NET Core web apps používaly:

  • Protokol HTTPS přesměrování middleware ( UseHttpsRedirection ) pro přesměrování požadavků HTTP na https.
  • HSTS middleware (UseHsts) k odeslání hlaviček HSTS (http Strict Transport Security Protocol) do klientů.

Poznámka

Aplikace nasazené v konfiguraci reverzního proxy serveru umožňují proxy zpracovávat zabezpečení připojení (HTTPS). Pokud proxy také zpracovává přesměrování protokolu HTTPS, není nutné používat middleware pro přesměrování protokolu HTTPS. Pokud proxy server také zpracovává zápis hlaviček HSTS (například nativní podporu HSTS ve službě IIS 10,0 (1709) nebo novější), aplikace HSTS middleware není aplikací požadována. Další informace najdete v tématu výslovný nedostatek protokolu HTTPS/HSTS při vytváření projektu.

UseHttpsRedirection

Následující kód volá 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:

Doporučujeme místo trvalých přesměrování použít 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 upřednostňujete odeslání trvalého stavového kódu přesměrování, když je aplikace v nevývojovém prostředí, přečtěte si část Konfigurace trvalých přesměrování v produkčním prostředí. Doporučujeme používat HSTS k signalizaci klientům, aby se do aplikace poslaly jenom zabezpečené požadavky na prostředky (jenom v produkčním prostředí).

Konfigurace portů

Pro middleware musí být k dispozici port pro přesměrování nezabezpečené žádosti na HTTPS. Pokud není k dispozici žádný port:

  • Přesměrování na HTTPS neproběhne.
  • Middleware zaznamená upozornění. "Nepodařilo se 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.

  • Nastavte https_port Nastavení hostitele:

    • V konfiguraci hostitele.

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

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

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

  • Označení portu pomocí zabezpečeného schématu pomocí proměnné prostředí ASPNETCORE_URLS. Proměnná prostředí nakonfiguruje server. Middleware nepřímo vyhledá port HTTPS prostřednictvím IServerAddressesFeature . Tento přístup nefunguje v nasazeních reverzních proxy serverů.

  • webové šablony ASP.NET Core nastavily adresu URL HTTPS v Properties/launchsettings. json pro i Kestrel IIS Express. launchsettings. JSON se používá jenom na místním počítači.

  • Konfigurace koncového bodu adresy URL HTTPS pro nasazení Kestrel serveru nebo HTTP.sysho serveru s veřejným přístupem. Aplikace používá jenom jeden port HTTPS . Middleware zjistí port prostřednictvím IServerAddressesFeature .

Poznámka

Když je aplikace spuštěná v konfiguraci reverzního proxy serveru, IServerAddressesFeature není k dispozici. Port nastavte pomocí některého z dalších přístupů popsaných v této části.

Nasazení Edge

Když Kestrel nebo HTTP.sys slouží jako veřejný hraniční server, Kestrel nebo HTTP.sys nutné nakonfigurovat tak, aby naslouchal na obou těchto počítačích:

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

Aby aplikace přijímala nezabezpečený požadavek a přesměrovala klienta na zabezpečený port, musí být nezabezpečený port přístupný klientovi.

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

Scénáře nasazení

Všechny brány firewall mezi klientem a serverem musí mít také otevřené komunikační porty pro provoz.

Pokud se požadavky předávají v konfiguraci reverzního proxy serveru, před voláním middleware pro přesměrování protokolu HTTPS použijte middleware pro předané hlavičky . Middleware s předanými hlavičkami aktualizuje Request.Scheme , pomocí X-Forwarded-Proto hlavičky. Middleware povoluje správné fungování identifikátorů URI přesměrování a dalších zásad zabezpečení. Když se nepoužije middleware předávaných hlaviček, back-end aplikace nemusí získat správné schéma a končit smyčkou přesměrování. Společná chybová zpráva koncového uživatele je, že došlo k příliš velkému počtu přesměrování.

Při nasazování do Azure App Service postupujte podle pokynů v kurzu: vytvoření vazby existujícího vlastního certifikátu SSL k Azure Web Apps.

Možnosti

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

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = (int)HttpStatusCode.TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

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

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

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

Middleware ve výchozím nastavení odesílá Status307TemporaryRedirect pomocí všech přesměrování. Pokud upřednostňujete odeslání trvalého stavového kódu přesměrování, pokud je aplikace v nevývojovém prostředí, zabalte konfiguraci možností middlewaru do podmíněné kontroly pro nevývojové prostředí.

Při konfiguraci služeb v programu program. cs:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int)HttpStatusCode.PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

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

    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Alternativní přístup middlewaru přesměrování HTTPS

Alternativou k použití middlewaru pro přesměrování protokolu HTTPS ( UseHttpsRedirection ) je použití přepisu adresy URL ( AddRedirectToHttps ). AddRedirectToHttps může také nastavit stavový kód a port při spuštění přesměrování. Další informace najdete v tématu middleware pro přepis adres URL.

Při přesměrování na HTTPS bez požadavku na další pravidla přesměrování doporučujeme použít middleware pro přesměrování protokolu HTTPS ( UseHttpsRedirection ) popsaný v tomto tématu.

Protokol HTTP Strict Transport Security (HSTS)

Za OWASPje zabezpečení protokolu HTTP (HSTS Strict Transport Security) na základě souhlasu s hlavičkou odpovědi zadané pomocí webové aplikace. Když prohlížeč, který podporuje HSTS, obdrží tuto hlavičku:

  • Prohlížeč ukládá konfiguraci pro doménu, která znemožňuje odeslání jakékoli komunikace prostřednictvím protokolu HTTP. Prohlížeč vynutí veškerou komunikaci přes protokol HTTPS.
  • Prohlížeč brání uživateli v používání nedůvěryhodných nebo neplatných certifikátů. Prohlížeč zakáže výzvy, které umožní uživateli dočasně důvěřovat takovému certifikátu.

Vzhledem k tomu, že klient vynutil HSTS , má některá omezení:

  • Klient musí podporovat HSTS.
  • HSTS vyžaduje alespoň jeden úspěšný požadavek HTTPS k vytvoření zásad 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í UseHsts metody rozšíření. Pokud aplikace není UseHsts ve vývojovém režimu, volá se následující kód:

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 se nedoporučuje při vývoji, protože nastavení HSTS jsou prohlížečem vysoce ukládaná do mezipaměti. Ve výchozím nastavení UseHsts vyloučí adresu místní zpětné smyčky.

Pro produkční prostředí, která poprvé implementuje HTTPS, nastavte pomocí jedné z metod počáteční HstsOptions.MaxAge na malou TimeSpan hodnotu. Pokud potřebujete vrátit infrastrukturu HTTPS na HTTP, nastavte hodnotu z hodin na méně než jeden den. Jakmile budete mít jistotu o udržitelnosti konfigurace HTTPS, zvyšte hodnotu HSTS. Běžně používaná hodnota max-age je jeden rok.

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

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = (int)HttpStatusCode.TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();
  • Nastaví parametr předběžného načtení Strict-Transport-Security hlavičky. Předběžné načtení není součástí specifikace RFC HSTS,ale webové prohlížeče ho podporují k předběžnému načtení webů HSTS při nové instalaci. Další informace najdete na webu https://hstspreload.org/.
  • Povolí includeSubDomain, která použije zásadu HSTS na subdomény Hostitele.
  • Explicitně nastaví max-age parametr Strict-Transport-Security hlavičky na 60 dní. Pokud není nastavené, výchozí hodnota je 30 dnů. Další informace najdete v direktivě max-age.
  • Přidá example.com do seznamu hostitelů, které se vyloučí.

UseHsts vyloučí 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, kde se zabezpečení připojení zpracovává na veřejném okraji sítě, není konfigurace zabezpečení připojení na jednotlivých uzlech nutná. Webové aplikace vygenerované ze šablon v Visual Studio nebo z nového příkazu dotnet povolují přesměrování HTTPS a HSTS. U nasazení, která nevyžadují tyto scénáře, můžete vyjádřit výslovný nesouhlas s HTTPS/HSTS při vytvoření aplikace ze šablony.

Odhlášení z HTTPS/HSTS:

Zrušte zaškrtnutí políčka Konfigurovat pro HTTPS.

Dialogové ASP.NET Core Nová webová aplikace zobrazující nezaškrtnuté políčko Konfigurovat pro HTTPS.

Důvěryhodnost certifikátu ASP.NET Core HTTPS v Windows a macOS

Informace o prohlížeči Firefox najdete v další části.

Součástí .NET Core SDK vývojový certifikát HTTPS. Certifikát se nainstaluje jako součást prvního spuštění. Například vytvoří dotnet --info variaci 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 .NET Core SDK nainstaluje certifikát ASP.NET Core HTTPS do místního úložiště certifikátů uživatele. Certifikát se nainstaloval, ale není důvěryhodný. Pokud chcete certifikátu důvěřovat, proveďte jeden krok pro spuštění nástroje dev-certs dotnet:

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

Upozornění

Nevytvářejte certifikát pro vývoj v prostředí, které se bude distribuovat, například image kontejneru nebo virtuální počítač. To může vést ke falšování a zvýšení oprávnění. Pokud tomu chcete zabránit, nastavte DOTNET_GENERATE_ASPNET_CERTIFICATE proměnnou prostředí na hodnotu před prvním voláním rozhraní příkazového řádku false .NET CLI. Tím se přeskočí automatické generování certifikátu ASP.NET Core během prvního spuštění rozhraní příkazového řádku.

Důvěřovat certifikátu HTTPS ve Firefoxu, aby se zabránilo SEC_ERROR_INADEQUATE_KEY_USAGE chyb

Prohlížeč Firefox používá vlastní úložiště certifikátů, a proto důvěřuje certifikátům IIS Express Kestrel nebo vývojářům.

Existují dva přístupy k důvěřování certifikátu HTTPS ve Firefoxu, vytvoření souboru zásad nebo konfiguraci v prohlížeči Fire Jejich. Konfigurace pomocí prohlížeče vytvoří soubor zásad, takže oba přístupy jsou ekvivalentní.

Vytvoření souboru zásad pro vztah důvěryhodnosti certifikátu HTTPS s prohlížečem Firefox

Vytvořte soubor zásad na adrese:

  • Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\policies.json
  • Macos: Firefox.app/Contents/Resources/distribution
  • Linux: Další informace najdete v tomto dokumentu v části Důvěřovat certifikátu pomocí Prohlížeče Firefox v Linuxu.

Do souboru zásad Firefoxu přidejte následující kód JSON:

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

Předchozí soubor zásad činí Firefox důvěryhodnými certifikáty z důvěryhodných certifikátů v Windows certifikátu. V další části je k dispozici alternativní přístup k vytvoření předchozího souboru zásad pomocí prohlížeče Firefox.

Konfigurace vztahu důvěryhodnosti certifikátu HTTPS pomocí prohlížeče Firefox

Nastavte security.enterprise_roots.enabled = true podle následujících pokynů:

  1. V about:config prohlížeči Fire Při zadejte .
  2. Pokud riziko přijmete, vyberte Přijmout riziko a Pokračovat.
  3. Vyberte Zobrazit vše.
  4. Set (Nastavit) security.enterprise_roots.enabled = true
  5. Ukončení a restartování prohlížeče Firefox

Další informace najdete v tématu Nastavení certifikačních autorit ve Firefoxu a v souboru mozilla/policy-templates/README.

Jak nastavit certifikát pro vývojáře pro Docker

Podívejte se na GitHub problému.

Důvěřovat certifikátu HTTPS v Linuxu

Navázání vztahu důvěryhodnosti je specifické pro distribuci a prohlížeč. Následující části obsahují pokyny pro některé oblíbené distribuce a Chromium prohlížeče (Edge a Chrome) a pro Firefox.

Ubuntu důvěřuje certifikátu pro komunikaci mezi službou

  1. Nainstalujte OpenSSL 1.1.1h nebo novější. Pokyny k aktualizaci OpenSSL najdete v distribuci.

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

    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

Předchozí příkazy:

  • Ujistěte se, že je vytvořený vývojářský certifikát aktuálního uživatele.
  • Exportuje certifikát se zvýšenými oprávněními potřebnými pro složku ca-certificates pomocí prostředí aktuálního uživatele.
  • Odebrání -E příznaku exportuje certifikát uživatele root a v případě potřeby ho vygeneruje. Každý nově vygenerovaný certifikát má jiný kryptografický otisk. Při spuštění jako kořenové sudo a -E nejsou potřeba.

Cesta v předchozím příkazu je specifická pro Ubuntu. U jiných distribucí vyberte vhodnou cestu nebo použijte cestu certifikačních autorit .

Důvěřovat certifikátu HTTPS v Linuxu pomocí Edge nebo Chromu

Prohlížeče chromium v Linuxu:

  • Nainstalujte libnss3-tools pro vaši distribuci .

  • Vytvořte nebo $HOME/.pki/nssdb ověřte, že složka na počítači existuje.

  • Exportujte certifikát pomocí následujícího příkazu:

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

    Cesta v předchozím příkazu je specifická pro Ubuntu. U jiných distribucí vyberte vhodnou cestu nebo použijte cestu certifikačních autorit .

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

    certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt

  • Ukončete a restartujte prohlížeč.

Důvěřovat certifikátu firefoxu v Linuxu

  • Exportujte certifikát pomocí následujícího příkazu:

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

    Cesta v předchozím příkazu je specifická pro Ubuntu. U jiných distribucí vyberte vhodnou cestu nebo použijte cestu certifikačních autorit .

  • Vytvořte soubor JSON na adrese /usr/lib/firefox/distribution/policies.json s následujícím obsahem:

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

Alternativní způsob konfigurace souboru zásad pomocí prohlížeče najdete v tomto dokumentu v části Konfigurace důvěryhodnosti certifikátu HTTPS pomocí prohlížeče Firefox.

Důvěřovat certifikátu s Fedora 34

Viz tento GitHub komentář .

Důvěřovat certifikátu s jinými distribucemi

Podívejte se na GitHub problém.

Důvěřovat certifikátu HTTPS z Subsystém Windows pro Linux

Nástroj Subsystém Windows pro Linux (WSL) vygeneruje certifikát HTTPS pro vývoj podepsaný svým držitelem. Konfigurace úložiště Windows certifikátů tak, aby důvěřuje certifikátu WSL:

  • Exportujte certifikát vývojáře do souboru v Windows:

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

    Kde $CREDENTIAL_PLACEHOLDER$ je heslo.

  • V okně WSL importujte exportovaný certifikát do instance WSL:

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

Předchozí přístup je jednou operací na certifikát a pro distribuci WSL. Je to jednodušší než vyexportování certifikátu znovu a znovu. Pokud aktualizujete nebo znovu vygenerujte certifikát ve Windows, možná budete muset znovu spustit předchozí příkazy.

Řešení potíží s certifikáty, například s certifikátem, který není důvěryhodný

Tato část obsahuje nápovědu v případě ASP.NET Core je nainstalovaný a důvěryhodný vývojový certifikát HTTPS, ale stále máte upozornění prohlížeče, že certifikát není důvěryhodný. Certifikát ASP.NET Core HTTPS používá Kestrel .

Informace o opravě IIS Express najdete v tomto problému s StackOverflow.

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

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

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

Zavřete všechny instance prohlížeče. Otevřete v aplikaci nové okno prohlížeče. Důvěryhodnost certifikátu se ukládá do mezipaměti prohlížečů.

dotnet dev-certs https --clean – Selhání

Předchozí příkazy řeší většinu problémů s důvěryhodností prohlížeče. Pokud prohlížeč stále certifikátu důvěřuje, postupujte podle návrhů specifických pro platformu, které následují.

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

  • Odstraňte složku C:\Users { USER}\AppData\Roaming\ASP.NET\Https.
  • Vyčistěte řešení. Odstraňte složky bin a obj.
  • Restartujte vývojový nástroj. Například Visual Studio, Visual Studio Code nebo Visual Studio pro Mac.

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

  • Zkontrolujte certifikáty v úložiště certifikátů. V části i by měl být certifikát localhost ASP.NET Core HTTPS development certificate s popisný Current User > Personal > Certificates název. Current User > Trusted root certification authorities > Certificates
  • Odeberte všechny nalezené certifikáty z osobních i důvěryhodných kořenových certifikačních autorit. Neodeberete certifikát IIS Express localhost.
  • Spusťte následující příkazy:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Zavřete všechny instance prohlížeče. Otevřete v aplikaci nové okno prohlížeče.

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

  • Otevřete KeyChain Access.
  • Vyberte systémový klíč.
  • Zkontrolujte přítomnost certifikátu místního hostitele.
  • Zkontrolujte, že ikona obsahuje symbol, který označuje, že je + pro všechny uživatele důvěryhodný.
  • Odeberte certifikát ze systémového klíčen.
  • Spusťte následující příkazy:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Zavřete všechny instance prohlížeče. Otevřete v aplikaci nové okno prohlížeče.

Informace o řešení potíží s certifikáty IIS Express najdete v tématu Chyba HTTPS při IIS Express (dotnet/AspNetCore #16892) Visual Studio.

Certifikát pro Linux není důvěryhodný

Zkontrolujte, že certifikát konfigurovaný pro vztah důvěryhodnosti je vývojářský certifikát HTTPS uživatele, který bude používán Kestrel serverem.

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

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

Soubor certifikátu vývojáře HTTPS Kestrel je kryptografický otisk SHA1. Když se soubor odstraní přes , v případě potřeby se znovu vygeneruje dotnet dev-certs https --clean s jiným kryptografický otiskem. Pomocí následujícího příkazu zkontrolujte shodu kryptografického otisku exportovaného certifikátu:

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

Pokud se certifikát neshoduje, může to být jedna z následujících možností:

  • Starý certifikát.
  • Export certifikátu vývojáře pro kořenového uživatele. V takovém případě exportujte certifikát.

Kořenový uživatelský certifikát je možné zkontrolovat na adrese:

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

IIS Express Certifikát SSL používaný s Visual Studio

Pokud chcete opravit problémy s certifikátem IIS Express, vyberte v instalačním programu Visual Studio opravit. Další informace najdete v tomto GitHub .

Další informace

Upozornění

Projekty rozhraní API

Nepoužívejte RequireHttpsAttribute u webových rozhraní 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 ho obeyt. Tito klienti mohou odesílat informace přes protokol HTTP. Webová rozhraní API by měla:

  • Nenaslouchá na HTTP.
  • Ukončete připojení se stavový kódem 400 (Chybný požadavek) a požadavek nesídlí.

Pokud chcete zakázat přesměrování HTTP v rozhraní API, nastavte ASPNETCORE_URLS proměnnou prostředí nebo použijte příznak --urls příkazového řádku. Další informace najdete v tématu a 5 způsobech nastavení adres URL pro aplikaci Používání více prostředí v ASP.NET Core ASP.NET Core – Andrew Lock.

Projekty HSTS a API

Výchozí projekty rozhraní API nezahrnují HSTS, protože HSTS je obecně instrukce pouze pro prohlížeč. Ostatní volající, například aplikace pro telefon nebo stolní počítače, pokyny neřídí. I v prohlížečích je jedno ověřené volání rozhraní API přes HTTP ohroženo v nezabezpečených sítích. Zabezpečeným přístupem je konfigurace projektů rozhraní API tak, aby naslouchala pouze protokolu HTTPS a reagovala na ně.

Vyžadovat HTTPS

Doporučujeme, aby produkční ASP.NET Core webové aplikace:

  • Middleware pro přesměrování HTTPS ( UseHttpsRedirection ) pro přesměrování požadavků HTTP na HTTPS.
  • Middleware HSTS (UseHsts) k odesílání hlaviček HSTS (Http Strict Transport Security Protocol) klientům.

Poznámka

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

UseHttpsRedirection

Následující kód volá UseHttpsRedirection ve Startup třídě :

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

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

Místo trvalých přesměrování doporučujeme 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í trvalého stavového kódu přesměrování, když je aplikace v jiném než vývojovém prostředí, podívejte se do části Konfigurace trvalých přesměrování v produkčním prostředí. Doporučujeme použít HSTS k signálu klientům, že do aplikace (pouze v produkčním prostředí) by se měly odeslat pouze zabezpečené požadavky na prostředky.

Konfigurace portů

Pro middleware musí být k dispozici port pro přesměrování nezabezpečené žádosti na HTTPS. Pokud není k dispozici žádný port:

  • Přesměrování na HTTPS neproběhne.
  • Middleware zaznamená upozornění. "Nepodařilo se 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.

  • Nastavte https_port Nastavení hostitele:

    • V konfiguraci hostitele.

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

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

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

  • Označení portu pomocí zabezpečeného schématu pomocí proměnné prostředí ASPNETCORE_URLS. Proměnná prostředí nakonfiguruje server. Middleware nepřímo vyhledá port HTTPS prostřednictvím IServerAddressesFeature . Tento přístup nefunguje v nasazeních reverzních proxy serverů.

  • Ve vývojovém prostředí nastavte adresu URL HTTPS v souboru launchsettings. JSON. pokud se používá IIS Express, povolte HTTPS.

  • Konfigurace koncového bodu adresy URL HTTPS pro nasazení Kestrel serveru nebo HTTP.sysho serveru s veřejným přístupem. Aplikace používá jenom jeden port HTTPS . Middleware zjistí port prostřednictvím IServerAddressesFeature .

Poznámka

Když je aplikace spuštěná v konfiguraci reverzního proxy serveru, IServerAddressesFeature není k dispozici. Port nastavte pomocí některého z dalších přístupů popsaných v této části.

Nasazení Edge

Když Kestrel nebo HTTP.sys slouží jako veřejný hraniční Server, Kestrel nebo HTTP.sys nutné nakonfigurovat tak, aby naslouchal na obou těchto počítačích:

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

Aby aplikace přijímala nezabezpečený požadavek a přesměrovala klienta na zabezpečený port, musí být nezabezpečený port přístupný klientovi.

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

Scénáře nasazení

Všechny brány firewall mezi klientem a serverem musí mít také otevřené komunikační porty pro provoz.

Pokud se požadavky předávají v konfiguraci reverzního proxy serveru, před voláním middleware pro přesměrování protokolu HTTPS použijte middleware pro předané hlavičky . Middleware s předanými hlavičkami aktualizuje Request.Scheme , pomocí X-Forwarded-Proto hlavičky. Middleware povoluje správné fungování identifikátorů URI přesměrování a dalších zásad zabezpečení. Když se nepoužije middleware předávaných hlaviček, back-end aplikace nemusí získat správné schéma a končit smyčkou přesměrování. Společná chybová zpráva koncového uživatele je, že došlo k příliš velkému počtu přesměrování.

Při nasazování do Azure App Service postupujte podle pokynů v kurzu: vytvoření vazby existujícího vlastního certifikátu SSL k Azure Web Apps.

Možnosti

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

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

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

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

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

Middleware ve výchozím nastavení odesílá Status307TemporaryRedirect pomocí všech přesměrování. Pokud upřednostňujete odeslání trvalého stavového kódu přesměrování, pokud je aplikace v nevývojovém prostředí, zabalte konfiguraci možností middlewaru do podmíněné kontroly pro nevývojové prostředí.

Při konfiguraci služeb při spuštění. 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;
        });
    }
}

Alternativní přístup middlewaru přesměrování HTTPS

Alternativou k použití middlewaru pro přesměrování protokolu HTTPS ( UseHttpsRedirection ) je použití přepisu adresy URL ( AddRedirectToHttps ). AddRedirectToHttps může také nastavit stavový kód a port při spuštění přesměrování. Další informace najdete v tématu middleware pro přepis adres URL.

Při přesměrování na HTTPS bez požadavku na další pravidla přesměrování doporučujeme použít middleware pro přesměrování protokolu HTTPS ( UseHttpsRedirection ) popsaný v tomto tématu.

Protokol HTTP Strict Transport Security (HSTS)

Za OWASPje zabezpečení protokolu HTTP (HSTS Strict Transport Security) na základě souhlasu s hlavičkou odpovědi zadané pomocí webové aplikace. Když prohlížeč, který podporuje HSTS, obdrží tuto hlavičku:

  • Prohlížeč ukládá konfiguraci pro doménu, která znemožňuje odeslání jakékoli komunikace prostřednictvím protokolu HTTP. Prohlížeč vynutí veškerou komunikaci přes protokol HTTPS.
  • Prohlížeč brání uživateli v používání nedůvěryhodných nebo neplatných certifikátů. Prohlížeč zakáže výzvy, které umožní uživateli dočasně důvěřovat takovému certifikátu.

Vzhledem k tomu, že klient vynutil HSTS, má některá omezení:

  • Klient musí podporovat HSTS.
  • HSTS vyžaduje alespoň jednu úspěšnou žádost HTTPS k vytvoření zásady HSTS.
  • Aplikace musí kontrolovat všechny požadavky HTTP a přesměrovat nebo zamítnout požadavek HTTP.

ASP.NET Core implementuje HSTS s UseHsts metodou rozšíření. Následující kód volá, UseHsts když aplikace není v režimu pro vývoj:

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 nedoporučuje se při vývoji, protože nastavení HSTS jsou prohlížeči vysoce ukládat do mezipaměti. Ve výchozím nastavení UseHsts vyloučí místní adresu zpětné smyčky.

V produkčních prostředích, která implementují protokol HTTPS poprvé, nastavte počáteční HstsOptions. maxAge na malou hodnotu pomocí jedné z TimeSpan metod. Nastavte hodnotu z hodin na ne více než jeden den pro případ, že budete potřebovat obnovit infrastrukturu HTTPS na HTTP. Až budete mít jistotu, že dojde k udržitelnosti konfigurace HTTPS, zvyšte max-age hodnotu HSTS. běžně používaná hodnota je jeden rok.

Následující kód:

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;
    });
}
  • Nastaví parametr přednačtení Strict-Transport-Security hlavičky. Předběžné načtení není součástí specifikace RFC HSTS, ale podporuje je ve webových prohlížečích k přednačtení webů HSTS při nové instalaci. Další informace najdete na webu https://hstspreload.org/.
  • Povolí includeSubDomain, která aplikuje zásady HSTS na hostování subdomén.
  • Explicitně nastaví max-age parametr Strict-Transport-Security záhlaví na 60 dní. Pokud není nastavené, výchozí hodnota je 30 dní. Další informace najdete v direktivě max-age.
  • Přidá example.com do seznamu hostitelů, které mají být vyloučeny.

UseHsts vyloučí 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.

Výslovný nesouhlas s protokolem HTTPS/HSTS při vytváření projektu

V některých případech služby back-end, kde se zabezpečení připojení zpracovává na veřejném hraničním serveru sítě, se konfigurace zabezpečení připojení na jednotlivých uzlech nevyžaduje. webové aplikace, které jsou generovány ze šablon v Visual Studio nebo z příkazu dotnet new enable HTTPS direction a HSTS. Pro nasazení, která tyto scénáře nevyžadují, můžete při vytvoření aplikace ze šablony vyjádřit výslovný souhlas s HTTPS/HSTS.

Výslovný souhlas s protokolem HTTPS/HSTS:

Zrušte zaškrtnutí políčka Konfigurovat pro protokol HTTPS .

dialog nové webové aplikace ASP.NET Core zobrazující políčko konfigurovat pro protokol HTTPS není vybrané.

důvěra ASP.NET Core certifikát pro vývoj HTTPS v Windows a macOS

Informace o prohlížeči Firefox najdete v další části.

.NET Core SDK obsahuje certifikát pro vývoj HTTPS. Certifikát je nainstalován jako součást prvního spuštění prostředí. Například dotnet --info vytváří variaci 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 .NET Core SDK nainstaluje certifikát pro vývoj ASP.NET Core HTTPS do úložiště certifikátů místního uživatele. Certifikát je nainstalovaný, ale není důvěryhodný. Chcete-li důvěřovat certifikátu, proveďte v jednom časovém kroku spuštění nástroje dotnet dev-certs :

dotnet dev-certs https --trust

Následující příkaz nabízí informace o dev-certs nástroji:

dotnet dev-certs https --help

Upozornění

Nevytvářejte certifikát pro vývoj v prostředí, které se bude distribuovat, jako je například Image kontejneru nebo virtuální počítač. To může vést k falšování a zvýšení oprávnění. Chcete-li tomu zabránit, nastavte DOTNET_GENERATE_ASPNET_CERTIFICATE false před prvním voláním rozhraní .NET CLI proměnnou prostředí na. tato akce přeskočí automatické generování ASP.NET Coreho vývojového certifikátu během prvního spuštění rozhraní příkazového řádku.

Důvěřovat certifikátu HTTPS s Firefox, aby se zabránilo SEC_ERROR_INADEQUATE_KEY_USAGE chybě

prohlížeč Firefox používá vlastní úložiště certifikátů, proto nedůvěřuje certifikátům IIS Express ani Kestrel vývojářům.

Existují dva způsoby, jak důvěřovat certifikátu HTTPS s aplikací Firefox, vytvořit soubor zásad nebo nakonfigurovat pomocí prohlížeče FireFox. Konfigurace pomocí prohlížeče vytvoří soubor zásad, takže tyto dva přístupy jsou ekvivalentní.

Vytvoření souboru zásad pro důvěřování certifikátu HTTPS pomocí Firefox

Vytvořit soubor zásad v:

Do souboru zásad pro Firefox přidejte následující kód JSON:

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

předchozí soubor zásad zpřístupňuje prohlížeči Firefox certifikáty z důvěryhodných certifikátů v úložišti certifikátů Windows. V další části najdete alternativní postup vytvoření předchozího souboru zásad pomocí prohlížeče Firefox.

Konfigurace vztahu důvěryhodnosti certifikátu HTTPS pomocí prohlížeče Firefox

Nastavte security.enterprise_roots.enabled = true pomocí následujících pokynů:

  1. about:configDo prohlížeče Firefox zadejte.
  2. Vyberte přijmout riziko a pokračovat , pokud souhlasíte s rizikem.
  3. Vybrat Zobrazit vše
  4. Nastavit security.enterprise_roots.enabled = true
  5. Ukončení a restartování prohlížeče Firefox

Další informace najdete v tématu Nastavení certifikačních autorit (CAS) v prohlížeči Firefox a souboru Mozilla/Policy-TEMPLATEs/Readme.

Jak nastavit certifikát pro vývojáře pro Docker

podívejte se na tento GitHub problém.

Důvěřovat certifikátu HTTPS v systému Linux

Vytvoření vztahu důvěryhodnosti je specifické pro distribuci a prohlížeč. následující části obsahují pokyny pro některé oblíbené distribuce a Chromium prohlížeče (Edge a Chrome) a pro Firefox.

Ubuntu důvěřovat certifikátu pro komunikaci mezi službami a službami

  1. Nainstalujte OpenSSL 1.1.1 h nebo novější. Pokyny k aktualizaci OpenSSL najdete v tématu věnovaném distribuci.

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

    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

Předchozí příkazy:

  • Ujistěte se, že je vytvořený certifikát pro vývojáře aktuálního uživatele.
  • Exportuje certifikát se zvýšenými oprávněními, která jsou potřebná pro ca-certificates složku, pomocí prostředí aktuálního uživatele.
  • Odebráním -E příznaku se vygeneruje kořenový certifikát uživatele a v případě potřeby se vygeneruje. Každý nově vygenerovaný certifikát má jiný kryptografický otisk. Při spuštění jako kořenového adresáře sudo a nejsou -E potřeba.

Cesta v předchozím příkazu je specifická pro Ubuntu. Pro jiné distribuce vyberte vhodnou cestu nebo použijte cestu k certifikační autoritě (CA).

Důvěřovat certifikátu HTTPS na platformě Linux pomocí Edge nebo Chromu

Pro prohlížeče Chromu v systému Linux:

  • Nainstalujte libnss3-tools pro distribuci.

  • Vytvořte nebo ověřte, že $HOME/.pki/nssdb Složka na počítači existuje.

  • Exportujte certifikát pomocí následujícího příkazu:

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

    Cesta v předchozím příkazu je specifická pro Ubuntu. Pro jiné distribuce vyberte vhodnou cestu nebo použijte cestu k certifikační autoritě (CA).

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

    certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt

  • Ukončete a restartujte prohlížeč.

Důvěřovat certifikátu pomocí prohlížeče Firefox v systému Linux

  • Exportujte certifikát pomocí následujícího příkazu:

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

    Cesta v předchozím příkazu je specifická pro Ubuntu. Pro jiné distribuce vyberte vhodnou cestu nebo použijte cestu k certifikační autoritě (CA).

  • Vytvořte soubor JSON /usr/lib/firefox/distribution/policies.json s následujícím obsahem:

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

Alternativní způsob konfigurace souboru zásad pomocí prohlížeče najdete v tématu Konfigurace vztahu důvěryhodnosti certifikátu HTTPS pomocí prohlížeče Firefox v tomto dokumentu.

Důvěřovat certifikátu pomocí Fedora 34

podívejte se na tento GitHub komentář.

Důvěřovat certifikátu s ostatními distribuce

podívejte se na tento GitHub problém.

důvěřovat certifikátu HTTPS z Subsystém Windows pro Linux

Subsystém Windows pro Linux (WSL) generuje certifikát pro vývoj podepsaný svým držitelem (HTTPS). konfigurace úložiště certifikátů Windows pro důvěřování certifikátu WSL:

  • Exportujte certifikát vývojáře do souboru na Windows:

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

    Kde $CREDENTIAL_PLACEHOLDER$ je heslo.

  • V okně WSL importujte exportovaný certifikát do instance WSL:

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

Předchozí přístup je jednorázová operace na certifikát a distribuce podle WSL. Je jednodušší než exportování certifikátu přes a přes. Pokud aktualizujete nebo znovu vygenerujete certifikát ve Windows, možná budete muset znovu spustit předchozí příkazy.

Řešení potíží s certifikáty, jako je nedůvěryhodný certifikát

tato část obsahuje informace o tom, kdy byl certifikát pro vývoj ASP.NET Core HTTPS nainstalovaný a důvěryhodný, ale přesto máte upozornění prohlížeče, že certifikát není důvěryhodný. ASP.NET Core certifikát pro vývoj HTTPS používá Kestrel .

pokud chcete opravit IIS Express certifikát, přečtěte si tento problém Stackoverflow .

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

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

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

Zavřete všechny otevřené instance prohlížeče. Otevřete nové okno prohlížeče pro aplikaci. Důvěryhodnost certifikátu je ukládána v mezipaměti prohlížeči.

dotnet dev-certifikáty https--Clean

Předchozí příkazy vyřeší většinu problémů s důvěryhodností prohlížečů. Pokud prohlížeč pořád certifikát nedůvěřuje, postupujte podle následujících doporučení pro konkrétní platformu.

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

  • odstraňte složku C:\Users { USER} \AppData\Roaming\ ASP.NET \Https .
  • Vyčistěte řešení. Odstraňte složky bin a obj .
  • Restartujte nástroj pro vývoj. například Visual Studio, Visual Studio Code nebo Visual Studio pro Mac.

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

  • Ověřte certifikáty v úložišti certifikátů. localhostV části i by měl být certifikát s ASP.NET Core HTTPS development certificate popisným názvem Current User > Personal > Certificates .Current User > Trusted root certification authorities > Certificates
  • Odeberte všechny nalezené certifikáty z osobních i důvěryhodných kořenových certifikačních autorit. neodstraňujte certifikát IIS Express localhost.
  • Spusťte následující příkazy:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Zavřete všechny otevřené instance prohlížeče. Otevřete nové okno prohlížeče pro aplikaci.

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

  • Otevřete přístup k řetězci klíčů.
  • Vyberte systémový řetězec klíčů.
  • Zkontrolujte přítomnost certifikátu místního hostitele.
  • Zkontrolujte, že ikona obsahuje symbol, který označuje, že je + pro všechny uživatele důvěryhodný.
  • Odeberte certifikát ze systémového klíčen.
  • Spusťte následující příkazy:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Zavřete všechny instance prohlížeče. Otevřete v aplikaci nové okno prohlížeče.

Informace o řešení potíží s certifikáty IIS Express najdete v tématu Chyba HTTPS při IIS Express (dotnet/AspNetCore #16892) Visual Studio.

Certifikát pro Linux není důvěryhodný

Zkontrolujte, že certifikát konfigurovaný pro vztah důvěryhodnosti je vývojářský certifikát HTTPS uživatele, který bude Kestrel používán serverem.

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

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

Soubor certifikátu vývojáře HTTPS Kestrel je kryptografický otisk SHA1. Když se soubor odstraní přes , v případě potřeby se znovu vygeneruje dotnet dev-certs https --clean s jiným kryptografickým otiskem. Pomocí následujícího příkazu zkontrolujte shodu kryptografického otisku exportovaného certifikátu:

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

Pokud se certifikát neshoduje, může to být jedna z následujících možností:

  • Starý certifikát.
  • Export certifikátu vývojáře pro kořenového uživatele. V takovém případě exportujte certifikát.

Kořenový uživatelský certifikát je možné zkontrolovat na adrese:

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

IIS Express Certifikát SSL používaný s Visual Studio

Pokud chcete opravit problémy s certifikátem IIS Express, vyberte v instalačním programu Visual Studio opravit. Další informace najdete v tomto GitHub .

Další informace