HTTPS kényszerítése a ASP.NET Core-ban

David Galvan és Rick Anderson

A https/TLS használatára vonatkozó bejövő kérések ASP.NET Core-alkalmazásokhoz való kényszerítéséhez a következőt teheti:

• Minden kéréshez HTTPS-t kell igényelni.
• Az összes HTTP-kérés átirányítása HTTPS-be.

Egyetlen API sem akadályozhatja meg, hogy az ügyfél bizalmas adatokat küldjön az első kérelemre.

Ez a cikk azt ismerteti, hogyan konfigurálhatja a ASP.NET Core-alkalmazásokat, hogy HTTPS/TLS-t igényeljenek, vagy hogyan irányíthatók át HTTP-kérelmek a HTTPS/TLS-hez a biztonságos interakció érdekében. A különböző platformok hibaelhárítási lépései a nem megbízható tanúsítványokkal kapcsolatos problémák megoldásához szükségesek.

API-projektek

A webes API-kat használó projekteknek a következőkre kell törekednie:

• Nem figyel a HTTP-n.
• Zárja be a kapcsolatot a 400-ás állapotkóddal (hibás kérés), és ne szolgálja ki a kérést.

Ha le szeretné tiltani a HTTP-átirányítást egy API-ban, állítsa be a ASPNETCORE_URLS környezeti változót, vagy használja a parancssori --urls jelzőt. További információ: ASP.NET Core futtatókörnyezetek és 8 módszer az ASP.NET Core-alkalmazások URL-címeinek beállítására Andrew Lock által.

Warning

Ne használjon RequireHttpsAttribute olyan webes API-kat, amelyek bizalmas információkat kapnak. RequireHttpsAttribute HTTP-állapotkódokkal irányítja át a böngészőket a HTTP-ről a HTTPS-be. Előfordulhat, hogy az API-ügyfelek nem értik vagy nem tartják be a HTTP-ről HTTPS-re történő átirányításokat, és http-en keresztül is küldhetnek információkat.

HSTS- és API-projektek

A HTTP Strict Transport Security (HSTS) protokoll biztonságos megközelítése, hogy az API-projekteket úgy konfigurálja, hogy csak a HTTPS-n keresztül hallgassanak és válaszoljanak.

Warning

Az alapértelmezett API-projektek nem tartalmazzák a HSTS-t , mert általában csak böngészőbeli utasítások. Más hívók, például telefonos vagy asztali alkalmazások , nem tartják be az utasításokat. Még a böngészőkben is fennáll a veszélye annak, hogy egy API http-n keresztüli hitelesített hívása nem biztonságos hálózatokat veszélyeztet.

HTTP-átirányítás HTTPS-hez (ERR_INVALID_REDIRECT CORS-elővizsgálati kérelem esetén)

Ha egy HTTP-t használó végpontra irányuló kérést a UseHttpsRedirection metódussal HTTPS-re irányítanak át, az átirányítás a CORS elővizsgálati kérés során a(z) ERR_INVALID_REDIRECT hibával meghiúsul.

Az API-projektek elutasíthatják a HTTP-kéréseket ahelyett, hogy a metódust használva átirányítanák a UseHttpsRedirection kéréseket a HTTPS-be.

HTTPS megkövetelése

Éles ASP.NET Core webalkalmazások esetén a következő megközelítés ajánlott:

• A HTTP-kérések HTTPS-hez való átirányításához használja a HTTPS átirányítási köztes szoftverét (UseHttpsRedirection).

• Ha HSTS-fejléceket szeretne küldeni az ügyfeleknek, használja a HSTS köztes szoftvereket a UseHsts metóduson keresztül.

Note

A fordított proxykonfigurációban üzembe helyezett alkalmazások lehetővé teszik a proxy számára a kapcsolatbiztonság (HTTPS) kezelését. Ha a proxy a HTTPS-átirányítást is kezeli, nincs szükség HTTPS-átirányítási köztes szoftver használatára. Ha a proxykiszolgáló HSTS-fejlécek írását is kezeli (például natív HSTS-támogatás az Internet Information Services (IIS) 10.0 1709-es vagy újabb verziójában), akkor az alkalmazásnak nincs szüksége HSTS köztes szoftverre. További információ: HTTPS/HSTS letiltása a projektlétrehozáskor.

