ASP.NET Core에서 HTTPS 적용

작성자: Rick Anderson

이 문서에서는 다음을 수행 하는 방법을 보여 줍니다.

  • 모든 요청에 대해 HTTPS를 요구 합니다.
  • 모든 HTTP 요청을 HTTPS로 리디렉션합니다.

API가 없으면 클라이언트가 첫 번째 요청에서 중요 한 데이터를 전송 하지 못할 수 있습니다.

경고

API 프로젝트

중요 한 정보를 수신 하는 웹 Api에 RequireHttpsAttribute 를 사용 하지 마세요. RequireHttpsAttribute http 상태 코드를 사용 하 여 브라우저를 HTTP에서 HTTPS로 리디렉션합니다. API 클라이언트는 HTTP에서 HTTPS로의 리디렉션을 인식 하거나 준수 하지 않을 수 있습니다. 이러한 클라이언트는 HTTP를 통해 정보를 보낼 수 있습니다. 웹 Api는 다음 중 하나를 수행 해야 합니다.

  • HTTP에서 수신 하지 않습니다.
  • 상태 코드 400 (잘못 된 요청)이 포함 된 연결을 닫고 요청을 제공 하지 않습니다.

API에서 HTTP 리디렉션을 사용 하지 않도록 설정 하려면 ASPNETCORE_URLS 환경 변수를 설정 하거나 --urls 명령줄 플래그를 사용 합니다. 자세한 내용은 ASP.NET Core에서 여러 환경 사용 Andrew Lock에서 ASP.NET Core 앱에 대 한 url을 설정 하는 및 5 가지 방법 을 참조 하세요.

HSTS 및 API 프로젝트

HSTS는 일반적으로 브라우저 전용 명령 이므로 기본 API 프로젝트는 Hsts 를 포함 하지 않습니다. 전화 또는 데스크톱 앱과 같은 다른 호출자는 지침을 따르지 않습니다 . 브라우저 내 에서도 HTTP를 통한 API에 대 한 인증 된 단일 호출은 안전 하지 않은 네트워크에서 위험이 있습니다. 안전한 방법은 HTTPS를 통해서만 수신 대기 하 고 응답 하도록 API 프로젝트를 구성 하는 것입니다.

경고

API 프로젝트

중요 한 정보를 수신 하는 웹 Api에 RequireHttpsAttribute 를 사용 하지 마세요. RequireHttpsAttribute http 상태 코드를 사용 하 여 브라우저를 HTTP에서 HTTPS로 리디렉션합니다. API 클라이언트는 HTTP에서 HTTPS로의 리디렉션을 인식 하거나 준수 하지 않을 수 있습니다. 이러한 클라이언트는 HTTP를 통해 정보를 보낼 수 있습니다. 웹 Api는 다음 중 하나를 수행 해야 합니다.

  • HTTP에서 수신 하지 않습니다.
  • 상태 코드 400 (잘못 된 요청)이 포함 된 연결을 닫고 요청을 제공 하지 않습니다.

HTTPS 필요

프로덕션 ASP.NET Core 웹 앱을 사용 하는 것이 좋습니다.

  • Https 리디렉션 미들웨어 ( UseHttpsRedirection )-HTTP 요청을 https로 리디렉션합니다.
  • 클라이언트에 HSTS (HTTP Strict Transport Security Protocol) 헤더를 전송 하는 HSTS 미들웨어 (Usehsts)

참고

역방향 프록시 구성에 배포 된 앱을 통해 프록시가 연결 보안 (HTTPS)을 처리할 수 있습니다. 프록시가 HTTPS 리디렉션을 처리 하는 경우에는 HTTPS 리디렉션 미들웨어를 사용할 필요가 없습니다. 또한 프록시 서버에서 HSTS 헤더 쓰기를 처리 하는 경우 (예: IIS 10.0 (1709) 이상에서 기본 hsts 지원) 앱에 Hsts 미들웨어가 필요 하지 않습니다. 자세한 내용은 프로젝트를 만들 때 HTTPS/HSTS 옵트아웃 (Opt out)을 참조 하세요.

UseHttpsRedirection

클래스에서를 호출 하는 코드는 다음과 UseHttpsRedirection Startup 같습니다.

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();
    });
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

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

    app.UseMvc();
}

앞에서 강조 표시 된 코드:

