ASP.NET Core で HTTPS を適用する

  • [アーティクル]

作成者 David Galvan、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 で複数の環境を使用する」と Andrew Lock による「8 ways to set the URLs for an ASP.NET Core app (ASP.NET Core のアプリの URL を設定する 8 つの方法)」を参照してください。

HSTS と API プロジェクト

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

HTTPS への HTTP リダイレクトにより、CORS プレフライト要求で、ERR_INVALID_REDIRECT が発生する

UseHttpsRedirection による、HTTPS にリダイレクトされる HTTP を使用するエンドポイントへの要求は、ERR_INVALID_REDIRECT on the CORS preflight request で失敗します。

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

HTTPS を必須にする

運用環境の ASP.NET Core Web アプリでは、次を使うことをお勧めします。

  • HTTP 要求を HTTPS にリダイレクトするための、HTTPS リダイレクト ミドルウェア (UseHttpsRedirection)。
  • HTTP Strict Transport Security プロトコル (HSTS) ヘッダーをクライアントに送信するための、HSTS ミドルウェア (UseHsts)。

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

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

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

ポート構成

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

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

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

  • HttpsRedirectionOptions.HttpsPort を設定します。

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

    • ホストの構成で。

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

    • appsettings.json に最上位レベルのエントリを追加する。

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

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

  • ASP.NET Core Web テンプレートにより、Kestrel と IIS Express の両方の Properties/launchsettings.json に HTTPS URL が設定されます。 launchsettings.json は、ローカル コンピューターでのみ使用されます。

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

Note

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

Edge の展開

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

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

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

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

展開シナリオ

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

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

Azure App Service に展開する場合、「チュートリアル: 既存のカスタム SSL 証明書を Azure Web Apps にバインドする」のガイダンスに従ってください。

オプション

次の強調表示されているコードでは、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 の値を変更する場合にのみ必要です。

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

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

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

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) を使う代わりに、URL リライト ミドルウェア (AddRedirectToHttps) を使うこともできます。 AddRedirectToHttps でも、リダイレクトが実行されるときの状態コードとポートを設定できます。 詳細については、URL リライト ミドルウェアに関するページをご覧ください。

リダイレクト規則を追加せずに HTTPS にリダイレクトする場合は、このトピックで説明されている HTTPS Redirection Middleware (UseHttpsRedirection) を使用することをお勧めします。

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

