クライアントで HTTPS を適用 ASP.NET Core

作成者: Rick Anderson

このドキュメントでは、次の方法を示します。

  • すべての要求に HTTPS を要求します。
  • すべての HTTP 要求を HTTPS にリダイレクトします。

API を使用すると、クライアントが最初の要求で機密データを送信するのを防ぐ必要があります。

警告

API プロジェクト

機密情報 受け取る Web API では RequireHttpsAttribute を使用しません。 RequireHttpsAttribute は HTTP 状態コードを使用して、ブラウザーを HTTP から HTTPS にリダイレクトします。 API クライアントは、HTTP から HTTPS へのリダイレクトを理解または従わない場合があります。 このようなクライアントは、HTTP を使用して情報を送信できます。 Web API では、次のいずれかを行う必要があります。

  • HTTP でリッスンしない。
  • 状態コード 400 (Bad Request) を使用して接続を閉じ、要求を処理しない。

API で HTTP リダイレクトを無効にするには、環境変数を ASPNETCORE_URLS 設定するか、コマンド ライン --urls フラグを使用します。 詳細については、Andrew Lock によるアプリの URL を設定する 5 つの ASP.NET Core で複数の環境を使用する ASP.NET Coreを参照してください。

HSTS プロジェクトと API プロジェクト

HSTS は一般にブラウザー専用の命令なので、既定の API プロジェクトには HSTS は含め "されません"。 電話アプリやデスクトップ アプリなどの他の呼び出し元は、 指示に 従わない。 ブラウザー内でも、HTTP を使用した API への認証された 1 回の呼び出しは、セキュリティで保護されていないネットワーク上のリスクを伴います。 セキュリティで保護されたアプローチは、HTTPS 経由でのみリッスンして応答するように API プロジェクトを構成することです。

警告

API プロジェクト

機密情報 受け取る Web API では RequireHttpsAttribute を使用しません。 RequireHttpsAttribute は HTTP 状態コードを使用して、ブラウザーを HTTP から HTTPS にリダイレクトします。 API クライアントは、HTTP から HTTPS へのリダイレクトを理解または従わない場合があります。 このようなクライアントは、HTTP を使用して情報を送信できます。 Web API では、次のいずれかを行う必要があります。

  • HTTP でリッスンしない。
  • 状態コード 400 (Bad Request) を使用して接続を閉じ、要求を処理しない。

HTTPS を必須にする

Web アプリの実稼働環境 ASP.NET Core使用することをお勧めします。

  • HTTP 要求を HTTPS にリダイレクトする HTTPS リダイレクト ミドルウェア ( UseHttpsRedirection )。
  • HSTS ミドルウェア (UseHsts) を使用して、HTTP Strict Transport Security Protocol (HSTS) ヘッダーをクライアントに送信します。

注意

リバース プロキシ構成でデプロイされたアプリを使用すると、プロキシで接続セキュリティ (HTTPS) を処理できます。 プロキシが HTTPS リダイレクトも処理する場合は、HTTPS リダイレクト ミドルウェアを使用する必要はありません。 プロキシ サーバーが HSTS ヘッダーの書き込み (IIS 10.0 (1709)以降でのネイティブ HSTS サポートなど) も処理する場合、HSTS ミドルウェアはアプリで必要ありません。 詳細については、「プロジェクト作成時の HTTPS/HSTS のオプトアウト」を参照してください

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 。 この方法は、リバース プロキシのデプロイでは機能しません。

  • 開発時に、 で HTTPS URL をlaunchsettings.js します。 アプリケーションが使用されている場合IIS Express HTTPS を有効にする。

  • サーバーまたはサーバーの公開エッジ展開用に HTTPS URL Kestrel エンドポイントをHTTP.sys します。 アプリ で使用される HTTPS ポート は 1 つのみです。 ミドルウェアは、 を介してポートを検出します IServerAddressesFeature

注意

アプリがリバース プロキシ構成で実行されている場合、 IServerAddressesFeature は使用できません。 このセクションで説明する他の方法のいずれかを使用して、ポートを設定します。

Edge の展開

または がHTTP.sysエッジ サーバーとして使用されている場合、または両方でリッスンするようにHTTP.sysを構成 Kestrel Kestrel する必要がある場合。

  • クライアントがリダイレクトされるセキュリティで保護されたポート (通常、実稼働環境では 443、開発時は 5001)。
  • セキュリティで保護されていないポート (通常、実稼働では 80、開発では 5000)。

アプリが安全でない要求を受信し、クライアントをセキュリティで保護されたポートにリダイレクトするには、セキュリティで保護されていないポートにクライアントがアクセスできる必要があります。

詳細については、「エンドポイントの構成 Kestrel 」または「 」を参照してください ASP.NET Core での HTTP.sys Web サーバーの実装

デプロイメント シナリオ

クライアントとサーバーの間のファイアウォールでも、トラフィック用に通信ポートが開いている必要があります。

