ASP.NET Core で HTTPS を適用する

[アーティクル]
11/06/2024

この記事では、次の方法について説明します。

すべての要求に対して 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 を使用するエンドポイントへの要求は、CORS プレフライト要求での ERR_INVALID_REDIRECT で失敗します。

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

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

既定値 HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect) を使います。
ASPNETCORE_HTTPS_PORT 環境変数または IServerAddressesFeature によってオーバーライドされない限り、既定値の HttpsRedirectionOptions.HttpsPort (null) を使います。

永続的なリダイレクトではなく、一時的なリダイレクトを使うことをお勧めします。リンクキャッシュを使用すると、開発環境で不安定な動作が発生する可能性があります。アプリが開発以外の環境にあるときに永続的なリダイレクトの状態コードを送信したい場合は、「運用環境で永続的なリダイレクトを構成する」セクションを参照してください。 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 テンプレートにより、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 の値を変更する場合にのみ必要です。

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

HttpsRedirectionOptions.RedirectStatusCode を Status307TemporaryRedirect (既定値) に設定します。 RedirectStatusCode への代入に StatusCodes クラスのフィールドを使います。
HTTPS ポートを 5001 に設定します。

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

ミドルウェアでは、既定ですべてのリダイレクトで 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 リダイレクトミドルウェア (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 をオプトアウトするには:

Visual Studio
.NET CLI

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

[HTTPS 用の構成] チェックボックスの選択解除を示す新しい ASP.NET Core Web アプリケーションダイアログ。

--no-https オプションを使用します。次に例を示します。

dotnet new webapp --no-https

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

.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

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

dotnet dev-certs https --help

警告

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

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

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

Linux 固有の考慮事項

Linux ディストリビューションは、証明書を信頼済みとしてマークする方法が大きく異なります。 dotnet dev-certs は広く適用されることが期待されていますが、Ubuntu と Fedora でのみ正式にサポートされており、特に Firefox および Chromium ベースのブラウザー (Edge、Chrome、Chromium) への信頼を確保することを目的としています。

依存関係

OpenSSL の信頼を確立するには、openssl ツールがパス上にある必要があります。

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

OpenSSL の信頼

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

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

使用しているメジャーバージョンに応じて、1.1.1h 以降または 3.0.0 以降が必要であることに注意してください。

OpenSSL の信頼が正しくない状態になる場合 (たとえば、dotnet dev-certs https --clean が削除に失敗した場合)、c_rehash ツールを使用して適切に設定できることが多いです。

上書き

独自の Network Security Services (NSS) ストアで別のブラウザーを使用している場合は、DOTNET_DEV_CERTS_NSSDB_PATHS 環境変数を使用して、開発証明書を追加する NSS ディレクトリ (たとえば、cert9.db を含むディレクトリ) のコロン区切りのリストを指定できます。

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

警告

これらの変数のいずれかを設定する場合は、信頼が更新されるたびに同じ値に設定することが重要です。変更された場合、ツールは、たとえば証明書をクリーンアップしようにも、それらの以前の場所を認識しません。

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

こちらの GitHub の issue を参照してください

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

このセクションでは、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 の問題します。

追加情報

Note

.NET 9 SDK 以降を使用している場合は、この記事の .NET 9 バージョンで更新された Linux プロシージャをご覧ください。

警告

API プロジェクト

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

HSTS と API プロジェクト

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

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

HTTPS を必須にする

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

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

Note

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) を使います。
ASPNETCORE_HTTPS_PORT 環境変数または IServerAddressesFeature によってオーバーライドされない限り、既定値の HttpsRedirectionOptions.HttpsPort (null) を使います。

ポート構成

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 テンプレートにより、Kestrel と IIS Express の両方の Properties/launchsettings.json に HTTPS URL が設定されます。 launchsettings.json は、ローカルコンピューターでのみ使用されます。
Kestrel サーバーまたは HTTP.sys サーバーの公開エッジ展開用に HTTPS URL エンドポイントを構成します。 1 つの HTTPS ポートのみがアプリで使用されます。ミドルウェアでは、IServerAddressesFeature を介してポートが検出されます。

Note

Edge の展開

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

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

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

展開シナリオ

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

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 の値を変更する場合にのみ必要です。

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

HttpsRedirectionOptions.RedirectStatusCode を Status307TemporaryRedirect (既定値) に設定します。 RedirectStatusCode への代入に StatusCodes クラスのフィールドを使います。
HTTPS ポートを 5001 に設定します。

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

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