OWASP によると、HTTP Strict Transport Security (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 を実装する運用環境では、いずれかの TimeSpan メソッドを使って、最初の HstsOptions.MaxAge を小さい値に設定してください。 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 HSTS 仕様の一部ではありませんが、Web ブラウザーでは、新規インストール時に HSTS サイトのプリロードを行うことがサポートされています。 詳細については、「https://hstspreload.org/」を参照してください。
  • includeSubDomain を有効にします。これにより、HSTS ポリシーがホスト サブドメインに適用されます。
  • Strict-Transport-Security ヘッダーの max-age パラメーターを明示的に 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 をオプトアウトするには:

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

New ASP.NET Core Web Application dialog showing the Configure for HTTPS checkbox unselected.

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

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 証明書を信頼するには 2 つの方法があります。ポリシー ファイルを作成する方法と、FireFox ブラウザーを使って構成する方法です。 ブラウザーを使って構成するとポリシー ファイルが作成されるため、2 つの方法は等価です。

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

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

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

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

上記のポリシー ファイルにより、Windows 証明書ストアの信頼できる証明書からの証明書が Firefox で信頼されるようになります。 次のセクションでは、Firefox ブラウザーを使って上記のポリシー ファイルを作成する別の方法を示します。

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

次の手順に従って security.enterprise_roots.enabled = true を設定します。

  1. FireFox ブラウザーで「about:config」と入力します。
  2. リスクに同意する場合は、 [危険性を承知の上で使用する] を選びます。
  3. [すべて表示] を選びます
  4. security.enterprise_roots.enabled = true を設定します
  5. Firefox を終了して再起動します

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

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

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

Linux で HTTPS 証明書を信頼する

信頼の確立は、ディストリビューションとブラウザー固有です。 以下のセクションには、人気のあるいくつかのディストリビューションと Chromium ブラウザー(Edge と Chrome)、および Firefox 用の手順が記載されています。

Ubuntu でサービス間通信用の証明書を信頼する

次の手順は、20.04 などの一部の Ubuntu バージョンでは機能できません。 詳細については、GitHub イシュー dotnet/AspNetCore.Docs #23686 を参照してください。

  1. OpenSSL 1.1.1h 以降をインストールします。 OpenSSL の更新方法については、お使いのディストリビューションの指示を参照してください。

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

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

上のコマンドでは以下の操作が行われます。

  • 現在のユーザーの開発者証明書が作成されることを保証します。
  • 現在のユーザーの環境を使用して、ca-certificates フォルダーに必要な昇格されたアクセス許可を持つ証明書をエクスポートします。
  • -E フラグを削除すると、ルート ユーザー証明書がエクスポートされ、必要に応じて生成されます。 新しく生成された各証明書には異なるサムプリントがあります。 ルートとして実行する場合は、sudo と -E は必要ありません。

上記のコマンドに含まれるパスは Ubuntu に固有のものです。 その他のディストリビューションの場合は、適切なパスを選ぶか、証明機関 (CA) のパスを使ってください。

Edge または Chrome を使って Linux で HTTPS 証明書を信頼する

Linux 上の chromium ブラウザーの場合:

  • お使いのディストリビューションの libnss3-tools をインストールします。

  • コンピューター上に $HOME/.pki/nssdb フォルダーを作成するか、存在していることを確認します。

  • 次のコマンドを使って証明書をエクスポートします。

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

    上記のコマンドに含まれるパスは Ubuntu に固有のものです。 その他のディストリビューションの場合は、適切なパスを選ぶか、証明機関 (CA) のパスを使ってください。

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

    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
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM

    上記のコマンドに含まれるパスは Ubuntu に固有のものです。 その他のディストリビューションの場合は、適切なパスを選ぶか、証明機関 (CA) のパスを使ってください。

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

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

注: Ubuntu 21.10 Firefox はスナップ パッケージとして提供され、インストール フォルダーは /snap/firefox/current/usr/lib/firefox です。

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

Fedora 34 で証明書を信頼する

参照トピック

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

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

Linux 用 Windows サブシステムからの HTTPS 証明書を信頼する

次の手順は、Ubuntu 20.04 などの一部の Linux ディストリビューションでは機能しません。 詳細については、GitHub イシュー dotnet/AspNetCore.Docs #23686 を参照してください。

Linux 用 Windows サブシステム (WSL) によって HTTPS 自己署名開発証明書が生成されます。これは、既定では Windows で信頼されません。 Windows で WSL 証明書が信頼されるようにする最も簡単な方法は、Windows と同じ証明書を使用するように WSL を構成することです。

  • Windows 上で、開発者証明書をファイルにエクスポートします。

    dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust

    $CREDENTIAL_PLACEHOLDER$ はパスワードです。

  • WSL ウィンドウで、エクスポートした証明書を WSL インスタンスにインポートします。

    dotnet dev-certs https --clean --import <<path-to-pfx>> --password $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 dev-certs https --clean が失敗する

上記のコマンドによって、ブラウザーの信頼に関するほとんどの問題を解決できます。 証明書がまだブラウザーによって信頼されていない場合は、以下のプラットフォーム固有の推奨事項に従ってください。

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

  • C:\Users{USER}\AppData\Roaming\ASP.NET\Https フォルダーを削除します。
  • ソリューションをクリーンアップします。 bin フォルダーと obj フォルダーを削除します。
  • 開発ツールを再起動します。 たとえば、Visual Studio、Visual Studio Code。

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

  • 証明書ストア内の証明書を確認します。 ASP.NET Core HTTPS development certificate というフレンドリ名を持つ localhost 証明書が、Current User > Personal > Certificates と Current User > Trusted root certification authorities > Certificates の両方に存在するはずです
  • Personal と Trusted の両方のルート証明機関から、見つかったすべての証明書を削除します。 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 での証明書に関する問題のトラブルシューティングについては、「HTTPS Error using IIS Express (IIS Express を使った HTTPS エラー)」 (dotnet/AspNetCore #16892) を参照してください。

Linux 証明書が信頼されていない

信頼するように構成されている証明書が、Kestrel サーバーで使用されるユーザーの HTTPS 開発者証明書であることを確認します。

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

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

HTTPS 開発者 Kestrel 証明書ファイルは SHA1 サムプリントです。 dotnet dev-certs https --clean を使用してファイルを削除すると、別のサムプリントを使用して必要になったときに再生成されます。 次のコマンドを使用して、エクスポートされた証明書のサムプリントが一致することを確認します。

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

証明書が一致しない場合は、次のいずれかの可能性があります。

  • 古い証明書である。
  • ルート ユーザーの開発者証明書がエクスポートされた。 この場合は、証明書をエクスポートします。

ルートユーザー証明書は、次の場所で確認できます。

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

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

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

グループ ポリシーにより、自己署名証明書が信頼されなくなる

場合によっては、グループ ポリシーにより自己署名証明書が信頼されなくなることがあります。 詳細については、次を参照してください。この GitHub の問題します。

追加情報

警告

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 で複数の環境を使用する」と Andrew Lock による「5 ways to set the URLs for an ASP.NET Core app」(ASP.NET Core のアプリの URL を設定する 5 つの方法) を参照してください。

HSTS と API プロジェクト

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

HTTPS を必須にする

運用環境の ASP.NET Core Web アプリでは、次を使うことをお勧めします。

  • HTTP 要求を HTTPS にリダイレクトするための、HTTPS リダイレクト ミドルウェア (UseHttpsRedirection)。
  • HTTP Strict Transport Security プロトコル (HSTS) ヘッダーをクライアントに送信するための、HSTS ミドルウェア (UseHsts)。

Note

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

UseHttpsRedirection

次のコードは、Startup クラスで UseHttpsRedirection を呼び出します。

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

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

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

ポート構成

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

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

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

  • HttpsRedirectionOptions.HttpsPort を設定します。

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

    • ホストの構成で。

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

    • appsettings.json に最上位レベルのエントリを追加する。

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

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

  • 開発時に、launchsettings.json で HTTPS URL を設定します。 IIS Express が使われる場合、HTTPS を有効にします。

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

Note

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

Edge の展開

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

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

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

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

展開シナリオ

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

リバース プロキシ構成で要求が転送される場合は、HTTPS リダイレクト ミドルウェアを呼び出す前に Forwarded Headers Middleware を使用してください。 Forwarded Headers Middleware では、X-Forwarded-Proto ヘッダーを使って、Request.Scheme が更新されます。 このミドルウェアによって、リダイレクト 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;
    });
}

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