要求がリバース プロキシ構成で転送される場合は、HTTPS リダイレクト ミドルウェアを呼び出す前に 転送 ヘッダー ミドルウェアを使用します。 Forwarded Headers Middleware は、 ヘッダーを使用 Request.Scheme して を更新 X-Forwarded-Proto します。 ミドルウェアを使用すると、リダイレクト URI や他のセキュリティ ポリシーを正しく動作できます。 Forwarded Headers Middleware を使用しない場合、バックエンド アプリは正しいスキームを受け取らない可能性があります。その結果、リダイレクト ループが発生する可能性があります。 一般的なエンド ユーザー エラー メッセージは、リダイレクトが多すぎるというエラー メッセージが表示されます。

アプリケーションにデプロイAzure App Service、「チュートリアル: 既存のカスタム SSL 証明書を Azure Web Apps にバインドする」のガイダンス に従います

オプション

次の強調表示されているコードでは 、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 を送信します。 アプリが非開発環境にあるときに永続的なリダイレクト状態コードを送信する場合は、非開発環境の条件付きチェックでミドルウェア オプションの構成をラップします。

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

Startup.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 リダイレクト ミドルウェア ( ) を使用する代わりに、URL 書き換えミドルウェア ( ) UseHttpsRedirection を使用することもできます AddRedirectToHttpsAddRedirectToHttps では、リダイレクトの実行時に状態コードとポートを設定できます。 詳細については 、「URL 書き換えミドルウェア」を参照してください

追加のリダイレクト規則を必要とせずに HTTPS にリダイレクトする場合は、このトピックで説明する HTTPS リダイレクト ミドルウェア ( UseHttpsRedirection ) を使用することをお勧めします。

HTTP Strict Transport Security Protocol (HSTS)

OWASPごとに、HTTP Strict Transport Security (HSTS)は、応答ヘッダーを使用して Web アプリによって指定されるオプトイン セキュリティ拡張機能です。 HSTS をサポートするブラウザーが次のヘッダーを受け取る場合:

  • ブラウザーには、HTTP を使用した通信の送信を妨げるドメインの構成が格納されます。 ブラウザーは、HTTPS 経由のすべての通信を強制的に行います。
  • ブラウザーでは、信頼されていない証明書または無効な証明書をユーザーが使用できない。 ブラウザーは、ユーザーがこのような証明書を一時的に信頼できるプロンプトを無効にします。

HSTS はクライアントによって適用されるので、いくつかの制限があります。

  • クライアントは HSTS をサポートする必要があります。
  • HSTS では、HSTS ポリシーを確立するために、少なくとも 1 つの成功した 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.MaxAge を小さな値 TimeSpan に設定します。 HTTPS インフラストラクチャを HTTP に戻す必要がある場合は、時間の値を 1 日以下に設定します。 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仕様の一部ではなく、Web ブラウザーでサポートされ、新しいインストール時に HSTS サイトを事前読み込みできます。 詳細については、「https://hstspreload.org/」を参照してください。
  • includeSubDomain を有効にし、HSTS ポリシーをホスト サブドメインに適用します。
  • ヘッダーの パラメーター max-age を明示的に Strict-Transport-Security 60 日に設定します。 設定されていない場合、既定値は 30 日です。 詳細については 、max-age ディレクティブ に関するページを参照してください
  • 除外 example.com するホストの一覧に を追加します。

UseHsts では、次のループバック ホストが除外されます。

  • localhost : IPv4 ループバック アドレス。
  • 127.0.0.1 : IPv4 ループバック アドレス。
  • [::1] : IPv6 ループバック アドレス。

プロジェクト作成時の HTTPS/HSTS のオプトアウト

ネットワークの公開エッジで接続セキュリティが処理されるバックエンド サービスのシナリオによっては、各ノードで接続セキュリティを構成する必要はありません。 テンプレートから生成された Web アプリは、Visual Studio dotnet newコマンドから生成され、HTTPS リダイレクトHSTS を有効にします。 これらのシナリオを必要としないデプロイの場合は、テンプレートからアプリを作成するときに HTTPS/HSTS をオプトアウトできます。

HTTPS/HSTS をオプトアウトするには:

[HTTPS 用 に構成する] チェック ボックスを オフにします。

[Https ASP.NET Core構成する] チェック ボックスがオフの [Web アプリケーションの新しい構成] ダイアログ。

[Https ASP.NET Core構成する] チェック ボックスがオフの [Web アプリケーションの新しい構成] ダイアログ。

ASP.NET Core macOS で HTTPS 開発証明書を信頼Windowsする

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 ツールを実行する 1 回の手順を実行 dev-certs します。

dotnet dev-certs https --trust

次のコマンドにより、dev-certs ツールに関するヘルプが表示されます。

dotnet dev-certs https --help

警告