HTTPS átirányítási köztes szoftver (UseHttpsRedirection)

A következő kód meghívja a UseHttpsRedirection a Program.cs fájlban:

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

Az előző kiemelt kód:

• Az alapértelmezett HttpsRedirectionOptions.RedirectStatusCode tulajdonságot használja a Status307TemporaryRedirect kóddal.
• Az alapértelmezett HttpsRedirectionOptions.HttpsPort tulajdonságot használja (nullt ad át), hacsak a ASPNETCORE_HTTPS_PORT környezeti változó vagy a IServerAddressesFeature felül nem írja.

Az ajánlott módszer az ideiglenes átirányítások használata állandó átirányítások helyett. A linkek gyorsítótárazása instabil viselkedést okozhat a fejlesztési környezetekben. Ha inkább állandó átirányítási állapotkódot szeretne küldeni, amikor az alkalmazás nem Development környezetben van, tekintse meg az állandó átirányítások konfigurálása a gyártásban című szakaszt. A HSTS használatával jelezheti az ügyfeleknek, hogy csak biztonságos erőforrás-kérelmeket kell elküldeni az alkalmazásnak (csak éles környezetben).

Note

Ne keverje össze a konfigurációs kulcsot és a HTTPS_PORT környezeti változót, amely a HTTPS átirányítási köztes szoftver portját állítja be a konfigurációs kulccsal és ASPNETCORE_HTTPS_PORTS a HTTPS_PORTS környezeti változóval, amely beállítja a portokat a /HTTP.sys végpontkonfigurációhozKestrel.ASPNETCORE_HTTPS_PORT

Portkonfiguráció

A köztes szoftvernek elérhetőnek kell lennie egy portnak ahhoz, hogy egy nem biztonságos kérést átirányítson a HTTPS-be. Ha nincs elérhető port:

• A HTTPS-hez való átirányítás nem történik meg.
• A köztes szoftver naplózza a figyelmeztetést, amely nem tudta meghatározni a https-portot az átirányításhoz.

Adja meg a HTTPS-portot az alábbi módszerek bármelyikével:

• Állítsa be a HttpsRedirectionOptions.HttpsPort értékét.

• Állítsa be a https_portgazdagép beállításait:

  • Gazdagépkonfigurációban.

  • A ASPNETCORE_HTTPS_PORT környezeti változó beállításával.

  • Ha hozzáad egy legfelső szintű bejegyzést a appsettings.json fájlhoz:

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

• Jelöljön meg egy portot a biztonságos sémával a ASPNETCORE_URLS környezeti változó használatával. A környezeti változó konfigurálja a kiszolgálót. A köztes szoftver közvetetten felderíti a HTTPS-portot a IServerAddressesFeature. Ez a megközelítés nem működik fordított proxytelepítésekben.

• A ASP.NET Core websablonok https URL-címet állít be a Properties/launchsettings.json fájlban Kestrel és az IIS Express esetében is. A launchsettings.json fájl csak a helyi gépen használható.

• HTTPS URL-végpontot kell konfigurálni a Kestrel kiszolgáló vagy a HTTP.sys kiszolgáló nyilvános elérhetőségű peremhálózati üzembe helyezéséhez. Az alkalmazás csak egy HTTPS-portot használ. A köztes szoftver a portot észleli a következőn keresztül: IServerAddressesFeature.

Note

Ha egy alkalmazás fordított proxykonfigurációban fut, IServerAddressesFeature nem érhető el. Állítsa be a portot az ebben a szakaszban ismertetett egyéb megközelítések egyikével.

Peremtelepítések

Amikor Kestrel vagy HTTP.sys nyilvános elérésű edge szerverként van használva, akkor Kestrel vagy HTTP.sys úgy kell konfigurálni, hogy mindkettőt figyelje.

