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

David Galvan és Rick Anderson

ez a cikk bemutatja, hogyan:

• 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.

Warning

API-projektek

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. Az ilyen ügyfelek HTTP-en keresztül küldhetnek információkat. A webes API-knak a következőkre van szükség:

• 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.

HSTS- és API-projektek

Az alapértelmezett API-projektek nem tartalmazzák a HSTS-t , mivel a HSTS általában csak böngészőutasítás . 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. A biztonságos megközelítés az API-projektek konfigurálása, hogy csak a HTTPS-en keresztül hallgassanak és válaszoljanak.

A HTTP-ről HTTPS-re történő átirányítás ERR_INVALID_REDIRECT hibát okoz a CORS-elővizsgálati kérelemben.

A HTTP-t használó végpontra irányuló kérelmek, amelyeket a UseHttpsRedirection HTTPS-re átirányítanak, sikertelenek a CORS elővizsgálati kérelem során ERR_INVALID_REDIRECT.

Az API-projektek elutasíthatják a HTTP-kéréseket, ahelyett, hogy UseHttpsRedirection segítségével irányítanák át a kéréseket HTTPS-re.

HTTPS megkövetelése

Javasoljuk, hogy az éles ASP.NET Core-webalkalmazások a következőket használják:

• HTTPS Redirection Middleware (UseHttpsRedirection) a HTTP-kérések HTTPS-hez való átirányításához.
• A HSTS Middleware (UseHsts) http strict transport security protocol (HSTS) fejléceket küld az ügyfeleknek.

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 Redirection Middleware 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 IIS 10.0 -ban (1709) vagy újabb verziókban), az alkalmazás nem igényli a HSTS Middleware-t. További információ: HTTPS/HSTS letiltása a projektlétrehozáskor.

UseHttpsRedirection

A következő kódhívás a UseHttpsRedirection fájlban található: 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();

Az előző kiemelt kód:

• Az alapértelmezett HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect) értéket használja.
• Az alapértelmezett HttpsRedirectionOptions.HttpsPort (null) értéket használja, kivéve, ha azt a ASPNETCORE_HTTPS_PORT környezeti változó vagy IServerAddressesFeature felülírja.