HTTPS リダイレクト ミドルウェアの代わりとなる方法

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

リダイレクト規則を追加せずに HTTPS にリダイレクトする場合は、このトピックで説明されている HTTPS Redirection Middleware (UseHttpsRedirection) を使用することをお勧めします。

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

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

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

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

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

ASP.NET Core では、UseHsts 拡張メソッドを使って HSTS が実装されます。 次のコードでは、アプリが開発モードでない場合に 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();
    });
}

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

初めて HTTPS を実装する運用環境では、いずれかの TimeSpan メソッドを使って、最初の HstsOptions.MaxAge を小さい値に設定してください。 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;
    });
}
  • Strict-Transport-Security ヘッダーのプリロード パラメーターを設定します。 プリロードは RFC HSTS 仕様の一部ではありませんが、Web ブラウザーでは、新規インストール時に HSTS サイトのプリロードを行うことがサポートされています。 詳細については、「https://hstspreload.org/」を参照してください。
  • includeSubDomain を有効にします。これにより、HSTS ポリシーがホスト サブドメインに適用されます。
  • Strict-Transport-Security ヘッダーの max-age パラメーターを明示的に 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 をオプトアウトするには:

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

New ASP.NET Core Web Application dialog showing the Configure for HTTPS checkbox unselected.

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

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 証明書を信頼するには 2 つの方法があります。ポリシー ファイルを作成する方法と、FireFox ブラウザーを使って構成する方法です。 ブラウザーを使って構成するとポリシー ファイルが作成されるため、2 つの方法は等価です。

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

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

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

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

上記のポリシー ファイルにより、Windows 証明書ストアの信頼できる証明書からの証明書が Firefox で信頼されるようになります。 次のセクションでは、Firefox ブラウザーを使って上記のポリシー ファイルを作成する別の方法を示します。

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

次の手順に従って security.enterprise_roots.enabled = true を設定します。

  1. FireFox ブラウザーで「about:config」と入力します。
  2. リスクに同意する場合は、 [危険性を承知の上で使用する] を選びます。
  3. [すべて表示] を選びます
  4. security.enterprise_roots.enabled = true を設定します
  5. Firefox を終了して再起動します

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

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

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

Linux で HTTPS 証明書を信頼する