영구 리디렉션이 아닌 임시 리디렉션을 사용 하는 것이 좋습니다. 링크 캐싱은 개발 환경에서 불안정한 동작을 일으킬 수 있습니다. 앱이 개발 환경에 있지 않은 경우 영구 리디렉션 상태 코드를 보내려면 프로덕션에서 영구 리디렉션 구성 섹션을 참조 하세요. Hsts 를 사용 하 여 보안 리소스 요청만 앱에 전송 되어야 한다는 것을 클라이언트에 알리는 것이 좋습니다 (프로덕션 환경 에서만).

포트 구성

미들웨어가 안전 하지 않은 요청을 HTTPS로 리디렉션하는 데 포트를 사용할 수 있어야 합니다. 포트를 사용할 수 없는 경우:

  • HTTPS로의 리디렉션이 발생 하지 않습니다.
  • 미들웨어는 "리디렉션을 위한 https 포트를 결정 하지 못했습니다." 경고를 기록 합니다.

다음 방법 중 하나를 사용 하 여 HTTPS 포트를 지정 합니다.

  • https_port 호스트 설정을다음과 같이 설정 합니다.

    • 호스트 구성에서.

    • ASPNETCORE_HTTPS_PORT환경 변수를 설정 합니다.

    • 에서 최상위 항목을 추가 하 여 appsettings.json 다음을 수행 합니다.

      {
          "https_port": 443,
          "Logging": {
              "LogLevel": {
                  "Default": "Information",
                  "Microsoft": "Warning",
                  "Microsoft.Hosting.Lifetime": "Information"
              }
          },
          "AllowedHosts": "*"
      }
      
  • ASPNETCORE_URLS 환경 변수를 사용 하 여 보안 체계가 있는 포트를 표시 합니다. 환경 변수는 서버를 구성 합니다. 미들웨어는를 통해 HTTPS 포트를 간접적으로 검색 합니다 IServerAddressesFeature . 이 방법은 역방향 프록시 배포에서 작동 하지 않습니다.

  • https_port 호스트 설정을다음과 같이 설정 합니다.

    • 호스트 구성에서.

    • ASPNETCORE_HTTPS_PORT환경 변수를 설정 합니다.

    • 에서 최상위 항목을 추가 하 여 appsettings.json 다음을 수행 합니다.

      {
          "https_port": 443,
          "Logging": {
              "LogLevel": {
                  "Default": "Warning"
              }
          },
          "AllowedHosts": "*"
      }
      
  • ASPNETCORE_URLS 환경 변수를 사용 하 여 보안 체계가 있는 포트를 표시 합니다. 환경 변수는 서버를 구성 합니다. 미들웨어는를 통해 HTTPS 포트를 간접적으로 검색 합니다 IServerAddressesFeature . 이 방법은 역방향 프록시 배포에서 작동 하지 않습니다.

  • 개발에서 launchsettings.js 의 HTTPS URL을 설정 합니다. IIS Express 사용 하는 경우 HTTPS를 사용 하도록 설정 합니다.

  • Kestrel서버 또는 HTTP.sys 서버의 공용에 지 배포에 대 한 HTTPS URL 끝점을 구성 합니다. 앱에서 HTTPS 포트 를 하나만 사용 합니다. 미들웨어는를 통해 포트를 검색 합니다 IServerAddressesFeature .

참고

앱이 역방향 프록시 구성에서 실행 되는 경우에는를 IServerAddressesFeature 사용할 수 없습니다. 이 섹션에 설명 된 다른 방법 중 하나를 사용 하 여 포트를 설정 합니다.

Edge 배포

Kestrel또는 HTTP.sys를 공용에 지 서버로 사용 Kestrel 하거나 HTTP.sys에서 수신 대기 하도록 구성 해야 합니다.

  • 클라이언트가 리디렉션되는 보안 포트 (일반적으로 프로덕션의 경우 443, 개발 중인 경우 5001)
  • 안전 하지 않은 포트 (일반적으로 프로덕션의 경우 80, 개발에서 5000)

응용 프로그램이 안전 하지 않은 요청을 받고 클라이언트를 보안 포트로 리디렉션하도록 클라이언트에서 보안 되지 않은 포트에 액세스할 수 있어야 합니다.

자세한 내용은 Kestrel 끝점 구성 또는을 참조 하세요 ASP.NET Core에서 HTTP.sys 웹 서버 구현 .

배포 시나리오

클라이언트와 서버 간의 모든 방화벽에는 트래픽에 대 한 통신 포트도 열려 있어야 합니다.