Javasoljuk, hogy ideiglenes átirányításokat használjunk á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, ha az alkalmazás nem fejlesztési környezetben van, tekintse meg az állandó átirányítások konfigurálása az éles környezetben című szakaszt. Javasoljuk, hogy HSTS használatával jelezhesse az ügyfeleknek, hogy csak biztonságos erőforrás-kérelmeket kell küldeni az alkalmazásnak (csak éles környezetben).

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 következő figyelmeztetést: "Nem sikerült 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.

  • Úgy, hogy hozzáadsz egy legfelső szintű bejegyzést itt: appsettings.json.

    {
      "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.

• Az ASP.NET Core-websablonok HTTPS-URL címet állítanak be a Properties/launchsettings.json mind a Kestrel mind az IIS Express számára. launchsettings.json 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íthassa 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 fordított proxykonfigurációt használ a kérelmek továbbítására, a HTTPS Redirection Middleware meghívása előtt használja a Forwarded Headers Middleware szoftvert. A továbbított fejlécek köztes réteg frissíti a Request.Scheme fejléceket X-Forwarded-Proto segítségével. 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 köztes szoftver nincs használatban, előfordulhat, hogy a háttéralkalmazás nem kapja meg a megfelelő sémát, és átirányítási hurokba kerül. Gyakori végfelhasználói hibaüzenet, hogy túl sok átirányítás történt.

Az Azure App Service-ben való üzembe helyezéskor kövesse az oktatóanyag útmutatását : Meglévő egyéni SSL-tanúsítvány kötése az Azure Web Appshez.

Beállítások

A köztes szoftver beállításainak konfigurálásához a következő kiemelt kódhívások AddHttpsRedirection :

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:

• HttpsRedirectionOptions.RedirectStatusCode beállítása Status307TemporaryRedirect értékre, ami az alapértelmezett. 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ésként egy Status307TemporaryRedirect küld az összes átirányításnál. Ha tartós átirányítási állapotkódot szeretne küldeni, ha az alkalmazás nem fejlesztési környezetben van, csomagolja be a köztes szoftver beállításainak konfigurációját egy feltételes ellenőrzésbe egy nem fejlesztési környezethez.

Szolgáltatások konfigurálásakor a következő helyen 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();

HTTPS Redirection Middleware alternatív megközelítés

Az HTTPS Redirection Middleware (UseHttpsRedirection) alternatívája az URL Rewriting Middleware (AddRedirectToHttps) használata. 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 az URL-cím újraírása köztes szoftvereket.

Ha a HTTPS-hez a további átirányítási szabályok megkövetelése nélkül szeretne átirányítani, javasoljuk, hogy a jelen cikkben ismertetett HTTPS Redirection Middleware (UseHttpsRedirection) szolgáltatást használja.

HTTP Szigorú átviteli biztonsági protokoll (HSTS)

Az OWASP szerint a HTTP Strict Transport Security (HSTS) egy válaszfejlécen keresztül megadott, opt-in biztonsági fejlesztés, amelyet a webalkalmazás kínál. 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 a HSTS-t az ügyfél kényszeríti ki, bizonyos korlátozásokkal rendelkezik:

• 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.

A HTTPS-t első alkalommal implementáló éles környezetekben állítsa a kezdeti HstsOptions.MaxAge értéket egy kis értékre az TimeSpan egyik metódus használatával. Állítsa be az értéket úgy, hogy órák helyett legfeljebb egy nap legyen, arra az esetre, ha vissza kell állítania a HTTPS-infrastruktúrát HTTP-re. Miután biztos a HTTPS-konfiguráció fenntarthatóságában, növelje a HSTS-értéket max-age ; a gyakran használt érték 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 adatbetöltés nem része az RFC HSTS-specifikációnak, de a webböngészők támogatják a HSTS-webhelyek új telepítésre való előzetes betöltését. További információért lásd https://hstspreload.org/.
• Engedélyezi az includeSubDomain beállítást, amely a HSTS-szabályzatot alkalmazza a Host altartományaira.
• 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értelmezett érték 30 nap. További információt a maximális életkorról szóló irányelvben talál.
• 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 projektlétrehozáskor

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, nincs szükség a kapcsolatbiztonság konfigurálására az egyes csomópontokon. 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, ha az alkalmazás a sablonból jön létre.

A HTTPS/HSTS letiltása:

Visual Studio

Törölje a jelölést a HTTPS konfigurálás jelölőnégyzetből.

.NET CLI

Használja a --no-https lehetőséget. 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. Például dotnet --info a következő kimenet egy változata jelenik meg:

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 olyan környezetben, amely újraterjesztésre kerül, például tárolólemezképet vagy virtuális gépet. Ez hamisításhoz és jogosultságszint-emeléséhez vezethet. Ennek elkerülése érdekében állítsa a DOTNET_GENERATE_ASPNET_CERTIFICATE környezeti változót false a .NET CLI első meghívása előtt. Ez 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

Lásd ezt a GitHub-hibajegyet.

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. Bár dotnet dev-certs várhatóan széles körben alkalmazható, hivatalosan csak az Ubuntu és a Fedora támogatott. Kifejezetten arra törekszik, hogy biztosítsa a bizalmat a Firefox és a Chromium-alapú böngészőkben (Edge, Chrome és Chromium).

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 az Edge-ben vagy a Firefoxban) az certutil eszköznek az elérési úton kell lennie.

OpenSSL-megbízhatóság

Ha a ASP.NET Core fejlesztési tanúsítvány megbízható, a rendszer az aktuális felhasználó kezdőlapjának egyik mappájába exportálja. 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 . Ezt vagy egyetlen munkamenetben megteheti egy olyan parancs futtatásával, mint export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (a pontos érték a kimenetben jelenik meg, amikor a --verbose-t használja), vagy hozzáadhatja a (disztribúció- és rendszerhéj-specifikus) konfigurációs fájlhoz (például .profile).

Ahhoz, hogy az olyan eszközök, mint curl, megbízhatónak tekintsék a fejlesztési tanúsítványt. Vagy másik lehetőségként átadhatja -CAfile vagy -CApath minden egyes curl meghívásához.

Vegye figyelembe, hogy ehhez 1.1.1h vagy újabb vagy 3.0.0-s vagy újabb verzióra van szükség, 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), gyakran lehet helyesen beállítani a dolgokat az c_rehash eszközzel.

Overrides

Ha egy másik böngészőt használ saját Hálózati biztonsági szolgáltatások (NSS) tárolóval, a környezeti változóval DOTNET_DEV_CERTS_NSSDB_PATHS megadhatja az NSS-címtárak (például az azt tartalmazó cert9.dbkönyvtár) kettősponttal tagolt listáját, amelyhez hozzá szeretné adni a fejlesztési tanúsítványt.

Ha egy adott könyvtárban tárolja azOkat a tanúsítványokat, amelyeket az OpenSSL-ben szeretne megbízni, a DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY környezeti változóval jelezheti, hogy hol van.

Warning

