ASP.NET Core で HTTPS を適用する

作成者 David Galvan、Rick Anderson

HTTPS/TLS を使用するように ASP.NET Core アプリに受信要求を強制するには、次の手順を実行します。

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

API を使って、クライアントが最初の要求で機密データを送信しないようにすることはできません。

この記事では、HTTPS/TLS を要求するように ASP.NET Core アプリを構成する方法、または HTTP 要求を HTTPS/TLS にリダイレクトして安全な対話を行う方法について説明します。 信頼されていない証明書の問題を解決するためのトラブルシューティング手順は、さまざまなプラットフォームで提供されています。

API プロジェクト

Web API を使用するプロジェクトでは、次のいずれかを行う必要があります。

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

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

Warning

機密情報を受け取る Web API では、 をRequireHttpsAttributeでください。 RequireHttpsAttribute では HTTP 状態コードを使って、ブラウザーを HTTP から HTTPS にリダイレクトします。 API クライアントは、HTTP から HTTPS へのリダイレクトを理解したり従ったりしないことがあり、HTTP 経由で情報を送信する可能性があります。

HSTS と API プロジェクト

HTTP Strict Transport Security Protocol (HSTS) のセキュリティで保護されたアプローチは、HTTPS 経由でのみリッスンして応答するように API プロジェクトを構成することです。

Warning

既定の API プロジェクトには HSTS は含まれません。これは通常、ブラウザーのみの命令であるためです。 電話アプリやデスクトップ アプリなどの他の呼び出し元は、その命令に従いません。 ブラウザー内でも、HTTP 経由の 1 回の認証済み API 呼び出しには、セキュリティで保護されていないネットワークのリスクが伴います。

HTTP から HTTPS へのリダイレクト（CORS プリフライト リクエストで ERR_INVALID_REDIRECT が発生）

HTTP を使用するエンドポイントへの要求が、 UseHttpsRedirection メソッドを使用して HTTPS にリダイレクトされると、CORS プレフライト要求で ERR_INVALID_REDIRECT エラーが発生してリダイレクトが失敗します。

API プロジェクトでは、 UseHttpsRedirection メソッドを使用して HTTPS に要求をリダイレクトするのではなく、HTTP 要求を拒否できます。

HTTPS が必要

運用 ASP.NET Core Web アプリの場合は、次の方法をお勧めします。

• HTTP 要求を HTTPS にリダイレクトするには、HTTPS リダイレクト ミドルウェア (UseHttpsRedirection) を使用します。

• HSTS ヘッダーをクライアントに送信するには、 UseHsts メソッドを使用して HSTS ミドルウェアを使用します。

Note

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

UseHttpsRedirection

次のコードは、Program.cs ファイル内の UseHttpsRedirection メソッドを呼び出します。

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

上記の強調表示されたコードでは:

• HttpsRedirectionOptions.RedirectStatusCode コードで既定のStatus307TemporaryRedirect プロパティを使用します。
• HttpsRedirectionOptions.HttpsPort環境変数またはASPNETCORE_HTTPS_PORTによってオーバーライドされない限り、既定のIServerAddressesFeature プロパティ (null を渡す) を使用します。

推奨される方法は、永続的なリダイレクトではなく一時的なリダイレクトを使用することです。 リンク キャッシュを使用すると、開発環境で不安定な動作が発生する可能性があります。 アプリが非Development 環境にあるときに永続的なリダイレクト状態コードを送信する場合は、「 運用環境での永続的なリダイレクトの構成」 セクションを参照してください。 HSTS を使用して、セキュリティで保護されたリソース要求のみを (運用環境でのみ) アプリに送信する必要があることをクライアントに通知します。

ポートの構成

セキュリティで保護されていない要求を HTTPS にリダイレクトするために、ミドルウェアでポートを使用できるようにする必要があります。 使用可能なポートがない場合:

• HTTPS へのリダイレクトは行われません。
• ミドルウェアは、 リダイレクト用の https ポートを決定できませんでしたという警告をログに記録します。

次のいずれかの方法を使用して HTTPS ポートを指定します。

• HttpsRedirectionOptions.HttpsPort を設定します。

• 次の方法で https_portホスト設定を設定します。

  • ホスト構成中

  • ASPNETCORE_HTTPS_PORT 環境変数を設定する。

  • appsettings.json ファイルに最上位のエントリを追加します。

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

• ASPNETCORE_URLS環境変数を使用して、セキュリティで保護されたスキームを持つポートを示します。 この環境変数によってサーバーを構成します。 ミドルウェアでは、IServerAddressesFeature を介して間接的に HTTPS ポートを検出します。 この方法は、リバース プロキシ展開では機能しません。