역방향 프록시 구성에서 요청을 전달 하는 경우 HTTPS 리디렉션 미들웨어를 호출 하기 전에 전달 된 헤더 미들웨어 를 사용 합니다. 전달 된 헤더 미들웨어는 Request.Scheme 헤더를 사용 하 여를 업데이트 합니다 X-Forwarded-Proto . 미들웨어는 리디렉션 Uri 및 기타 보안 정책이 제대로 작동 하도록 허용 합니다. 전달 된 헤더 미들웨어를 사용 하지 않는 경우 백엔드 앱은 올바른 체계를 수신 하지 않고 리디렉션 루프에서 종료 될 수 있습니다. 일반적인 최종 사용자 오류 메시지는 너무 많은 리디렉션이 발생 한 것입니다.

Azure App Service에 배포할 때 자습서: Azure Web Apps에 기존 사용자 지정 SSL 인증서 바인딩의 지침을 따릅니다.

옵션

다음 강조 표시 된 코드는 AddHttpsRedirection 을 호출 하 여 미들웨어 옵션을 구성 합니다.

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;
    });
}
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

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

AddHttpsRedirection또는의 값을 변경 하는 경우에만를 호출 해야 HttpsPort RedirectStatusCode 합니다.

앞에서 강조 표시 된 코드:

프로덕션 환경에서 영구 리디렉션 구성

미들웨어는 기본적으로 모든 리디렉션을 사용 하 여 Status307TemporaryRedirect 를 보냅니다. 앱이 개발 환경에 있지 않은 경우 영구 리디렉션 상태 코드를 보내려면 비 개발 환경에 대 한 조건부 검사에서 미들웨어 옵션 구성을 래핑합니다.

시작 .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;
        });
    }
}

시작 .cs 에서 서비스를 구성 하는 경우:

public void ConfigureServices(IServiceCollection services)
{
    // IHostingEnvironment (stored in _env) is injected into the Startup class.
    if (!_env.IsDevelopment())
    {
        services.AddHttpsRedirection(options =>
        {
            options.RedirectStatusCode = (int) HttpStatusCode.MovedPermanently;
            options.HttpsPort = 443;
        });
    }
}

HTTPS 리디렉션 미들웨어 대체 방법

HTTPS 리디렉션 미들웨어 ()를 사용 하 UseHttpsRedirection 는 대신 URL 재작성 미들웨어 ()를 사용할 수 AddRedirectToHttps 있습니다. AddRedirectToHttps 리디렉션이 실행 될 때 상태 코드 및 포트를 설정할 수도 있습니다. 자세한 내용은 URL 재작성 미들웨어를 참조 하세요.

추가 리디렉션 규칙을 요구 하지 않고 HTTPS로 리디렉션하는 경우 UseHttpsRedirection 이 항목에서 설명 하는 Https 리디렉션 미들웨어 ()를 사용 하는 것이 좋습니다.

HTTP HSTS (Strict Transport Security Protocol)

OWASP에 따라 hsts (HTTP Strict Transport security) 는 응답 헤더를 사용 하 여 웹 앱에서 지정 하는 옵트인 (opt in) 보안 기능입니다. HSTS를 지 원하는 브라우저가 이 헤더를 수신 하는 경우:

  • 브라우저는 HTTP를 통한 통신 전송을 방지 하는 도메인에 대 한 구성을 저장 합니다. 브라우저는 HTTPS를 통한 모든 통신을 강제로 수행 합니다.
  • 브라우저는 사용자가 신뢰할 수 없거나 유효 하지 않은 인증서를 사용 하지 못하도록 합니다. 브라우저는 사용자가 이러한 인증서를 일시적으로 신뢰할 수 있도록 하는 프롬프트를 사용 하지 않도록 설정 합니다.

HSTS는 클라이언트에 의해 적용 되므로 다음과 같은 몇 가지 제한 사항이 있습니다.

  • 클라이언트는 HSTS를 지원 해야 합니다.
  • HSTS는 HSTS 정책을 설정 하기 위해 하나 이상의 성공한 HTTPS 요청이 필요 합니다.
  • 응용 프로그램은 모든 HTTP 요청을 확인 하 고 HTTP 요청을 리디렉션하거나 거부 해야 합니다.

ASP.NET Core 2.1 이상에서는 확장 메서드를 사용 하 여 hsts를 구현 UseHsts 합니다. 다음 코드는 UseHsts 앱이 개발 모드가아닐 때를 호출 합니다.

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();
    });
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

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

    app.UseMvc();
}

