ASP.NET Core'da HTTPS'i zorunlu kılma

David Galvan ve Rick Anderson tarafından

https/TLS kullanmak üzere ASP.NET Core uygulamalarınıza gelen istekleri zorunlu kılmak için şunları yapabilirsiniz:

• Tüm istekler için HTTPS iste.
• Tüm HTTP isteklerini HTTPS'ye yeniden yönlendirir.

Hiçbir API, istemcinin ilk istekte hassas veriler göndermesini önleyemez.

Bu makalede, ASP.NET Core uygulamalarınızı HTTPS/TLS gerektirecek şekilde yapılandırma veya güvenli etkileşim için HTTP isteklerini HTTPS/TLS'ye yönlendirme işlemleri açıklanmaktadır. Güvenilmeyen sertifika sorunlarını çözmek için çeşitli platformlar için sorun giderme adımları sağlanır.

API projeleri

Web API'lerini kullanan projeler aşağıdakilerden birini yapmalıdır:

• HTTP'de dinlemeyin.
• 400 (Hatalı İstek) durum koduyla bağlantıyı kapatın ve isteği sunmayın.

API'de HTTP yeniden yönlendirmesini devre dışı bırakmak için ortam değişkenini ASPNETCORE_URLS ayarlayın veya komut satırı bayrağını --urls kullanın. Daha fazla bilgi için bkz . ASP.NET Core çalışma zamanı ortamları ve Andrew Lock tarafından ASP.NET Core uygulamasının URL'lerini ayarlamanın 8 yolu .

Warning

Hassas bilgiler alan Web API'lerinde kullanmayınRequireHttpsAttribute. RequireHttpsAttribute tarayıcıları HTTP'den HTTPS'ye yönlendirmek için HTTP durum kodlarını kullanır. API istemcileri HTTP'den HTTPS'ye yönlendirmeleri anlamayabilir veya bunlara uymayabilir ve HTTP üzerinden bilgi gönderebilir.

HSTS ve API projeleri

HTTP Katı Aktarım Güvenliği (HSTS) protokolü için güvenli yaklaşım, API projelerini yalnızca HTTPS üzerinden dinleyecek ve yanıt verecek şekilde yapılandırmaktır.

Warning

Genellikle yalnızca bir tarayıcı yönergesi olduğundan varsayılan API projeleri HSTS içermez. Telefon veya masaüstü uygulamaları gibi diğer arayanlar yönergeye uymaz. Tarayıcılar içinde bile, HTTP üzerinden API'ye yapılan tek bir kimliği doğrulanmış çağrının güvenli olmayan ağlarda riskleri vardır.

HTTP'den HTTPS'ye yönlendirme (CORS ön kontrol isteğinde ERR_INVALID_REDIRECT)

HTTP kullanan bir uç noktaya yapılan istek, UseHttpsRedirection yöntemiyle HTTPS'ye yönlendirildiğinde, yeniden yönlendirme CORS ön kontrol isteğinde ERR_INVALID_REDIRECT hatasıyla başarısız olur.

API projeleri, istekleri HTTPS'ye yeniden yönlendirmek için UseHttpsRedirection yöntemini kullanmak yerine HTTP isteklerini reddedebilir.

HTTPS'i zorunlu kıl.

Üretim ASP.NET Core web uygulamaları için aşağıdaki yaklaşım önerilir:

• HTTP isteklerini HTTPS'ye yönlendirmek için HTTPS yeniden yönlendirme ara yazılımını (UseHttpsRedirection ) kullanın.

• İstemcilere HSTS üst bilgileri göndermek için UseHsts yöntemi aracılığıyla HSTS ara yazılımını kullanın.

Note

Ters ara sunucu yapılandırmasında dağıtılan uygulamalar, proxy'nin bağlantı güvenliğini (HTTPS) işlemesine olanak tanır. Proxy, HTTPS yeniden yönlendirmeyi de işleyecekse, HTTPS yeniden yönlendirme ara yazılımını kullanmanız gerekmez. Proxy sunucusu HSTS üst bilgilerini de yazıyorsa (örneğin, Internet Information Services (IIS) 10.0 sürüm 1709 ve sonraki sürümlerde yerel HSTS desteği), uygulama HSTS ara katmanını gerektirmez. Daha fazla bilgi için bkz . Proje oluşturma işleminde HTTPS/HSTS'yi geri çevirme.