• ASP.NET Core Web テンプレートは、 と IIS Express の両方に対して、Kestrel ファイルに HTTPS URL を設定します。 launchsettings.json ファイルは、ローカル コンピューターでのみ使用されます。

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

Note

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

エッジデプロイメント

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

• クライアントがリダイレクトされるセキュリティで保護されたポート (通常、運用環境では 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にデプロイする場合は、 Azure App Service。

オプション

次の強調表示されたコードは、ミドルウェア オプションを構成するために 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();

AddHttpsRedirection の呼び出しは、HttpsPort または RedirectStatusCode の値を変更する場合にのみ必要です。

上記の強調表示されたコードでは:

• HttpsRedirectionOptions.RedirectStatusCode プロパティをStatus307TemporaryRedirectコードに設定します。これは既定値です。 StatusCodes への代入に RedirectStatusCode クラスのフィールドを使います。
• HTTPS ポートを 5001 に設定します。

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

ミドルウェアは既定で、すべてのリダイレクトを含む Status307TemporaryRedirect コードを送信します。 アプリが非Development 環境にあるときに永続的なリダイレクト状態コードを送信する場合は、ミドルウェア オプションの構成を、Development 以外の環境の条件付きチェックでラップします。

次のコードは、 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 リダイレクト ミドルウェアの代わりとなる方法

HTTPS リダイレクト ミドルウェア ( UseHttpsRedirection メソッド) を使用する代わりに、( AddRedirectToHttps メソッドを使用して) URL リライト ミドルウェアを使用します。 AddRedirectToHttps でも、リダイレクトが実行されるときの状態コードとポートを設定できます。 詳細については、URL リライト ミドルウェアに関するページをご覧ください。

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

HTTP Strict Transport Security プロトコル (HSTS)

OWASP ごとに、HSTS は、応答ヘッダーを介して Web アプリによって指定されるオプトイン セキュリティ強化です。 HSTS をサポートするブラウザーがこのヘッダーを受け取ると、次のようになります。

• ブラウザーに、HTTP 経由の通信を送信できないようにするドメインの構成が保存されます。 ブラウザーでは、すべての通信が強制的に HTTPS 経由で実行されます。
• ブラウザーによって、ユーザーが信頼されていない証明書や無効な証明書を使えなくなります。 ユーザーがそのような証明書を一時的に信頼できるようにするプロンプトがブラウザーで無効になります。

クライアントは HSTS を適用するため、いくつかの制限があります。

• クライアントで HSTS がサポートされている必要があります。
• HSTS では、HSTS ポリシーを確立するために、少なくとも 1つの成功した HTTPS 要求が必要です。
• アプリケーションではすべての HTTP 要求をチェックし、その HTTP 要求をリダイレクトまたは拒否する必要があります。

ASP.NET Core では、UseHsts 拡張メソッドを使って HSTS が実装されます。 次のコードでは、アプリがUseHstsでない場合に を呼び出します。

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 は開発環境では推奨されません。HSTS の設定はブラウザーによって高度にキャッシュ可能であるためです。 既定で、UseHsts ではローカル ループバック アドレスが除外されます。

HTTPS を初めて実装する運用環境では、HstsOptions.MaxAgeメソッドのいずれかを使用して、初期TimeSpanプロパティ値を少量に設定します。 HTTPS インフラストラクチャを HTTP に戻す必要がある場合は、時間から 1 日以下に値を設定します。 HTTPS 構成の持続可能性に自信を持ったら、HSTS max-age 値 (通常は 1 年) を増やします。

以下の強調表示されたコードでは、次のようにします。

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 ヘッダーのプリロード パラメーターを設定します。 プリロードは RFC 6797 HSTS 仕様の一部ではありません。 Web ブラウザーでは、新規インストール時の HSTS サイトのプリロードがサポートされます。 詳細については、「https://hstspreload.org/」を参照してください。
• HSTS ポリシーをホスト サブドメインに適用する includeSubDomain ディレクティブを有効にします。 詳細については、 RFC 6797 HSTS 仕様 (セクション 6.1.2) を参照してください。
• max-age ヘッダーの Strict-Transport-Security パラメーターを明示的に 60 日に設定します。 設定しない場合、既定値は 30 日です。 詳細については、max-age の ディレクティブを参照してください。
• 除外するホストの一覧に example.com を追加します。

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

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

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

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

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

Visual Studio

新しい ASP.NET Core Web アプリを作成するときに、Configure for HTTPS オプションの選択を解除します。

Visual Studioの [Create a new ASP.NET Core Web application]\(新しい ASP.NET Core Web アプリケーションの作成\) ダイアログと、選択されていない [Configure for HTTPS]\(HTTPS の構成\)

.NET CLI

--no-https コマンドで dotnet new webapp オプションを使用します。次に例を示します。

dotnet new webapp --no-https

ASP.NET Core の HTTPS 開発証明書を信頼する

.NET 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 SDK をインストールすると、ASP.NET Core HTTPS 開発証明書がローカル ユーザー証明書ストアにインストールされます。 証明書はインストールされていますが、信頼されていません。 証明書を信頼するには、dotnet dev-certs ツールを実行する 1 回限りの手順を実行します。

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

Warning

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

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

Docker の開発者証明書を構成するには、GitHub dotnet/aspnetcore.docs の問題 #6199 - 開発時に開発証明書を設定する方法を参照してください。

Linux 固有の考慮事項

Linux ディストリビューションは、証明書を信頼済みとしてマークする方法が大きく異なります。

dotnet dev-certsツールは広く適用されることが予想されますが、公式サポートは Ubuntu と Fedora でのみ利用できます。 このサポートは、Firefox および Chromium ベースのブラウザー (Microsoft Edge、Chrome、Chromium) への信頼を確保することを特に目的としています。

Dependencies

• OpenSSL の信頼を確立するには、openssl ツールがパス上にある必要があります。
• ブラウザーの信頼 (Microsoft Edge や Firefox など) を確立するには、certutil ツールがパス上にある必要があります。

OpenSSL の信頼

ASP.NET Core開発証明書が信頼されると、証明書は現在のユーザーのホーム ディレクトリ内のフォルダーにエクスポートされます。 OpenSSL (およびそれを使用するクライアント) がこのフォルダーを取得できるようにするには、SSL_CERT_DIR 環境変数を設定する必要があります。 1 つのセッションで変数を設定するには、 export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs などのコマンドを実行するか ( --verbose が渡されたときに正確な値が出力に含まれます)、または (ディストリビューションとシェル固有の) 構成ファイル ( .profile など) を追加します。

この方法は、開発証明書を信頼 curl などのツールを作成するために必要です。 または、個々の-CAfile呼び出しに-CApathまたはcurlを渡すことができます。

Note

使用しているメジャー バージョンに応じて、1.1.1h 以降または 3.0.0 以降が必要です。

OpenSSL の信頼が正しくない状態になる場合 (たとえば、 dotnet dev-certs https --clean が削除に失敗した場合)、 c_rehash ツールを使用して状況を頻繁に解決できます。

Overrides

独自のネットワーク セキュリティ サービス (NSS) ストアで別のブラウザーを使用している場合は、 DOTNET_DEV_CERTS_NSSDB_PATHS 環境変数を使用して、NSS ディレクトリのコロン区切りのリスト (たとえば、 cert9.dbを含むディレクトリ) を指定できます。 その後、開発証明書の場所を変数の一覧に追加できます。

OpenSSL で信頼する証明書を特定のディレクトリに格納する場合は、 DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY 環境変数を使用して証明書の場所を示すことができます。

Warning

いずれかの変数を設定する場合は、信頼が更新されるたびに必ず同じ値を設定してください。 値が変更された場合、ツールは以前の場所の証明書について認識しません (たとえば、証明書のクリーンアップ中)。

sudo の使用

他のプラットフォームと同様に、開発証明書はユーザーごとに個別に保存され、信頼されます。

dotnet dev-certsを (たとえば、sudoを使用して) 別のユーザーとして実行する場合、その特定のユーザー (root など) は開発証明書を信頼します。

linux-dev-certs を使って Linux で HTTPS 証明書を信頼する

linux-dev-certs は、コミュニティでサポートされているオープン ソースの .NET グローバル ツールであり、Linux で開発者の証明書を作成して信頼するための便利な方法を提供します。 Microsoftはツールを維持またはサポートしません。

次のコマンドは、このツールをインストールし、信頼できる開発者証明書を作成します。

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

詳細について、または問題を報告するには、linux-dev-certs GitHub リポジトリを参照してください。

SUSE Linux Enterprise Server (SLES Linux)

構成に SUSE Linux Enterprise Server が含まれている場合は、GitHub dotnet/aspnetcore.docs の問題 #28292 - SLES 上のTRUST HTTPS 証明書を参照してください。

証明書の問題のトラブルシューティング (証明書が信頼されていません)

ASP.NET Core HTTPS 開発証明書がインストールされ、信頼されている場合、ブラウザーは証明書が信頼されていないことを警告します。 次のセクションでは、この問題のトラブルシューティングに役立ちます。

ASP.NET Core の HTTPS 開発証明書は Kestrel によって使われます。

IIS Express 証明書を修復するには、「 スタック オーバーフローの問題 #20036984/answer #20048613 - 不足している IIS Express SSL 証明書を復元するにはどうすればよいですか?

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

すべてのプラットフォームで、次の手順で信頼されていない証明書の問題を解決してみてください。

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

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

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

   ブラウザー キャッシュには、証明書が信頼されているかどうかを格納します。 閉じる/開くプロセスは、証明書のブラウザー キャッシュ設定を更新するのに役立ちます。

dotnet dev-certs httpsコマンドは、通常、ほとんどのブラウザー信頼の問題を解決します。 dotnet dev-certs https --clean コマンドが失敗してもブラウザーが証明書を信頼しない場合は、次のセクションでプラットフォーム固有の推奨事項を試してください。

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

Docker を使用している場合は、次の手順で問題を解決してみてください。

1. C:\Users{USER}\AppData\Roaming\ASP.NET\Https フォルダーを削除します。

2. ソリューションをクリーンアップします。 bin フォルダーと obj フォルダーを削除します。

3. 開発ツールを再起動します。 たとえば、Visual Studio、Visual Studio Code。

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

Windowsで作業している場合は、次のトラブルシューティング手順を実行します。

1. 証明書ストア内の証明書を確認します。 localhost フレンドリ名を持つ ASP.NET Core HTTPS development certificate 証明書を 2 つのフォルダーで探します。

   • 現在のユーザー > 個人用 > 証明書
   • 現在のユーザー > 信頼されたルート証明機関 > 証明書

2. 個人用証明機関と信頼されたルート証明機関の両方からすべての証明書を削除します。

   Important

   IIS Express localhost 証明書は削除しないでください。

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

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

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

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

OS X を使用している場合は、次の手順で問題を解決してみてください。

1. KeyChain Access を開き、システム キーチェーンを選択します。

2. localhost 証明書の存在を確認します。

3. アイコンにプラス記号 (+) が表示されていることを確認します。これは、証明書がすべてのユーザーに対して信頼されていることを示します。

4. システム キーチェーンからその証明書を削除します。

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

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

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

Visual Studioでの証明書の問題のトラブルシューティングの詳細については、GitHub dotnet/aspnetcore 問題 #16892) - IIS Express を使用したHTTPS エラーを参照してください。

Linux - 証明書が信頼されていません

Linux を実行している場合は、次の手順に従って、信頼されていない証明書のトラブルシューティングを行います。

1. 調査中の証明書が、 Kestrel サーバーで使用する予定のユーザー HTTPS 開発者証明書であることを確認します。

2. 現在のユーザーの既定の HTTPS 開発者 Kestrel 証明書を次の場所で確認します。

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

   HTTPS 開発者 Kestrel 証明書ファイルは SHA1 サムプリントです。 dotnet dev-certs https --clean コマンドを使用してファイルを削除すると、必要に応じて別の拇印でファイルが再生成されます。

3. 次のコマンドを実行して、エクスポートされた証明書の拇印が一致していることを確認します。

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

   証明書の拇印が一致しない場合は、次の条件を調べます。

   • 証明書が古いかどうかを確認します。

   • 証明書がルート ユーザーのエクスポートされた開発者証明書であるかどうかを確認します。

     • その場合は、証明書をエクスポートします。

4. 次のフォルダーにあるルート ユーザー証明書を確認します。

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

Visual Studio で使われる IIS Express SSL 証明書

IIS Express 証明書の問題を解決するには、Visual Studio インストーラーで Repair を選択します。 詳細については、「GitHub dotnet/aspnetcore 問題 #16892) - IIS Express を使用したHTTPS エラーを参照してください。

グループ ポリシーによって自己署名証明書が信頼されないようにする

場合によっては、グループ ポリシーによって自己署名証明書が信頼されない場合があります。 詳細については、GitHub dotnet/aspnetcore の問題 #21173 - HTTPS 開発者証明書を信頼しているエラーを参照してください。

関連するコンテンツ

• プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する
• Nginx を使った Linux での ASP.NET Core のホスト: HTTPS 構成
• IIS 7 以降で SSL を設定する
• Kestrel Web サーバーのエンドポイントを構成する
• OWASP HSTS ブラウザー サポート