UseHsts HSTS 설정은 브라우저에서 매우 캐시할 수 있으므로 개발에는 권장 되지 않습니다. 기본적으로는 UseHsts 로컬 루프백 주소를 제외 합니다.

처음으로 HTTPS를 구현 하는 프로덕션 환경의 경우 메서드 중 하나를 사용 하 여 초기 HstsOptions 를 작은 값으로 설정 합니다. TimeSpan HTTPS 인프라를 HTTP로 되돌려야 하는 경우에는 값을 하루에 한 번 이상으로 설정 해야 합니다. HTTPS 구성의 유지 가능성을 확신 하는 경우 HSTS 값을 늘립니다 max-age . 일반적으로 사용 되는 값은 1 년입니다.

코드는 다음과 같습니다.

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;
    });
}
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    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;
    });
}
  • 헤더의 미리 로드 매개 변수를 설정 합니다 Strict-Transport-Security . 프리 로드는 RFC hsts 사양의일부가 아니지만 웹 브라우저가 새로 설치 시 hsts 사이트를 미리 로드 하도록 지원 합니다. 자세한 내용은 https://hstspreload.org/을(를) 참조하세요.
  • 도메인을 호스트 하는 데 HSTS 정책을 적용 하는 Includesubdomain 도메인을 사용 하도록 설정 합니다.
  • max-age헤더의 매개 변수를 60 일로 명시적으로 설정 Strict-Transport-Security 합니다. 설정 되지 않은 경우 기본값은 30 일입니다. 자세한 내용은 최대 기간 지시문을 참조 하세요.
  • example.com제외할 호스트 목록에를 추가 합니다.

UseHsts 다음 루프백 호스트를 제외 합니다.

  • localhost : IPv4 루프백 주소입니다.
  • 127.0.0.1 : IPv4 루프백 주소입니다.
  • [::1] : IPv6 루프백 주소입니다.

프로젝트를 만들 때 HTTPS/HSTS 옵트아웃 (Opt out)

네트워크의 공용 가장자리에서 연결 보안이 처리 되는 일부 백 엔드 서비스 시나리오에서는 각 노드에서 연결 보안을 구성할 필요가 없습니다. Visual Studio 또는 dotnet new 명령에서 템플릿에서 생성 된 웹 앱은 HTTPS 리디렉션과 hsts를 사용 하도록 설정 합니다. 이러한 시나리오가 필요 하지 않은 배포의 경우 템플릿에서 앱을 만들 때 HTTPS/HSTS를 옵트아웃 (opt out) 할 수 있습니다.

HTTPS/HSTS를 옵트아웃 (opt out) 하려면:

HTTPS에 대해 구성 확인란의 선택을 취소 합니다.

HTTPS에 대해 구성 확인란의 선택을 취소 한 새 ASP.NET Core 웹 응용 프로그램 대화 상자

HTTPS에 대해 구성 확인란의 선택을 취소 한 새 ASP.NET Core 웹 응용 프로그램 대화 상자

Windows 및 macos에서 ASP.NET Core HTTPS 개발 인증서를 신뢰 합니다.

Firefox 브라우저의 경우 다음 섹션을 참조 하세요.

.NET Core SDK에는 HTTPS 개발 인증서가 포함 되어 있습니다. 인증서는 첫 실행 환경의 일부로 설치 됩니다. 예를 들어는 dotnet --info 다음 출력의 변형을 생성 합니다.

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 Core SDK를 설치하면 로컬 사용자 인증서 저장소에 ASP.NET Core HTTPS 개발 인증서가 설치됩니다. 인증서가 설치 되었지만 트러스트 되지 않았습니다. 인증서를 신뢰 하려면 dotnet 도구를 실행 하는 일회성 단계를 수행 합니다 dev-certs .

dotnet dev-certs https --trust

다음 명령은 dev-certs 도구에 대한 도움말을 제공합니다.

dotnet dev-certs https --help

경고

컨테이너 이미지 또는 가상 머신과 같이 재배포할 환경에서 개발 인증서를 만들지 마세요. 이렇게 하면 스푸핑 및 권한 상승이 발생할 수 있습니다. 이를 방지 하려면 DOTNET_GENERATE_ASPNET_CERTIFICATE 처음으로 .NET CLI를 호출 하기 전에 환경 변수를로 설정 false 합니다. 이렇게 하면 CLI의 첫 실행 환경에서 ASP.NET Core 개발 인증서의 자동 생성을 건너뜁니다.