UseHttpsRedirection

Aşağıdaki kod, UseHttpsRedirection dosyasında yöntemini çağırır:

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

Yukarıdaki vurgulanan kod:

• Varsayılan HttpsRedirectionOptions.RedirectStatusCode özelliğini Status307TemporaryRedirect koduyla kullanır.
• HttpsRedirectionOptions.HttpsPort ortam değişkeni veya ASPNETCORE_HTTPS_PORT tarafından geçersiz kılınmadığı sürece varsayılan IServerAddressesFeature özelliğini kullanır (null geçirilerek).

Önerilen yaklaşım, kalıcı yeniden yönlendirmeler yerine geçici yeniden yönlendirmeler kullanmaktır. Bağlantı önbelleğe alma, geliştirme ortamlarında kararsız davranışlara neden olabilir. Uygulama Development ortamında değilken kalıcı yönlendirme durum kodu göndermeyi tercih ediyorsanız, Prodüksiyon ortamında kalıcı yönlendirmeleri yapılandırma bölümüne bakın. İstemcilere yalnızca güvenli kaynak isteklerinin uygulamaya gönderilmesi gerektiğini (yalnızca üretimde) sinyal vermek için HSTS kullanın.

Bağlantı noktası yapılandırması

Güvenli olmayan bir isteği HTTPS'ye yönlendirmek için ara yazılım için bir bağlantı noktası kullanılabilir olmalıdır. Kullanılabilir bağlantı noktası yoksa:

• HTTPS'ye yeniden yönlendirme gerçekleşmez.
• Ara yazılım, yeniden yönlendirme için https bağlantı noktasını belirleyemedi uyarısını günlüğe kaydeder.

Aşağıdaki yaklaşımlardan herhangi birini kullanarak HTTPS bağlantı noktasını belirtin:

• HttpsRedirectionOptions.HttpsPort'u ayarlayın.

• https_port Konak ayarını ayarlayın:

  • Sunucu yapılandırmasında.

  • Ortam değişkenini ASPNETCORE_HTTPS_PORT ayarlayarak.

  • appsettings.json dosyasına üst düzey girdi ekleyerek:

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

• ASPNETCORE_URLS ortam değişkenini kullanarak güvenli şemaya sahip bir bağlantı noktası belirtin. Ortam değişkeni sunucuyu yapılandırıyor. Ara yazılım, IServerAddressesFeature aracılığıyla HTTPS bağlantı noktasını dolaylı olarak bulur. Bu yaklaşım ters ara sunucu dağıtımlarında çalışmaz.

• ASP.NET Core web şablonları, hem hem de IIS Express için Kestrel dosyasında bir HTTPS URL'si ayarlar. launchsettings.json dosyası yalnızca yerel makinede kullanılır.

• Sunucunun veya HTTP.sys sunucusunun genel erişime açık uç dağıtımı için bir HTTPS URL uç noktası yapılandırın. Uygulama tarafından yalnızca bir HTTPS bağlantı noktası kullanılır. Orta katman yazılımı IServerAddressesFeature aracılığıyla bağlantı noktasını bulur.

Note

Bir uygulama reverse proxy yapılandırmasında çalıştığında, IServerAddressesFeature kullanılamaz. Bu bölümde açıklanan diğer yaklaşımlardan birini kullanarak bağlantı noktasını ayarlayın.

Edge dağıtımları

Kestrel HTTP.sys genel kullanıma açık bir uç sunucu olarak kullanıldığında, Kestrel veya HTTP.sys her ikisinin de dinlenmesi için yapılandırılmalıdır.

• İstemcinin yeniden yönlendirildiği güvenli bağlantı noktası (genellikle, üretimde 443 ve geliştirme aşamasında 5001).
• Güvenli olmayan port (genellikle üretimde 80, geliştirme ortamında 5000 olarak kullanılır).