コンテナー イメージや仮想マシンなど、再配布される環境で開発証明書を作成しない。 これにより、なりすましや特権の昇格につながる可能性があります。 これを防ぐには、.NET CLI を初めて呼び出す前に、 環境変数を に DOTNET_GENERATE_ASPNET_CERTIFICATE false 設定します。 これにより、CLI の初回実行時に、ASP.NET Core証明書の自動生成がスキップされます。

Firefox で HTTPS 証明書を信頼して、エラーが発生SEC_ERROR_INADEQUATE_KEY_USAGEします

Firefox ブラウザーでは独自の証明書ストアが使用されるため、証明書または開発者IIS Express Kestrel 信頼されません。

Firefox で HTTPS 証明書を信頼する方法、ポリシー ファイルを作成する方法、または FireFox ブラウザーを使用して構成する方法は 2 種類があります。 ブラウザーを使用して を構成するとポリシー ファイルが作成されます。そのため、2 つの方法は同等です。

Firefox で HTTPS 証明書を信頼するポリシー ファイルを作成する

次の場所にポリシー ファイルを作成します。

Firefox ポリシー ファイルに次の JSON を追加します。

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

前のポリシー ファイルは、証明書ストア内の信頼された証明書からの Firefox 信頼証明書Windowsします。 次のセクションでは、Firefox ブラウザーを使用して、前のポリシー ファイルを作成する別の方法を示します。

Firefox ブラウザーを使用して HTTPS 証明書の信頼を構成する

security.enterprise_roots.enabled = true の手順を使用して を設定します。

  1. about:configFireFox ブラウザーで「」と入力します。
  2. リスクを 受け入れる場合は、[リスクを受け入れて 続行する] を選択します。
  3. [すべて 表示] を選択します
  4. 設定 security.enterprise_roots.enabled = true
  5. Firefox を終了して再起動する

詳細については 、「Firefox での証明書機関 (CA) の設定」と mozilla/policy-templates/READMEファイルを参照してください。

Docker の開発者証明書を設定する方法

こちらの GitHub のイシューを参照してください。

Ubuntu は、サービス間通信用の証明書を信頼します

  1. OpenSSL 1.1.1h 以降をインストールします。 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 証明書を信頼する

信頼の確立はブラウザー固有です。 以下のセクションでは、ブラウザー Edge および Chrome および firefox Chromiumの手順について説明します。

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 に固有のパスです。 その他のディストリビューションの場合は、適切なパスを選択するか、証明書機関 (CA) のパスを使用します。 証明書をフォルダーにエクスポートするには、管理者特権のアクセス許可が必要な場合 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 に固有のパスです。 その他のディストリビューションの場合は、適切なパスを選択するか、証明書機関 (CA) のパスを使用します。

  • に次の内容を含む JSON /usr/lib/firefox/distribution/policies.json ファイルを作成します。

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

ブラウザー を使用してポリシー ファイルを構成する 別の方法については、このドキュメントの「Firefox ブラウザーを使用して HTTPS 証明書の信頼を構成する」を参照してください。

Fedora 34 で証明書を信頼する

このコメントをGitHubしてください

証明書を他のディストリビューションと信頼する

こちらの GitHub のイシューを参照してください。

クライアントから HTTPS 証明書を信頼Linux 用 Windows サブシステム

このLinux 用 Windows サブシステム (WSL) は、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 ディストリビューションごとに 1 回の操作です。 証明書をエクスポートするよりも簡単です。 Windows で証明書を更新または再生成する場合は、上記のコマンドを再度実行する必要があります。

証明書が信頼されていないなどの証明書の問題のトラブルシューティング

このセクションでは、HTTPS 開発証明書 ASP.NET Coreがインストールされ、信頼されているが、証明書が信頼されていないというブラウザーの警告がまだ存在する場合に役立ちます。 HTTPS ASP.NET Core証明書は によって使用されます 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 フォルダーを削除 します。
  • ソリューションをクリーンアップします。 bin フォルダーと obj フォルダーを削除します。
  • 開発ツールを再起動します。 たとえば、Visual Studio、Visual Studio Code、または Visual Studio for Mac。

Windows - 証明書が信頼されていない

  • 証明書ストアで証明書を確認します。 と の両方の localhost 下に、表示 ASP.NET Core HTTPS development certificate 名を持つ証明書が必要 Current User > Personal > Certificates です。 Current User > Trusted root certification authorities > Certificates
  • 見つかったすべての証明書を、個人用ルート証明機関と信頼されたルート証明機関の両方から削除します。 localhost 証明書のIIS Express削除しない。
  • 次のコマンドを実行します。
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

開いているブラウザー インスタンスを閉じます。 アプリに対して新しいブラウザー ウィンドウを開きます。

証明書の問題のトラブルシューティングについては、「IIS Express を使用した HTTPS エラー (dotnet/AspNetCore #16892)」を参照Visual Studio。

IIS ExpressVISUAL STUDIO で使用される SSL Visual Studio

証明書のインストールに関する問題をIIS Express、新しいインストーラーから [修復] をVisual Studioします。 詳細については、次を参照してください。この GitHub の問題します。

関連情報