HTTP Strict Transport Security プロトコル (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();

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

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 をオプトアウトする

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

Visual Studio
.NET CLI

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

[HTTPS 用の構成] チェックボックスの選択解除を示す新しい ASP.NET Core Web アプリケーションダイアログ。

--no-https オプションを使用します。次に例を示します。

dotnet new webapp --no-https

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

Firefox ブラウザーについては、次のセクションを参照してください。

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.

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

警告

Firefox で HTTPS 証明書を信頼して SEC_ERROR_INADEQUATE_KEY_USAGE エラーを防止する

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

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

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

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

Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
MacOS: Firefox.app/Contents/Resources/distribution
Linux: この記事の「Linux 上の Firefox で証明書を信頼する」をご覧ください。

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

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

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

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

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

FireFox ブラウザーで「about:config」と入力します。
リスクに同意する場合は、 [危険性を承知の上で使用する] を選びます。
[すべて表示] を選びます
security.enterprise_roots.enabled = true を設定します
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 を参照してください。

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

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

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

ブラウザーを終了して再起動します。

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 証明書の信頼を構成する」をご覧ください。

警告

次の手順は、開発のみを目的としています。運用環境では、次の手順で生成された証明書を使用しないでください。

これらの手順では、Mozilla の "レガシ" ツールである certutil (https://firefox-source-docs.mozilla.org/security/nss/legacy/tools/nss_tools_certutil/index.html) を使用します。最新のユーティリティとプラクティスが検出されると、手順が更新される場合があります。

注意事項

TLS 証明書を不適切に使用すると、スプーフィングにつながるおそれがあります。

ヒント

有効な運用証明書の手順については、RHEL のドキュメントを参照してください。 RHEL8 TLS 証明書 RHEL9 TLS 証明書 RHEL9 証明書システム

依存関係のインストール

dnf install nss-tools

ASP.NET Core 開発証明書をエクスポートする

重要

${ProjectDirectory} をお使いのプロジェクトディレクトリに置き換えます。 ${CertificateName} を、将来識別できる名前に置き換えます。

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

注意事項

git を使用している場合は、${ProjectDirectory}/.gitignore または ${ProjectDirectory}/.git/info/exclude に証明書を追加します。これらのファイルの詳細については、git ドキュメントを参照してください。

ヒント

エクスポートした証明書を Git リポジトリの外部に移動し、次の手順の ${ProjectDirectory} の出現箇所を新しい場所に置き換えることができます。

ASP.NET Core 開発証明書をインポートする

重要

${UserProfile} を使用するプロファイルに置き換えます。 $HOME は、置き換えないでください。これは、ユーザーディレクトリの環境変数です。

Chromium ベースのブラウザー

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Mozilla Firefox

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Curl でテストするエイリアスを作成する

重要

curl を使用してテストする予定の場合は、エクスポートされた証明書を削除しないでください。ご自分の $SHELL のプロファイルでそれを参照するエイリアスを作成する必要があります

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

開発証明書のクリーンアップ

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Note

先ほど作成した curl エイリアスを削除します

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

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

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

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

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

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

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

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

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 証明書

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

追加情報

警告

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 プロジェクト

HTTPS を必須にする

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

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

Note

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

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

既定値 HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect) を使います。
ASPNETCORE_HTTPS_PORT 環境変数または IServerAddressesFeature によってオーバーライドされない限り、既定値の HttpsRedirectionOptions.HttpsPort (null) を使います。

ポート構成

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

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

HttpsRedirectionOptions.HttpsPort を設定します。

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

ホストの構成で。
ASPNETCORE_HTTPS_PORT 環境変数を設定する。

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

Edge の展開

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

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

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

展開シナリオ

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

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 の値を変更する場合にのみ必要です。

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

HttpsRedirectionOptions.RedirectStatusCode を Status307TemporaryRedirect (既定値) に設定します。 RedirectStatusCode への代入に StatusCodes クラスのフィールドを使います。
HTTPS ポートを 5001 に設定します。

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

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

HTTP Strict Transport Security プロトコル (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();
    });
}

コード例を次に示します。

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 をオプトアウトする

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

Visual Studio
.NET CLI

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

[HTTPS 用の構成] チェックボックスが示されている、新しい ASP.NET Core Web アプリテンプレートの追加情報ダイアログ

--no-https オプションを使用します。次に例を示します。

dotnet new webapp --no-https

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

Firefox ブラウザーについては、次のセクションを参照してください。

.NET Core SDK には、HTTPS 開発証明書が含まれています。この証明書は、最初の実行エクスペリエンスの一環としてインストールされます。たとえば、dotnet new webapp を初めて実行すると、次の出力のバリエーションが生成されます。

Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

警告