Uygulamanın güvenli olmayan bir isteği alabilmesi ve istemciyi güvenli bağlantı noktasına yönlendirebilmesi için güvenli olmayan bağlantı noktasının istemci tarafından erişilebilir olması gerekir.

Daha fazla bilgi için bkzKestrel. ASP.NET Core'da uç nokta yapılandırması veya HTTP.sys web sunucusu uygulaması.

Dağıtım senaryoları

İstemci ve sunucu arasındaki tüm güvenlik duvarlarının da trafik için açık iletişim bağlantı noktaları olmalıdır.

İstekler ters ara sunucu yapılandırmasında iletiliyorsa, HTTPS yeniden yönlendirme ara yazılımını çağırmadan önce iletilen üst bilgi ara yazılımını kullanın. İletilen üst bilgiler ara yazılımı, X-Forwarded-Proto üst bilgisini kullanarak Request.Scheme günceller. Ara yazılım, yeniden yönlendirme URI'lerinin ve diğer güvenlik ilkelerinin düzgün çalışmasına izin verir. İletilen başlıklar ara yazılımı kullanılmadığında, arka uç uygulaması doğru şemayı alamayabilir ve bir yeniden yönlendirme döngüsüne girebilir. Sık karşılaşılan son kullanıcı hata iletisi, çok fazla yeniden yönlendirme olmasıdır.

Azure App Service dağıtırken Azure App Service'da özel bir etki alanı için HTTPS'yi etkinleştirme başlığındaki yönergeleri izleyin.

Options

Aşağıda vurgulanan kod, ara yazılım seçeneklerini yapılandırmak için AddHttpsRedirection yöntemini çağırır:

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

AddHttpsRedirection çağrısı yalnızca HttpsPort veya RedirectStatusCode değerlerini değiştirmek için gereklidir.

Yukarıdaki vurgulanan kod:

• HttpsRedirectionOptions.RedirectStatusCode özelliğini Status307TemporaryRedirect varsayılan değer olan koda ayarlar. StatusCodes sınıfının alanlarını RedirectStatusCode için atamalar için kullanın.
• HTTPS bağlantı noktasını 5001 olarak ayarlar.

Üretimde kalıcı yeniden yönlendirmeleri yapılandırma

Ara yazılım varsayılan olarak tüm yeniden yönlendirmelerle bir Status307TemporaryRedirect kod gönderir. Uygulama belirtilen ortamda değilken kalıcı bir yönlendirme durum kodu göndermeyi tercih ediyorsanız, ara yazılım seçenekleri yapılandırmasını bu ortamda olmadığını kontrol eden bir koşullu ifadeye sarın.

Aşağıdaki kod , Program.cs dosyasındaki hizmetlerin yapılandırmasını gösterir:

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 yeniden yönlendirme ara yazılımı alternatif yaklaşımı

HTTPS yeniden yönlendirme ara yazılımını (yöntemiyle UseHttpsRedirection ) kullanmanın bir alternatifi, URL yeniden yazma ara yazılımını (yöntemi aracılığıyla AddRedirectToHttps ) kullanmaktır. AddRedirectToHttps , yeniden yönlendirme yürütülürken durum kodunu ve bağlantı noktasını da ayarlayabilir. Daha fazla bilgi için bkz. URL yeniden yazma ara yazılımı.

Uygulama diğer yeniden yönlendirme kurallarına gerek kalmadan HTTPS'ye yeniden yönlendirildiğinde, bu makalede açıklandığı gibi HTTPS yeniden yönlendirme ara yazılımının (UseHttpsRedirection) kullanılması önerilir.

HTTP Katı Aktarım Güvenliği (HSTS) protokolü

OWASP'ye göre, HSTS, bir web uygulaması tarafından bir yanıt başlığı aracılığıyla tanımlanan isteğe bağlı bir güvenlik geliştirmesidir. HSTS destekleyen bir tarayıcı bu üst bilgiyi aldığında:

• Tarayıcı, HTTP üzerinden herhangi bir iletişim gönderilmesini engelleyen etki alanının yapılandırmasını depolar. Tarayıcı, tüm iletişimi HTTPS üzerinden yönlendirir.
• Tarayıcı, kullanıcının güvenilmeyen veya geçersiz sertifikalar kullanmasını engeller. Tarayıcı, kullanıcının bu tür bir sertifikaya geçici olarak güvenmesine izin veren istemleri devre dışı bırakır.

İstemci HSTS'yi zorunlu kıldığından bazı sınırlamalar vardır:

• İstemcinin HSTS'yi desteklemesi gerekir.
• HSTS, HSTS ilkesini oluşturmak için en az bir başarılı HTTPS isteği gerektirir.
• Uygulamanın her HTTP isteğini denetlemesi ve HTTP isteğini yeniden yönlendirmesi veya reddetmesi gerekir.

ASP.NET Core, uzantı yöntemiyle UseHsts HSTS uygular. Uygulama geliştirme modunda değilken, aşağıdaki kod UseHsts çağrılır.

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 geliştirme aşamasında önerilmez çünkü HSTS ayarları tarayıcılar tarafından yüksek oranda önbelleğe alınabilir. Varsayılan olarak, UseHsts yerel geri döngü adresini dışlar.

HTTPS'yi ilk kez uygulayan üretim ortamları için yöntemlerden birini HstsOptions.MaxAge kullanarak ilk TimeSpan özellik değerini küçük bir miktara ayarlayın. HTTPS altyapısını HTTP'ye geri döndürmeniz gerekirse, saat değerini tek bir günden fazla olmayacak şekilde ayarlayın. HTTPS yapılandırmasının sürdürülebilirliğine güvendikten sonra HSTS max-age değerini artırın (genellikle bir yıl).

Aşağıdaki vurgulanmış kod:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• Strict-Transport-Security başlığının ön yükleme parametresini ayarlar. Önceden yükleme , RFC 6797 HSTS belirtiminin bir parçası değildir. Web tarayıcıları, yeni yüklemede HSTS sitelerinin önceden yüklenmesini destekler. Daha fazla bilgi için bkz. https://hstspreload.org/.
• includeSubDomain HSTS ilkesini alt etki alanlarına uygulayan yönergesini etkinleştirir. Daha fazla bilgi için bkz. RFC 6797 HSTS belirtimi (Bölüm 6.1.2).
• Üst bilgi max-age'in Strict-Transport-Security parametresini açıkça 60 güne ayarlar. Ayarlanmadıysa, varsayılan olarak 30 gün olur. Daha fazla bilgi için max-age içindeki yönergeye bakın.
• Hariç tutulacak konaklar listesine example.com ekler.

UseHsts aşağıdaki geri döngü konaklarını dışlar:

• localhost: IPv4 geri döngü adresi.
• 127.0.0.1: IPv4 geri döngü adresi.
• [::1]: IPv6 geri döngü adresi.

Proje oluşturma işleminde HTTPS/HSTS'i geri çevirme

Bağlantı güvenliğinin ağın genel kullanıma yönelik kenarında işlendiği bazı arka uç hizmet senaryolarında, her düğümde bağlantı güvenliğini yapılandırmak gerekmez. Visual Studio'daki şablonlardan veya dotnet new komutundan oluşturulan web uygulamaları HTTPS yeniden yönlendirmesini ve HSTS'yi etkinleştirir. Bu senaryoları gerektirmeyen dağıtımlar için, uygulama şablondan oluşturulduğunda HTTPS/HSTS'yi geri çevirebilirsiniz.

HTTPS/HSTS'yi geri çevirmek için:

Visual Studio

Yeni bir ASP.NET Core web uygulaması oluşturduğunuzda HTTPS için Configure seçeneğinin seçimini kaldırın:

.NET CLI

--no-https komutuyla dotnet new webapp seçeneğini kullanın, örneğin:

dotnet new webapp --no-https

ASP.NET Core HTTPS geliştirme sertifikasına güvenme