• A biztonságos port, amelyre az ügyfél át van irányítva (általában a 443-as port az éles környezetben, és az 5001-es a fejlesztési környezetben).
• A nem biztonságos port (általában 80 éles környezetben és 5000 fejlesztési környezetben).

A nem biztonságos portot az ügyfélnek el kell érnie ahhoz, hogy az alkalmazás nem biztonságos kérést kapjon, és átirányítsa az ügyfelet a biztonságos portra.

További információ: Kestrel végpontkonfiguráció vagy HTTP.sys webkiszolgáló implementálása a ASP.NET Core-ban.

Üzembe helyezési forgatókönyvek

Az ügyfél és a kiszolgáló közötti tűzfalnak nyitva kell lennie a forgalom számára nyitva lévő kommunikációs portokkal is.

Ha a kérések továbbítása fordított proxykonfigurációban történik, használja a továbbított fejlécek köztes szoftverét , mielőtt meghívja a HTTPS-átirányítási köztes szoftvereket. A továbbított fejlécek köztes szoftvere a Request.Scheme elemet a X-Forwarded-Proto fejléc használatával frissíti. A köztes szoftver lehetővé teszi az átirányítási URI-k és más biztonsági szabályzatok megfelelő működését. Ha a továbbított fejlécek middleware-e nincs használatban, előfordulhat, hogy a háttéralkalmazás nem kapja meg a megfelelő sémát, és átirányítási ciklusba kerülhet. Gyakori végfelhasználói hibaüzenet, hogy túl sok átirányítás van.

Az Azure App Service-be történő üzembe helyezéskor kövesse az Egyéni tartomány HTTPS-protokolljának engedélyezése az Azure App Service-ben című útmutatást.

Beállítások

A következő kiemelt kód meghívja a metódust a AddHttpsRedirection köztes szoftver beállításainak konfigurálásához:

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

A hívás AddHttpsRedirection csak az értékek HttpsPortRedirectStatusCodemódosításához szükséges.

Az előző kiemelt kód:

• A tulajdonságot a HttpsRedirectionOptions.RedirectStatusCodeStatus307TemporaryRedirect kódra állítja, amely az alapértelmezett érték. Használja az StatusCodes osztály mezőit a RedirectStatusCode hozzárendelésekhez.
• A HTTPS-portot 5001-re állítja.

Állandó átirányítások konfigurálása éles környezetben

A köztes szoftver alapértelmezés szerint minden átirányítással Status307TemporaryRedirect kódot küld. Ha az állandó átirányítási állapotkódot szeretné küldeni, amikor az alkalmazás nem környezetiDevelopment állapotban van, csomagolja be a köztes szoftver beállításainak konfigurációját egy feltételes ellenőrzésbe, amely nem környezetiDevelopment állapotot tartalmaz.

Az alábbi kód a szolgáltatások konfigurálását mutatja be a Program.cs fájlban:

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

HTTPS-átirányítási köztes szoftver alternatív megközelítése

A HTTPS átirányítási köztes szoftver (a UseHttpsRedirection metódussal) használatának alternatíva az URL-újraírás köztes szoftver használata (a AddRedirectToHttps metóduson keresztül). AddRedirectToHttps az átirányítás végrehajtásakor az állapotkódot és a portot is beállíthatja. További információkért lásd: URL-átíró köztes szoftver.

Ha az alkalmazás más átirányítási szabályok megkövetelése nélkül átirányítja a HTTPS-hez, a javaslat a HTTPS átirányítási köztes szoftver (UseHttpsRedirection) használata a jelen cikkben leírtak szerint.

HTTP Strict Transport Security (HSTS) protokoll

OWASP-enként a HSTS egy, a webalkalmazás által a válaszfejlécen keresztül megadott bejelentkezési biztonsági fejlesztés. Ha a HSTS-t támogató böngésző a következő fejlécet kapja:

• A böngésző tárolja a tartomány konfigurációját, amely megakadályozza a HTTP-en keresztüli kommunikáció küldését. A böngésző minden kommunikációt HTTPS-en keresztül kényszerít.
• A böngésző megakadályozza, hogy a felhasználó nem megbízható vagy érvénytelen tanúsítványokat használ. A böngésző letiltja azokat a kéréseket, amelyek lehetővé teszik a felhasználó számára, hogy ideiglenesen megbízzanak egy ilyen tanúsítványban.

