ASP.NET Core に HTTPS を適用する

作成者: 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 コマンドラインフラグを使用します。 詳細については、「」 ASP.NET Core で複数の環境を使用する および 5 つの方法で ASP.NET Core アプリの Url を Andrew Lock で設定する方法に 関する説明を参照してください。

HSTS と API プロジェクト

HSTS は一般にブラウザー専用の命令であるため、既定の API プロジェクトには Hsts は含まれません。 電話やデスクトップアプリなどの他の呼び出し元は、命令に従い ません 。 ブラウザー内でも、HTTP 経由の API に対して認証された単一の呼び出しにより、セキュリティで保護されていないネットワークに対するリスクが生じます。 セキュリティで保護された方法は、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 では次のものを使用することをお勧めします。

  • UseHttpsRedirectionHTTP 要求を https にリダイレクトする Https リダイレクトミドルウェア ()。
  • 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 ます。 リバースプロキシの展開では、この方法は使用できません。

  • 開発では、 launchsettings.js で HTTPS URL を設定します。 IIS Express が使用されている場合は、HTTPS を有効にします。

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

注意

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

Edge の展開

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

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

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

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

デプロイメント シナリオ

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

リバースプロキシ構成で要求が転送される場合は、HTTPS リダイレクトミドルウェアを呼び出す前に、転送された ヘッダーミドルウェア を使用します。 転送されたヘッダーミドルウェアは、 Request.Scheme ヘッダーを使用してを更新し X-Forwarded-Proto ます。 ミドルウェアは、リダイレクト Uri とその他のセキュリティポリシーを正しく動作させることを許可します。 転送ヘッダーミドルウェアが使用されていない場合、バックエンドアプリは正しいスキームを受信せず、リダイレクトループで終了する可能性があります。 一般的なエンドユーザーエラーメッセージは、リダイレクトされた回数が多すぎることを示しています。

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

前の強調表示されているコード:

  • HttpsRedirectionOptions をに設定し ますStatus307TemporaryRedirect これは既定値です。 への割り当てには、クラスのフィールドを使用し StatusCodes RedirectStatusCode ます。
  • HTTPS ポートを5001に設定します。

運用環境での永続的なリダイレクトの構成

ミドルウェアは既定で、すべてのリダイレクトを含む 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 構成する] チェック ボックスがオフになっていることを示す [新しいコア Web アプリケーション] ダイアログ。

[https ASP.NET 構成する] チェック ボックスがオフになっていることを示す [新しいコア Web アプリケーション] ダイアログ。

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 開発証明書がインストールされます。 証明書はインストールされましたが、信頼されていません。 証明書を信頼するには、1 回の手順を実行して dotnet ツールを実行 dev-certs します。

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

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

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

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

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/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 証明書を信頼する

信頼の確立はブラウザー固有です。 次のセクションでは、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 に固有のパスです。 その他のディストリビューションの場合は、適切なパスを選択するか、証明書機関 (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 コメントを参照してください。

Windows Subsystem for Linux からの HTTPS 証明書を信頼する

Windows Subsystem For Linux (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 で証明書を更新または再生成する場合は、上記のコマンドをもう一度実行する必要があります。

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

このセクションでは ASP.NET Core の HTTPS 開発証明書がインストールされ、 信頼されているが、証明書が信頼されていないことを示すブラウザーの警告が表示される場合に役立つ情報を提供します。 ASP.NET Core HTTPS 開発証明書は、によって使用され Kestrel ます。

IIS Express 証明書を修復するには、 この Stackoverflow の問題を参照してください。

すべてのプラットフォーム-信頼されていない証明書

次のコマンドを実行します。

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

開いているすべてのブラウザーインスタンスを閉じます。 新しいブラウザーウィンドウを開いてアプリを開きます。 証明書の信頼は、ブラウザーによってキャッシュされます。

dotnet の開発-証明書 https--クリーンに失敗する

上記のコマンドは、ほとんどのブラウザーの信頼の問題を解決します。 ブラウザーがまだ証明書を信頼していない場合は、次のプラットフォーム固有の提案に従ってください。

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
  • 個人証明書と信頼されたルート証明機関の両方から、検出されたすべての証明書を削除します。 IIS Express localhost 証明書 は削除しないでください。
  • 次のコマンドを実行します。
dotnet dev-certs https --clean
dotnet dev-certs https --trust

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

OS X-信頼されていない証明書

  • キーチェーンアクセスを開きます。
  • システムキーチェーンを選択します。
  • 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 の問題のページを参照してください。

追加情報