SEC_ERROR_INADEQUATE_KEY_USAGE 오류를 방지 하기 위해 Firefox를 사용 하 여 HTTPS 인증서 신뢰

Firefox 브라우저는 자체 인증서 저장소를 사용 하므로 IIS Express 또는 개발자 인증서를 신뢰 하지 않습니다 Kestrel .

Firefox를 사용 하 여 HTTPS 인증서를 신뢰 하는 방법에는 두 가지가 있습니다. 정책 파일을 만들거나 FireFox 브라우저를 사용 하 여를 구성 합니다. 브라우저를 사용 하 여 구성 하면 정책 파일이 만들어지므로 두 가지 방법이 동일 합니다.

Firefox를 사용 하 여 HTTPS 인증서를 신뢰 하는 정책 파일 만들기

다음 위치에서 정책 파일을 만듭니다.

Firefox 정책 파일에 다음 JSON을 추가 합니다.

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

위의 정책 파일은 Windows 인증서 저장소에 있는 신뢰할 수 있는 인증서의 Firefox 신뢰 인증서를 만듭니다. 다음 섹션에서는 Firefox 브라우저를 사용 하 여 이전 정책 파일을 만드는 다른 방법을 제공 합니다.

Firefox 브라우저를 사용 하 여 HTTPS 인증서 신뢰 구성

security.enterprise_roots.enabled = true 다음 지침을 사용 하 여 설정 합니다.

  1. about:configFireFox 브라우저에서를 입력 합니다.
  2. 위험에 동의 하 고 위험을 수락 하는 경우 계속을 선택 합니다.
  3. 모두 표시 선택
  4. 설정 security.enterprise_roots.enabled = true
  5. Firefox 종료 및 다시 시작

자세한 내용은 Firefox에서 ca (인증 기관) 설정mozilla/정책-템플릿/추가 정보 파일을 참조 하세요.

Docker 용 개발자 인증서를 설정 하는 방법

GitHub 문제를 참조하세요.

Ubuntu는 서비스 간 통신을 위한 인증서를 신뢰 합니다.

  1. OpenSSL 1.1.1 h 이상 버전을 설치 합니다. OpenSSL를 업데이트 하는 방법에 대 한 지침은 배포를 참조 하세요.

  2. 다음 명령을 실행합니다.

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

이전 명령의 경로는 Ubuntu에만 해당 됩니다. 다른 배포의 경우 적절 한 경로를 선택 하거나 Ca (인증 기관)에 대 한 경로를 사용 합니다.

Linux에서 HTTPS 인증서 신뢰

신뢰 설정은 브라우저 마다 다릅니다. 다음 섹션에서는 Chromium 브라우저 Edge와 Chrome 및 Firefox에 대 한 지침을 제공 합니다.

Edge 또는 Chrome을 사용 하 여 Linux에서 HTTPS 인증서 신뢰

Linux의 chromium 브라우저:

  • 배포를 위한를 설치 합니다 libnss3-tools .

  • $HOME/.pki/nssdb컴퓨터에 폴더가 있는지 확인 합니다.

  • 다음 명령을 통해 인증서를 내보냅니다.

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

    이전 명령의 경로는 Ubuntu에만 적용됩니다. 다른 배포의 경우 적절한 경로를 선택하거나 인증 기관(AS)의 경로를 사용합니다. 인증서를 폴더로 내보내려면 상승된 권한이 필요할 수 ca-certificates 있습니다.

  • 다음 명령을 실행합니다.

    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
    
  • 브라우저를 종료하고 다시 시작합니다.

Linux에서 Firefox를 통해 인증서 신뢰

  • 다음 명령을 통해 인증서를 내보냅니다.

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

    이전 명령의 경로는 Ubuntu에만 적용됩니다. 다른 배포의 경우 적절한 경로를 선택하거나 인증 기관(AS)의 경로를 사용합니다.

  • 에서 다음 내용이 있는 JSON 파일을 /usr/lib/firefox/distribution/policies.json 만듭니다.

    {
        "policies": {
            "Certificates": {
                "Install": [
                    "/usr/local/share/ca-certificates/aspnet/https.crt"
                ]
            }
        }
    }
    