Mivel az ügyfél kényszeríti a HSTS-t, van néhány korlátozás:

• Az ügyfélnek támogatnia kell a HSTS-t.
• A HSTS legalább egy sikeres HTTPS-kérést igényel a HSTS-szabályzat létrehozásához.
• Az alkalmazásnak minden HTTP-kérést ellenőriznie kell, és át kell irányítania vagy el kell utasítania a HTTP-kérést.

ASP.NET Core a HSTS-t bővítménymetódussal UseHsts implementálja. Az alábbi kódhívások UseHsts , ha az alkalmazás nincs fejlesztési módban:

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 nem ajánlott a fejlesztés során, mert a HSTS-beállításokat a böngészők könnyen gyorsítótárazhatják. Alapértelmezés szerint UseHsts kizárja a helyi visszacsatolási címet.

Azokban az éles környezetekben, amelyekben első alkalommal vezetik be a HTTPS-t, állítsa a kezdeti HstsOptions.MaxAge tulajdonság értékét alacsony értékre az egyik TimeSpan metódus használatával. Állítsa az értéket legfeljebb egy napra (órákban megadva), arra az esetre, ha vissza kell térnie a HTTPS-infrastruktúráról HTTP-re. Miután biztos a HTTPS-konfiguráció fenntarthatóságában, növelje a HSTS max-age értékét (általában egy év).

A következő kiemelt 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();

• Beállítja a Strict-Transport-Security fejléc előbetöltési paraméterét. Az előzetes betöltés nem része az RFC 6797 HSTS-specifikációnak. A webböngészők támogatják a HSTS-webhelyek előzetes telepítését friss telepítéskor. További információért lásd https://hstspreload.org/.
• Engedélyezi az includeSubDomain irányelvet, amely a HSTS-szabályzatot alkalmazza az altartományok üzemeltetésére. További információ: RFC 6797 HSTS-specifikáció (6.1.2. szakasz).
• Az max-age fejléc Strict-Transport-Security paraméterét explicit módon 60 napra állítja be. Ha nincs beállítva, az alapértelmezés szerint 30 nap. További információkért lásd az max-agedirektívát az RFC 6797 HSTS specifikációban (6.1.1. szakasz).
• A example.com elemet hozzáadja a kizárandó gazdagépek listájához.

UseHsts kizárja a következő visszacsatolási gazdagépeket:

• localhost: Az IPv4 visszacsatolási címe.
• 127.0.0.1: Az IPv4 visszacsatolási címe.
• [::1]: Az IPv6 visszacsatolási címe.

A HTTPS/HSTS letiltása a projekt létrehozásakor

Bizonyos háttérszolgáltatás-forgatókönyvekben, ahol a kapcsolatbiztonság a hálózat nyilvános elérésű peremhálózatán van kezelve, nem szükséges minden csomóponton konfigurálni a kapcsolatbiztonságot. A Visual Studio sablonjaiból vagy a dotnet új parancsából létrehozott webalkalmazások engedélyezik a HTTPS-átirányítást és a HSTS-t. Az olyan üzemelő példányok esetében, amelyek nem igénylik ezeket a forgatókönyveket, kikapcsolhatja a HTTPS/HSTS szolgáltatást, amikor az alkalmazás a sablonból jön létre.

A HTTPS/HSTS letiltása:

Visual Studio

Amikor új ASP.NET Core webalkalmazást hoz létre, törölje a Konfiguráció https beállítás kijelölését:

.NET parancssori felület

Használja a --no-https kapcsolót a dotnet new webapp paranccsal, például:

dotnet new webapp --no-https

Megbízható ASP.NET Core HTTPS fejlesztői tanúsítvány

A .NET SDK https fejlesztési tanúsítványt tartalmaz. A tanúsítvány az első futtatás során települ. A parancs például a dotnet --info következő kimenet egy változatát állítja elő:

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.