.NET SDK'sı bir HTTPS geliştirme sertifikası içerir. Sertifika, ilk çalıştırma deneyiminin bir parçası olarak yüklenir. Örneğin, dotnet --info komut aşağıdaki çıkışın bir çeşitlemini oluşturur:

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.

.NET SDK'sını yüklemek ASP.NET Core HTTPS geliştirme sertifikasını yerel kullanıcı sertifika deposuna yükler. Sertifika yüklü, ancak güvenilir değil. Sertifikaya güvenmek için aracı çalıştırmak için tek seferlik adımı gerçekleştirin dotnet dev-certs :

dotnet dev-certs https --trust

Aşağıdaki komut, dotnet dev-certs aracı hakkında yardım bilgisi verir.

dotnet dev-certs https --help

Warning

Kapsayıcı görüntüsü veya sanal makine gibi yeniden dağıtım için planlanan bir ortamda geliştirme sertifikası oluşturmayın. Bu senaryo kimlik sahtekarlığına ve ayrıcalıkların yükseltilmesine yol açabilir. Bu durumun önlenmesine yardımcı olmak için, .NET CLI'yı ilk kez çağırmadan önce DOTNET_GENERATE_ASPNET_CERTIFICATE ortam değişkenini false olarak ayarlayın. Bu yaklaşım, CLI'nın ilk çalıştırma deneyimi sırasında ASP.NET Core geliştirme sertifikasının otomatik olarak oluşturulmasını atlar.

Docker için geliştirici sertifikası ayarlama

Docker için geliştirici sertifikasını yapılandırmak için bkz. GitHub dotnet/aspnetcore.docs sorunu #6199 - Geliştirme aşamasında Docker kullanırken geliştirme sertifikası nasıl ayarlanır.

Linux'a özgü dikkat edilmesi gerekenler

Linux dağıtımları, sertifikaları güvenilir olarak işaretleme açısından önemli ölçüde farklılık gösterir.

Aracın dotnet dev-certs geniş ölçüde uygulanabilir olması beklenir, ancak yalnızca Ubuntu ve Fedora için resmi destek sağlanır. Destek özellikle Firefox ve Chromium tabanlı tarayıcılara (Microsoft Edge, Chrome ve Chromium) güven sağlanmasını amaçlar.

Dependencies