Ha ezen változók egyikét állítja be, fontos, hogy minden megbízhatósági kapcsolat frissítésekor ugyanazokra az értékekre legyenek beállítva. Ha változnak, az eszköz nem fog tudni a korábbi helyeken található tanúsítványokról (például a tisztításukhoz).

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. Ennek eredményeképpen, ha más felhasználóként futtatja a dotnet dev-certs-t (például a sudo használatával), akkor az a felhasználó (például ) fogja megbízni a fejlesztési tanúsítványt.

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. Az eszközt a Microsoft nem tartja karban és nem támogatja.

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

A GitHub-probléma megtekintése

A tanúsítványokkal kapcsolatos problémák, például a nem megbízható tanúsítványok hibaelhárítása

Ez a szakasz segítséget nyújt a ASP.NET Core HTTPS-fejlesztési tanúsítvány telepítésekor és megbízhatóságában, de böngészőbeli figyelmeztetések vannak arról, hogy a tanúsítvány nem megbízható. 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 tekintse meg ezt a Stackoverflow-problémát .

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

Futtassa az alábbi parancsot:

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

Zárja be a megnyitott böngészőpéldányokat. Nyisson meg egy új böngészőablakot az alkalmazás számára. A tanúsítványmegbízhatóságot a böngészők gyorsítótárazják.

dotnet dev-certs https --clean sikertelen

Az előző parancsok a böngésző megbízhatóságával kapcsolatos legtöbb problémát megoldják. Ha a böngésző továbbra sem bízik a tanúsítványban, kövesse az alábbi platformspecifikus javaslatokat.

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

• Törölje a C:\Users{USER}\AppData\Roaming\ASP.NET\Https mappát.
• Tisztítsa meg az oldatot. Törölje a tároló, a és a obj, valamint a mappákat.
• 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ó

• Ellenőrizze a tanúsítványtárolóban található tanúsítványokat. Egy localhost tanúsítványnak kell lennie ASP.NET Core HTTPS development certificate barátságos névvel, mind Current User > Personal > Certificates mind Current User > Trusted root certification authorities > Certificates alatt.
• Távolítsa el az összes talált tanúsítványt mind a személyes, mind a megbízható legfelső szintű hitelesítésszolgáltatóktól. Ne távolítsa el az IIS Express localhost tanúsítványt.
• Futtassa az alábbi parancsot:

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

Zárja be a megnyitott böngészőpéldányokat. Nyisson meg egy új böngészőablakot az alkalmazás számára.

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

• Nyissa meg a KeyChain Accesst.
• Válassza ki a rendszerkulcsláncot.
• Ellenőrizze, hogy van-e localhost-tanúsítvány.
• Ellenőrizze, hogy tartalmaz-e szimbólumot + az ikonon, hogy az az összes felhasználó számára megbízható-e.
• Távolítsa el a tanúsítványt a rendszerkulcsláncból.
• Futtassa az alábbi parancsot:

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

Zárja be a megnyitott böngészőpéldányokat. Nyisson meg egy új böngészőablakot az alkalmazás számára.

A Visual Studióval kapcsolatos tanúsítványproblémák elhárításához lásd: HTTPS-hiba az IIS Express használatával (dotnet/AspNetCore #16892).

A Linux-tanúsítvány nem megbízható

Ellenőrizze, hogy a megbízhatóságra konfigurált tanúsítvány a kiszolgáló által Kestrel használt felhasználói HTTPS fejlesztői tanúsítvány-e.

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. A fájl törlésekor a dotnet dev-certs https --clean rendszeren keresztül, szükség esetén, egy másik ujjlenyomattal újragenerálódik. Ellenőrizze az exportált tanúsítvány ujjlenyomatát az alábbi paranccsal:

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

Ha a tanúsítvány nem egyezik, az a következők egyike lehet:

• Egy régi tanúsítvány.
• Exportált egy fejlesztői tanúsítványt a legfelső szintű felhasználó számára. Ebben az esetben exportálja a tanúsítványt.

A legfelső szintű felhasználói tanúsítvány a következő helyen ellenőrizhető:

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 Visual Studio telepítőjének Javítás elemét. További információkért tekintse meg ezt a GitHub-problémát.

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ókért tekintse meg ezt a GitHub-problémát.

További információk

• A ASP.NET Core konfigurálása proxykiszolgálókkal és terheléselosztókkal való együttműködésre
• Host ASP.NET Core on Linux with Nginx: HTTPS configuration
• SSL beállítása IIS-en
• Végpontok konfigurálása az ASP.NET Core Kestrel webkiszolgálóhoz
• OWASP HSTS böngésző támogatása