A .NET SDK telepítése telepíti a ASP.NET Core HTTPS fejlesztési tanúsítványt a helyi felhasználói tanúsítványtárolóba. A tanúsítvány telepítve van, de nem megbízható. A tanúsítvány megbízhatóságához hajtsa végre az eszköz futtatásához dotnet dev-certs szükséges egyszeri lépést:

dotnet dev-certs https --trust

Az alábbi parancs segítséget nyújt az dotnet dev-certs eszközről:

dotnet dev-certs https --help

Warning

Ne hozzon létre fejlesztési tanúsítványt újraterjesztésre tervezett környezetben, például tárolólemezképben vagy virtuális gépen. Ez a forgatókönyv hamisításhoz és jogosultságszint-emeléséhez vezethet. A helyzet megelőzése érdekében állítsa a DOTNET_GENERATE_ASPNET_CERTIFICATE környezeti változót false értékre, mielőtt első alkalommal meghívná a .NET parancssori felületet. Ez a megközelítés kihagyja a ASP.NET Core fejlesztési tanúsítvány automatikus létrehozását a parancssori felület első futtatása során.

Fejlesztői tanúsítvány beállítása a Dockerhez

A Docker fejlesztői tanúsítványának konfigurálásához lásd: GitHub dotnet/aspnetcore.docs 6199 - A fejlesztői tanúsítvány beállítása a Docker fejlesztésben való használatakor.

Linux-specifikus szempontok

A Linux-disztribúciók jelentősen eltérnek a tanúsítványok megbízhatóként való megjelölésétől.

Az dotnet dev-certs eszköz várhatóan széles körben alkalmazható lesz, de hivatalos támogatás csak az Ubuntu és a Fedora esetében érhető el. A támogatás kifejezetten a Firefox és a Chromium-alapú böngészők (Microsoft Edge, Chrome és Chromium) megbízhatóságának biztosítására irányul.

Dependencies

• Az OpenSSL hitelességének biztosításához az eszköznek az openssl elérési útvonalon kell lennie.
• A böngésző megbízhatóságának létrehozásához (például a Microsoft Edge vagy a Firefoxban) a certutil eszköznek az elérési úton kell lennie.

OpenSSL-megbízhatóság

Ha egy ASP.NET Core fejlesztési tanúsítvány megbízható, a rendszer exportálja a tanúsítványt az aktuális felhasználó kezdőlapjának egyik mappájába. Ahhoz, hogy az OpenSSL (és az azt használó ügyfelek) felvegyék ezt a mappát, be kell állítania a környezeti változót SSL_CERT_DIR . A változót beállíthatja egy adott munkamenetre egy, a export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs-hoz hasonló parancs futtatásával (a pontos érték a kimenetben található, amikor átadja a --verbose paramétert), vagy hozzáadhatja a(z) (disztribúció- és rendszerhéjfüggő) konfigurációs fájlhoz (például a .profile fájlhoz).

Ez a megközelítés szükséges ahhoz, hogy az olyan eszközök, mint a curl, megbízzanak a fejlesztői tanúsítványban. Alternatívaként átadhatja a -CAfile vagy -CApath értéket minden egyes curl hívásnak.

Note

Az 1.1.1h vagy újabb, illetve a 3.0.0-s vagy újabb verzió szükséges, attól függően, hogy melyik főverziót használja.

Ha az OpenSSL-megbízhatóság rossz állapotba kerül (például ha dotnet dev-certs https --clean nem sikerül eltávolítani), a c_rehash eszközzel gyakran megoldhatja a helyzetet.

Overrides

Ha egy másik böngészőt használ a saját Hálózati biztonsági szolgáltatások (NSS) tárolójával, a DOTNET_DEV_CERTS_NSSDB_PATHS környezeti változóval megadhatja az NSS-könyvtárak kettősponttal tagolt listáját (például a könyvtárat, amely cert9.dbtartalmazza). Ezután hozzáadhatja a fejlesztési tanúsítvány helyét a változó listájához.

Ha azOkat a tanúsítványokat tárolja, amelyekben az OpenSSL megbízhatónak szeretne lennie egy adott könyvtárban, a DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY környezeti változóval jelezheti a tanúsítvány helyét.