브라우저를 사용하여 정책 파일을 구성하는 다른 방법은 이 문서의 Firefox 브라우저를 사용하여 HTTPS 인증서 신뢰 구성을 참조하세요.

Fedora 34를 통해 인증서 신뢰

이 GitHub 주석을참조하세요.

다른 배포판과 인증서 신뢰

GitHub 문제를 참조하세요.

Linux용 Windows 하위 시스템 HTTPS 인증서 신뢰

WSL(Linux용 Windows 하위 시스템)은 HTTPS 자체 서명된 개발 인증서를 생성합니다. WSL 인증서를 신뢰하도록 Windows 인증서 저장소를 구성하려면 다음을 수행합니다.

  • 개발자 인증서를 Windows 파일로 내보냅니다.

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

    여기서 $CREDENTIAL_PLACEHOLDER$ 는 암호입니다.

  • WSL 창에서 내보낸 인증서를 WSL 인스턴스에서 가져옵니다.

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

앞의 방법은 인증서 및 WSL 배포당 한 번 작업입니다. 인증서를 반복해서 내보내는 것보다 쉽습니다. 창에서 인증서를 업데이트하거나 다시 생성할 경우 이전 명령을 다시 실행해야 할 수 있습니다.

신뢰할 수 없는 인증서와 같은 인증서 문제 해결

이 섹션에서는 ASP.NET Core HTTPS 개발 인증서가 설치되고 신뢰할 수있는 경우 도움말을 제공하지만 인증서를 신뢰할 수 없다는 브라우저 경고가 여전히 표시됩니다. ASP.NET Core HTTPS 개발 인증서는 에서 Kestrel 사용됩니다.

IIS Express 인증서를 복구하려면 이 Stackoverflow 문제를 참조하세요.

모든 플랫폼 - 신뢰할 수 없는 인증서

다음 명령을 실행합니다.

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

열려 있는 브라우저 인스턴스를 닫습니다. 앱에 대한 새 브라우저 창을 엽니다. 인증서 신뢰는 브라우저에서 캐시됩니다.

dotnet dev-certs https --clean Fails

위의 명령은 대부분의 브라우저 신뢰 문제를 해결합니다. 브라우저가 여전히 인증서를 신뢰하지 않는 경우 다음 플랫폼별 제안을 따릅니다.

Docker - 신뢰할 수 없는 인증서

  • C:\Users { USER}\AppData\Roaming\ASP.NET\Https 폴더를 삭제합니다.
  • 솔루션을 정리합니다. binobj 폴더를 삭제합니다.
  • 개발 도구를 다시 시작합니다. 예를 들어 Visual Studio, Visual Studio Code 또는 Mac용 Visual Studio.

Windows - 신뢰할 수 없는 인증서

  • 인증서 저장소에서 인증서를 확인합니다. 및 아래에 이름이 모두 있는 인증서가 있어야 합니다. localhost ASP.NET Core HTTPS development certificate Current User > Personal > Certificates``Current User > Trusted root certification authorities > Certificates
  • 개인 및 신뢰할 수 있는 루트 인증 기관에서 찾은 모든 인증서를 제거합니다. IIS Express localhost 인증서를 제거하지 마십시오.
  • 다음 명령을 실행합니다.
dotnet dev-certs https --clean
dotnet dev-certs https --trust

열려 있는 브라우저 인스턴스를 닫습니다. 앱에 대한 새 브라우저 창을 엽니다.

OS X - 신뢰할 수 없는 인증서

  • KeyChain Access를 엽니다.
  • 시스템 키 체인을 선택합니다.
  • localhost 인증서가 있는지 확인합니다.
  • 아이콘에 기호가 포함되어 있는지 + 확인하여 모든 사용자에 대해 신뢰할 수 있음을 나타냅니다.
  • 시스템 키 체인에서 인증서를 제거합니다.
  • 다음 명령을 실행합니다.
dotnet dev-certs https --clean
dotnet dev-certs https --trust

열려 있는 브라우저 인스턴스를 닫습니다. 앱에 대한 새 브라우저 창을 엽니다.

Visual Studio 인증서 문제를 해결하려면 IIS Express(dotnet/AspNetCore #16892)를 사용하는 HTTPS 오류를 참조하세요.

IIS Express Visual Studio 사용하는 SSL 인증서

IIS Express 인증서 문제를 해결하려면 Visual Studio 설치 관리자에서 복구를 선택합니다. 자세한 내용은 이 GitHub 이슈를 참조하세요.

추가 정보