Firefox で HTTPS 証明書を信頼して SEC_ERROR_INADEQUATE_KEY_USAGE エラーを防止する

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

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

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

Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
MacOS: Firefox.app/Contents/Resources/distribution
Linux: この記事で後出する「Linux 上の Firefox で証明書を信頼する」をご覧ください。

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

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

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

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

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

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

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

Linux で HTTPS 証明書を信頼する

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

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

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

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 は必要ありません。

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

ブラウザーを終了して再起動します。

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

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$
```

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

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

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

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

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

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

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 証明書

追加情報

Note

.NET 9 SDK 以降を使用している場合は、この記事の .NET 9 バージョンで更新された Linux プロシージャをご覧ください。

警告

API プロジェクト

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

HSTS と API プロジェクト

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

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

HTTPS を必須にする

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

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

Note

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) を使います。
ASPNETCORE_HTTPS_PORT 環境変数または IServerAddressesFeature によってオーバーライドされない限り、既定値の HttpsRedirectionOptions.HttpsPort (null) を使います。

ポート構成

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 テンプレートにより、Kestrel と IIS Express の両方の Properties/launchsettings.json に HTTPS URL が設定されます。 launchsettings.json は、ローカルコンピューターでのみ使用されます。
Kestrel サーバーまたは HTTP.sys サーバーの公開エッジ展開用に HTTPS URL エンドポイントを構成します。 1 つの HTTPS ポートのみがアプリで使用されます。ミドルウェアでは、IServerAddressesFeature を介してポートが検出されます。

Note

Edge の展開

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

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

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

展開シナリオ

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

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 の値を変更する場合にのみ必要です。

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

HttpsRedirectionOptions.RedirectStatusCode を Status307TemporaryRedirect (既定値) に設定します。 RedirectStatusCode への代入に StatusCodes クラスのフィールドを使います。
HTTPS ポートを 5001 に設定します。

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

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

HTTP Strict Transport Security プロトコル (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();

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

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 をオプトアウトする

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

Visual Studio
.NET CLI

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

[HTTPS 用の構成] チェックボックスの選択解除を示す新しい ASP.NET Core Web アプリケーションダイアログ。

--no-https オプションを使用します。次に例を示します。

dotnet new webapp --no-https

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

Firefox ブラウザーについては、次のセクションを参照してください。

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.

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

警告

Firefox で HTTPS 証明書を信頼して SEC_ERROR_INADEQUATE_KEY_USAGE エラーを防止する

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

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

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

Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
MacOS: Firefox.app/Contents/Resources/distribution
Linux: この記事の「Linux 上の Firefox で証明書を信頼する」をご覧ください。

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

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

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

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

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

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

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

Linux で HTTPS 証明書を信頼する

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

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

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

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

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 は必要ありません。

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

ブラウザーを終了して再起動します。

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 です。

警告

次の手順は、開発のみを目的としています。運用環境では、次の手順で生成された証明書を使用しないでください。

注意事項

TLS 証明書を不適切に使用すると、スプーフィングにつながるおそれがあります。

ヒント

有効な運用証明書の手順については、RHEL のドキュメントを参照してください。 RHEL8 TLS 証明書 RHEL9 TLS 証明書 RHEL9 証明書システム

依存関係のインストール

dnf install nss-tools

ASP.NET Core 開発証明書をエクスポートする

重要

${ProjectDirectory} をお使いのプロジェクトディレクトリに置き換えます。 ${CertificateName} を、将来識別できる名前に置き換えます。

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

注意事項

ヒント

エクスポートした証明書を Git リポジトリの外部に移動し、次の手順の ${ProjectDirectory} の出現箇所を新しい場所に置き換えることができます。

ASP.NET Core 開発証明書をインポートする

重要

${UserProfile} を使用するプロファイルに置き換えます。 $HOME は、置き換えないでください。これは、ユーザーディレクトリの環境変数です。

Chromium ベースのブラウザー

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Mozilla Firefox

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Curl でテストするエイリアスを作成する

重要

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

開発証明書のクリーンアップ

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Note

先ほど作成した curl エイリアスを削除します

Fedora 34 で証明書を信頼する

参照トピック

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

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

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

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$
```

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

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

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

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

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

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

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

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 証明書

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

追加情報

Note

.NET 9 SDK 以降を使用している場合は、この記事の .NET 9 バージョンで更新された Linux プロシージャをご覧ください。

警告

API プロジェクト

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

HSTS と API プロジェクト

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

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

HTTPS を必須にする

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

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

Note

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) を使います。
ASPNETCORE_HTTPS_PORT 環境変数または IServerAddressesFeature によってオーバーライドされない限り、既定値の HttpsRedirectionOptions.HttpsPort (null) を使います。