Warning

Ha bármelyik változót beállítja, minden alkalommal, amikor a megbízhatóság frissül, minden alkalommal ugyanazokat az értékeket kell megadnia. Ha az értékek megváltoznak, az eszköz nem tud a korábbi helyeken található tanúsítványokról (például a tanúsítványkarbantartás során).

A sudo használata

A többi platformhoz hasonlóan a fejlesztési tanúsítványok tárolása és megbízhatósága minden felhasználó számára külön történik.

Ha a dotnet dev-certs elemet másik felhasználóként futtatja (például a sudo használatával), akkor konkrétan az a felhasználó (például root) bízik meg a fejlesztési tanúsítványban.

HTTPS-tanúsítvány hitelesítése Linuxon a linux-dev-certs használatával

A linux-dev-certs egy nyílt forráskódú, közösség által támogatott , .NET-alapú globális eszköz, amely kényelmes módot kínál a linuxos fejlesztői tanúsítványok létrehozására és megbízhatóságára. Microsoft nem tartja karban és nem támogatja az eszközt.

Az alábbi parancsok telepítik az eszközt, és létrehoznak egy megbízható fejlesztői tanúsítványt:

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

További információkért vagy a problémák jelentéséhez tekintse meg a Linux-dev-certs GitHub-adattárat.

SUSE Linux Enterprise Server (SLES Linux)

Ha a konfiguráció tartalmazza a SUSE Linux Enterprise Servert, lásd: GitHub dotnet/aspnetcore.docs issue #28292 - HTTPS-tanúsítvány megbízhatóvá tétele SLES rendszeren.

Tanúsítványproblémák elhárítása (a tanúsítvány nem megbízható)

Előfordul, hogy egy ASP.NET Core HTTPS-fejlesztési tanúsítvány telepítve van, és megbízhatónak van jelölve, a böngésző mégis arra figyelmeztet, hogy a tanúsítvány nem megbízható. A következő szakaszok segítséget nyújtanak a probléma elhárításához.

A ASP.NET Core HTTPS fejlesztési tanúsítványt használja a Kestrelrendszer.

Az IIS Express-tanúsítvány javításához lásd: Stack Overflow-probléma #20036984/ válasz #20048613 - Hogyan állíthatom vissza a hiányzó IIS Express SSL-tanúsítványt?

Minden platform – a tanúsítvány nem megbízható

Minden platform esetében próbálja meg megoldani a nem megbízható tanúsítványokkal kapcsolatos problémákat az alábbi lépésekkel:

1. Futtassa az alábbi parancsot:

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

2. Zárja be a megnyitott böngészőpéldányokat, és nyissa meg az alkalmazást egy új böngészőablakban.

   A böngésző gyorsítótára tárolja, hogy egy tanúsítvány megbízható-e. A bezárási/megnyitási folyamat segít frissíteni a tanúsítványok böngészőgyorsítótár-beállításait.

A dotnet dev-certs https parancsok általában megoldják a böngésző megbízhatósági problémáinak többségét. Ha a dotnet dev-certs https --clean parancs sikertelen, és a böngésző továbbra sem bízik meg a tanúsítványban, próbálkozzon a platformspecifikus javaslatokkal a következő szakaszokban.

Docker – a tanúsítvány nem megbízható

Ha Dockert használ, próbálja meg megoldani a problémát az alábbi lépésekkel:

1. Törölje a C:\Users{USER}\AppData\Roaming\ASP.NET\Https mappát.

2. Tisztítsa meg az oldatot. Törölje a tároló, a és a obj, valamint a mappákat.

3. Indítsa újra a fejlesztőeszközt. Például a Visual Studio vagy a Visual Studio Code.

Windows – a tanúsítvány nem megbízható

Ha Windowsban dolgozik, hajtsa végre az alábbi hibaelhárítási lépéseket:

1. Ellenőrizze a tanúsítványtárolóban található tanúsítványokat. Keressen egy localhost tanúsítványt a ASP.NET Core HTTPS development certificate felhasználóbarát névvel két mappában:

   • Aktuális felhasználói > személyes > tanúsítványok
   • A felhasználó > megbízható legfelső szintű hitelesítésszolgáltatóinak > aktuális tanúsítványai