信頼の確立は、ディストリビューションとブラウザー固有です。 以下のセクションには、人気のあるいくつかのディストリビューションと Chromium ブラウザー(Edge と Chrome)、および Firefox 用の手順が記載されています。

Ubuntu でサービス間通信用の証明書を信頼する

  1. OpenSSL 1.1.1h 以降をインストールします。 OpenSSL の更新方法については、お使いのディストリビューションの指示を参照してください。

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

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

上のコマンドでは以下の操作が行われます。

  • 現在のユーザーの開発者証明書が作成されることを保証します。
  • 現在のユーザーの環境を使用して、ca-certificates フォルダーに必要な昇格されたアクセス許可を持つ証明書をエクスポートします。
  • -E フラグを削除すると、ルート ユーザー証明書がエクスポートされ、必要に応じて生成されます。 新しく生成された各証明書には異なるサムプリントがあります。 ルートとして実行する場合は、sudo と -E は必要ありません。

上記のコマンドに含まれるパスは Ubuntu に固有のものです。 その他のディストリビューションの場合は、適切なパスを選ぶか、証明機関 (CA) のパスを使ってください。

Edge または Chrome を使って Linux で HTTPS 証明書を信頼する

Linux 上の chromium ブラウザーの場合:

  • お使いのディストリビューションの libnss3-tools をインストールします。

  • コンピューター上に $HOME/.pki/nssdb フォルダーを作成するか、存在していることを確認します。

  • 次のコマンドを使って証明書をエクスポートします。

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

    上記のコマンドに含まれるパスは Ubuntu に固有のものです。 その他のディストリビューションの場合は、適切なパスを選ぶか、証明機関 (CA) のパスを使ってください。

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

    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
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM

    上記のコマンドに含まれるパスは Ubuntu に固有のものです。 その他のディストリビューションの場合は、適切なパスを選ぶか、証明機関 (CA) のパスを使ってください。

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

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

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

Fedora 34 で証明書を信頼する

Fedora の Firefox

echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js

echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg

echo "{
    \"policies\": {
        \"Certificates\": {
            \"Install\": [
                \"aspnetcore-localhost-https.crt\"
            ]
        }
    }
}" > policies.json

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt
rm localhost.crt

Fedora で dotnet-to-dotnet を信頼する

sudo cp localhost.crt /etc/pki/tls/certs/localhost.pem
sudo update-ca-trust
rm localhost.crt

詳細については、こちらの GitHub のコメントを参照してください。

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

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

Linux 用 Windows サブシステムからの HTTPS 証明書を信頼する

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

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

このセクションでは、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 が失敗する

上記のコマンドによって、ブラウザーの信頼に関するほとんどの問題を解決できます。 証明書がまだブラウザーによって信頼されていない場合は、以下のプラットフォーム固有の推奨事項に従ってください。

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

  • C:\Users{USER}\AppData\Roaming\ASP.NET\Https フォルダーを削除します。
  • ソリューションをクリーンアップします。 bin フォルダーと obj フォルダーを削除します。
  • 開発ツールを再起動します。 たとえば、Visual Studio、Visual Studio Code、または Visual Studio for Mac などです。

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

  • 証明書ストア内の証明書を確認します。 ASP.NET Core HTTPS development certificate というフレンドリ名を持つ localhost 証明書が、Current User > Personal > Certificates と Current User > Trusted root certification authorities > Certificates の両方に存在するはずです
  • Personal と Trusted の両方のルート証明機関から、見つかったすべての証明書を削除します。 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 での証明書に関する問題のトラブルシューティングについては、「HTTPS Error using IIS Express (IIS Express を使った HTTPS エラー)」 (dotnet/AspNetCore #16892) を参照してください。

Linux 証明書が信頼されていない

信頼するように構成されている証明書が、Kestrel サーバーで使用されるユーザーの HTTPS 開発者証明書であることを確認します。

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

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

HTTPS 開発者 Kestrel 証明書ファイルは SHA1 サムプリントです。 dotnet dev-certs https --clean を使用してファイルを削除すると、別のサムプリントを使用して必要になったときに再生成されます。 次のコマンドを使用して、エクスポートされた証明書のサムプリントが一致することを確認します。

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

証明書が一致しない場合は、次のいずれかの可能性があります。

  • 古い証明書である。
  • ルート ユーザーの開発者証明書がエクスポートされた。 この場合は、証明書をエクスポートします。

ルートユーザー証明書は、次の場所で確認できます。

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

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

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

追加情報