ポート構成

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 テンプレートにより、Kestrel と IIS Express の両方の Properties/launchsettings.json に HTTPS URL が設定されます。 launchsettings.json は、ローカルコンピューターでのみ使用されます。
Kestrel サーバーまたは HTTP.sys サーバーの公開エッジ展開用に HTTPS URL エンドポイントを構成します。 1 つの HTTPS ポートのみがアプリで使用されます。ミドルウェアでは、IServerAddressesFeature を介してポートが検出されます。

Note

Edge の展開

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

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

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

展開シナリオ

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

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 の値を変更する場合にのみ必要です。

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

HttpsRedirectionOptions.RedirectStatusCode を Status307TemporaryRedirect (既定値) に設定します。 RedirectStatusCode への代入に StatusCodes クラスのフィールドを使います。
HTTPS ポートを 5001 に設定します。

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

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

HTTP Strict Transport Security プロトコル (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();

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

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 をオプトアウトする

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

Visual Studio
.NET CLI

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

[HTTPS 用の構成] チェックボックスの選択解除を示す新しい ASP.NET Core Web アプリケーションダイアログ。

--no-https オプションを使用します。次に例を示します。

dotnet new webapp --no-https

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

Firefox ブラウザーについては、次のセクションを参照してください。

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.

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

警告

Firefox で HTTPS 証明書を信頼して SEC_ERROR_INADEQUATE_KEY_USAGE エラーを防止する

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

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

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

Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
MacOS: Firefox.app/Contents/Resources/distribution
Linux: この記事の「Linux 上の Firefox で証明書を信頼する」をご覧ください。

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

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

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

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

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

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

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

Linux で HTTPS 証明書を信頼する

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

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

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

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

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

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

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

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

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 は必要ありません。

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

ブラウザーを終了して再起動します。

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 です。

警告

次の手順は、開発のみを目的としています。運用環境では、次の手順で生成された証明書を使用しないでください。

注意事項

TLS 証明書を不適切に使用すると、スプーフィングにつながるおそれがあります。

ヒント

有効な運用証明書の手順については、RHEL のドキュメントを参照してください。 RHEL8 TLS 証明書 RHEL9 TLS 証明書 RHEL9 証明書システム

依存関係のインストール

dnf install nss-tools

ASP.NET Core 開発証明書をエクスポートする

重要

${ProjectDirectory} をお使いのプロジェクトディレクトリに置き換えます。 ${CertificateName} を、将来識別できる名前に置き換えます。

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

注意事項

ヒント

エクスポートした証明書を Git リポジトリの外部に移動し、次の手順の ${ProjectDirectory} の出現箇所を新しい場所に置き換えることができます。

ASP.NET Core 開発証明書をインポートする

重要

${UserProfile} を使用するプロファイルに置き換えます。 $HOME は、置き換えないでください。これは、ユーザーディレクトリの環境変数です。

Chromium ベースのブラウザー

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Mozilla Firefox

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Curl でテストするエイリアスを作成する

重要

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

開発証明書のクリーンアップ

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Note

先ほど作成した curl エイリアスを削除します

Fedora 34 で証明書を信頼する

参照トピック

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

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

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

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$
```

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

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

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

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

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

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

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

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

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

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

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

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

次の方法で共有

ASP.NET Core で HTTPS を適用する

API プロジェクト

HSTS と API プロジェクト

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

HTTPS を必須にする

UseHttpsRedirection

ポート構成

Edge の展開

展開シナリオ

オプション

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

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

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

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

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

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

Linux 固有の考慮事項

依存関係

OpenSSL の信頼

上書き

sudo を使用する

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

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

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

dotnet dev-certs https --clean が失敗する

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

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

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

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

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

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

追加情報

API プロジェクト

HSTS と API プロジェクト

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

HTTPS を必須にする

UseHttpsRedirection

ポート構成

Edge の展開

展開シナリオ

オプション

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

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

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

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

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

Firefox で HTTPS 証明書を信頼して SEC_ERROR_INADEQUATE_KEY_USAGE エラーを防止する

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

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

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

Linux で HTTPS 証明書を信頼する

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

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

Linux 上の Firefox で証明書を信頼する

Fedora 34 で証明書を信頼する

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

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

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

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

dotnet dev-certs https --clean が失敗する

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

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

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

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

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

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

追加情報

API プロジェクト

HSTS と API プロジェクト

HTTPS を必須にする

UseHttpsRedirection

ポート構成

Edge の展開

展開シナリオ

オプション

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

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

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

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

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

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

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

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

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

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

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

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

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