2. Távolítsa el az összes tanúsítványt mind a személyes, mind a megbízható legfelső szintű hitelesítésszolgáltatóktól.

   Important

   Ne távolítsa el az IIS Express localhost tanúsítványt.

3. Futtassa az alábbi parancsot:

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

4. Zárja be a megnyitott böngészőpéldányokat, és nyissa meg az alkalmazást egy új böngészőablakban.

OS X – a tanúsítvány nem megbízható

Ha az OS X-et használja, próbálja meg megoldani a problémát az alábbi lépésekkel:

1. Nyissa meg a KeyChain Accesst, majd válassza ki a rendszerkulcsláncot.

2. Ellenőrizze, hogy van-e localhost-tanúsítvány.

3. Győződjön meg arról, hogy a tanúsítvány az ikonon a plusz (+) szimbólumot jeleníti meg, amely azt jelzi, hogy a tanúsítvány minden felhasználó számára megbízható.

4. Távolítsa el a tanúsítványt a rendszerkulcsláncból.

5. Futtassa az alábbi parancsot:

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

6. Zárja be a megnyitott böngészőpéldányokat, és nyissa meg az alkalmazást egy új böngészőablakban.

A Visual Studio tanúsítványproblémáinak elhárításáról további információt a GitHub dotnet/aspnetcore probléma #16892) - HTTPS-hiba az IIS Express használatával című témakörben talál.

Linux – a tanúsítvány nem megbízható

Ha Linuxot futtat, kövesse az alábbi lépéseket a nem megbízható tanúsítvány hibaelhárításához:

1. Győződjön meg arról, hogy a vizsgált tanúsítvány a kiszolgáló által Kestrel használni tervezett felhasználói HTTPS fejlesztői tanúsítvány.

2. Ellenőrizze az aktuális felhasználó alapértelmezett HTTPS fejlesztői Kestrel tanúsítványát a következő helyen:

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

   A HTTPS fejlesztői Kestrel tanúsítványfájl az SHA1 lenyomatát tartalmazza. Ha a fájlt a dotnet dev-certs https --clean paranccsal törlik, a rendszer szükség esetén egy másik ujjlenyomattal újragenerálja a fájlt.

3. Ellenőrizze az exportált tanúsítvány ujjlenyomatát az alábbi parancs futtatásával:

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

   Ha a tanúsítvány ujjlenyomata nem egyezik, vizsgálja meg a következő feltételeket:

   • Ellenőrizze, hogy a tanúsítvány régi-e.

   • Ellenőrizze, hogy a tanúsítvány a főfelhasználó exportált fejlesztői tanúsítványa-e.

     • Ha igen, exportálja a tanúsítványt.

4. Ellenőrizze a legfelső szintű felhasználói tanúsítványt a következő mappában:

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

A Visual Studióval használt IIS Express SSL-tanúsítvány

Az IIS Express-tanúsítvánnyal kapcsolatos problémák megoldásához válassza a Repair lehetőséget a Visual Studio telepítőjében. További információ: GitHub dotnet/aspnetcore probléma #16892) - HTTPS-hiba az IIS Express használatával.

A csoportházirend megakadályozza az önaláírt tanúsítványok megbízhatóságát

Bizonyos esetekben a csoportházirend megakadályozhatja az önaláírt tanúsítványok megbízhatóságát. További információ: GitHub dotnet/aspnetcore probléma #21173 - Hiba a HTTPS fejlesztői tanúsítvány megbízhatóságával.

Kapcsolódó tartalom

• A ASP.NET Core konfigurálása proxykiszolgálókkal és terheléselosztókkal való együttműködésre
• Az ASP.NET Core kiszolgálása Linux-on Nginx-szel: HTTPS konfiguráció
• SSL beállítása az IIS 7-ben vagy újabb verziójában
• Végpontok konfigurálása webkiszolgálóhoz Kestrel
• OWASP HSTS böngésző támogatása