• OpenSSL güvenini sağlamak için openssl aracının sistem yolunda olması gerekir.
• Tarayıcı güveni oluşturmak için (örneğin Microsoft Edge veya Firefox'ta), certutil aracı yolda olmalıdır.

OpenSSL güvenilirliği

ASP.NET Core geliştirme sertifikasına güvenildiğinde, sertifika geçerli kullanıcının giriş dizinindeki bir klasöre aktarılır. OpenSSL'nin (ve kullanan istemcilerin) bu klasörü almasını sağlamak için ortam değişkenini SSL_CERT_DIR ayarlamanız gerekir. gibi export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs bir komut çalıştırarak (geçirildiğinde --verbose tam değer çıktıdadır) veya (distro ve kabuğa özgü) yapılandırma dosyanızı (örneğin .profile) ekleyerek değişkeni tek bir oturumda ayarlayabilirsiniz.

curl gibi araçların geliştirme sertifikasına güvenmesini sağlamak için bu yaklaşım gereklidir. Alternatif olarak, her bir -CAfile çağrısına -CApath veya curl iletebilirsiniz.

Note

Kullandığınız ana sürüme bağlı olarak 1.1.1h veya üzeri ya da 3.0.0 veya üzeri gerekir.

OpenSSL güven yapısı bozuk bir duruma girerse (örneğin dotnet dev-certs https --clean bunu kaldıramazsa), durumu çoğu zaman c_rehash aracını kullanarak çözebilirsiniz.

Overrides

Kendi Ağ Güvenlik Hizmetleri (NSS) deposuna sahip başka bir tarayıcı kullanıyorsanız, ortam değişkenini DOTNET_DEV_CERTS_NSSDB_PATHS kullanarak NSS dizinlerinin iki nokta üst üste ayrılmış listesini (örneğin, içeren cert9.dbdizin) belirtebilirsiniz. Daha sonra geliştirme sertifikası konumunu değişkendeki listeye ekleyebilirsiniz.

OpenSSL'nin güvenmesini istediğiniz sertifikaları belirli bir dizinde depolarsanız, sertifika konumunu belirtmek için ortam değişkenini kullanabilirsiniz DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY .

Warning

Değişkenlerden birini ayarlarsanız, güven her güncelleştirildiğinde aynı değerleri ayarladığınızdan emin olun. Değerler değişirse, araç eski konumlardaki sertifikalar hakkında bilgi edinemez (örneğin, sertifika temizleme sırasında).

Sudo kullanma

Diğer platformlarda olduğu gibi geliştirme sertifikaları da her kullanıcı için ayrı olarak depolanır ve güvenilir.

dotnet dev-certs öğesini farklı bir kullanıcı olarak (örneğin, sudo kullanarak) çalıştırırsanız, bu durumda özellikle söz konusu kullanıcı (örneğin root) geliştirme sertifikasına güvenir.

Linux-dev-certs ile Linux'ta HTTPS sertifikasına güvenme

linux-dev-certs , Linux üzerinde geliştirici sertifikası oluşturmak ve güvenmek için kullanışlı bir yol sağlayan açık kaynak, topluluk tarafından desteklenen bir .NET genel aracıdır. Microsoft aracın bakımını yapmaz veya desteklemez.

Aşağıdaki komutlar aracı yükler ve güvenilir bir geliştirici sertifikası oluşturur:

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

Daha fazla bilgi edinmek veya sorunları bildirmek için bkz . linux-dev-certs GitHub deposu.

SUSE Linux Enterprise Server (SLES Linux)

Yapılandırmanız SUSE Linux Enterprise Server içeriyorsa bkz. GitHub dotnet/aspnetcore.docs sorunu #28292 - SLES üzerinde HTTPS sertifikasına güvenin.

Sertifika sorunlarını giderme (sertifika güvenilir değil)

Bazen bir ASP.NET Core HTTPS geliştirme sertifikası yüklenip güvenilen bir sertifika olduğunda, tarayıcı sertifikanın güvenilir olmadığı konusunda uyarı verir. Aşağıdaki bölümler bu sorunu gidermeye yönelik yardım sağlar.

ASP.NET Core HTTPS geliştirme sertifikası, Kestrel tarafından kullanılır.

IIS Express sertifikasını onarmak için bkz. Stack Overflow sorunu #20036984 / answer #20048613 - Eksik IIS Express SSL Sertifikasını nasıl geri yükleyebilirim?

Tüm platformlar - sertifika güvenilir değil

Tüm platformlar için güvenilmeyen sertifika sorunlarını aşağıdaki adımlarla çözmeyi deneyin:

1. Aşağıdaki komutları çalıştırın:

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

2. Açık tarayıcı örneklerini kapatın ve uygulamayı yeni bir tarayıcı penceresinde açın.

   Tarayıcı önbelleği bir sertifikanın güvenilir olup olmadığını depolar. Kapatma/açma işlemi, sertifikaların tarayıcı önbellek ayarlarını yenilemeye yardımcı olur.

Komutlar dotnet dev-certs https genellikle tarayıcı güveni sorunlarının çoğunu çözer. dotnet dev-certs https --clean Komut başarısız olursa ve tarayıcı sertifikaya hala güvenmiyorsa, aşağıdaki bölümlerde platforma özgü önerileri deneyin.

Docker - sertifika güvenilir değil

Docker kullanıyorsanız sorunu aşağıdaki adımlarla çözmeyi deneyin:

1. C:\Users{USER}\AppData\Roaming\ASP.NET\Https klasörünü silin.

2. Çözümü temizleyin. bin ve obj klasörlerini silin.

3. Geliştirme aracını yeniden başlatın. Örneğin, Visual Studio veya Visual Studio Code.

Windows - sertifika güvenilir değil

Windows'de çalışıyorsanız aşağıdaki sorun giderme adımlarını tamamlayın:

1. Sertifika deposundaki sertifikaları denetleyin. İki klasörde, localhost kolay adına sahip bir ASP.NET Core HTTPS development certificate sertifikası arayın:

   • Geçerli Kullanıcı > Kişisel > Sertifikaları
   • Geçerli Kullanıcı > Güvenilen Kök Sertifika Yetkilileri > Sertifikalar

2. Hem Kişisel hem de Güvenilen kök sertifika yetkililerinden tüm sertifikaları kaldırın.

   Important

   IIS Express localhost sertifikasını kaldırmayın.

3. Aşağıdaki komutları çalıştırın:

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

4. Açık tarayıcı örneklerini kapatın ve uygulamayı yeni bir tarayıcı penceresinde açın.

OS X - sertifika güvenilir değil

OS X ile çalışıyorsanız sorunu aşağıdaki adımlarla çözmeyi deneyin:

1. Anahtar Zinciri Erişimi'ni açın ve sistem anahtar zincirini seçin.

2. Localhost sertifikası olup olmadığını denetleyin.

3. Sertifikanın, tüm kullanıcılar için sertifikanın güvenilir olduğunu gösteren artı (+) simgesini simgede gösterdiğini onaylayın.

4. Sertifikayı sistem anahtarlığından kaldırın.

5. Aşağıdaki komutları çalıştırın:

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

6. Açık tarayıcı örneklerini kapatın ve uygulamayı yeni bir tarayıcı penceresinde açın.

Visual Studio'da sertifika sorunlarını giderme hakkında daha fazla bilgi için bkz.: GitHub dotnet/aspnetcore sorunu #16892) - IIS Express kullanırken HTTPS hatası.

Linux - sertifika güvenilir değil

Linux çalıştırıyorsanız güvenilmeyen sertifika sorunlarını gidermek için şu adımları izleyin:

1. Araştırdığınız sertifikanın sunucu tarafından Kestrel kullanılması planlanan kullanıcı HTTPS geliştirici sertifikası olduğunu onaylayın.

2. Geçerli kullanıcı varsayılan HTTPS geliştirici Kestrel sertifikasını aşağıdaki konumda denetleyin.

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

   HTTPS geliştirici Kestrel sertifikası dosyası SHA1 parmak izidir. Dosya komutuyla dotnet dev-certs https --clean silindiğinde, farklı bir parmak iziyle gerektiğinde dosya yeniden oluşturulur.

3. Aşağıdaki komutu çalıştırarak dışarı aktarılan sertifika eşleşmelerinin parmak izini doğrulayın:

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

   Sertifika parmak izi eşleşmiyorsa aşağıdaki koşulları araştırın:

   • Sertifikanın eski olup olmadığını denetleyin.

   • Sertifikanın kök kullanıcı için dışarı aktarılan bir geliştirici sertifikası olup olmadığını denetleyin.

     • Bu durumda, sertifikayı dışarı aktarın.

4. Aşağıdaki klasörde kök kullanıcı sertifikasını denetleyin:

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

Visual Studio ile kullanılan IIS Express SSL sertifikası

IIS Express sertifikasıyla ilgili sorunları gidermek için Visual Studio yükleyicisinde Repair öğesini seçin. Daha fazla bilgi için bkz. GitHub dotnet/aspnetcore sorunu #16892) - HTTPS IIS Express kullanılırken hata oluştu.

Grup ilkesi otomatik olarak imzalanan sertifikalara güvenmeyi engeller

Bazı durumlarda, grup ilkesi otomatik olarak imzalanan sertifikaların güvenilir olmasını engelleyebilir. Daha fazla bilgi için bkz. GitHub dotnet/aspnetcore sorunu #21173 - HTTPS geliştirici sertifikasına güvenme hatası.

İlgili içerik

• ASP.NET Core'u ara sunucular ve yük dengeleyicilerle çalışacak şekilde yapılandırma
• Nginx ile Linux'ta ASP.NET Core Barındırma: HTTPS yapılandırması
• IIS 7 veya sonraki sürümlerde SSL'i ayarlama
• Web sunucusu için Kestrel uç noktaları yapılandırma
• OWASP HSTS tarayıcı desteği