先日 Let's Encript を利用してHTTPS 通信ができるようにしたのを機会に、ホスティングサービスに実装されている IIS の URL Rewrite Module を使って、HTTP で要求が来た場合は 301 Moved Permanently 応答を返して HTTPS にリダイレクトするように設定しました。

ネットで検索してヒットする記事の中では Redirect HTTP to HTTPS with Windows IIS 10 が一番信頼できると思います。実際その通りやって期待通りの結果が得られます。

ですが、自分の Windows 10 PC のローカル IIS で一通りやってみました。さらに、設定がどのような意味を持つかも調べました。調べて分かったことを以下に備忘録として書いておきます。

さらに詳しく知りたい場合は、Microsoft のドキュメント「URL リライト モジュール構成リファレンス」を見ることをお勧めします。日本語版は翻訳がアレなので意味不明なところがあると思います。その場合は英語版を読んでください。

(1) URL Rewrite Module の起動

IIS Manager を起動して書き換えを行うサイトまたはアプリケーションを選び、IIS メニューの［URL Rewrite］をクリックします。

(2) 書き換えルールの追加

画面右側の「操作」欄の下のメニュー［Add Rule(s)...］をクリック。それにより表示された「Add Rule(s)」ダイアログの「Inbound rules」下の「Blank rule」を選択して［OK］ボタンをクリックします。

(3) Match URL セクション

上の「Edit Inbound Rule」画面が表示されます。赤枠で示したように［Name］に任意の名前を入力し、Match URL セクションの［Pattern:］に正規表現 (.*) を入力します。その他はデフォルトで上の画像の通りとなっているはずなので、そのままにしておきます。

設定の意味は、要求 URL が［Pattern:］に設定された正規表現 (.*) にマッチした時に Conditions に設定された条件を調べて、条件が満たされていれば Action の設定に従って処理を行うということです。正規表現 (.*) はどのような URL にもマッチします。

正規表現を ( ) で囲うのは意味があって、今回の例では使っていませんが、パターンをグループ化して入力の特定の部分を {R:0} とか {R:1} で取得できるからです。

［Ignore case］というのは大文字・小文字の区別をしないという意味です。チェックが入ったままにしておいてください。

(4) Conditions セクション

Conditions セクションを開いて［Add...］ボタンをクリックし、表示された「Add Condition」ダイアログで［Condition input:］と［Pattern:］に赤枠で示した通り入力します。その他はデフォルトで上の画像の通りとなっているはずなので、そのままにしておきます。

［Condition input:］に入力した {HTTPS} は、上に紹介した Microsoft のドキュメントにも書いてありますが、サーバー変数です。HTTPS 通信でない場合サーバー変数 {HTTPS} の値は OFF という文字列になります。

つまり、サーバー変数 {HTTPS} の値が［Pattern:］に入力した正規表現 ^OFF$ にマッチした場合は HTTPS 通信でないと判断され、Action に設定されるリダイレクトが実行されるということです。

Conditions セクションの入力・設定が完了したら［OK］ボタンをクリックします。結果は以下のようになるはずです。

(5) Action セクション

上の画像の赤枠で示した通り設定・入力します。その他はデフォルトで画像の通りとなっているはずなので、そのままにしておきます。

［Action types:］の設定［Redirect］でリダイレクトを行う応答（この記事では 301 Moved Permanently）が返されます。

［Redirect URL:］に設定した {HTTP_HOST} と {REQUEST_URI} はサーバー変数です。上に紹介した Microsoft のドキュメントにも書いてありますが、例えば要求 URL が以下の場合、

http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3

取得される文字列はそれぞれ以下のようになります。

• HTTP_HOST: www.mysite.com
• REQUEST_URI: /content/default.aspx?tabid=2&subtabid=3

［Append query string］のチェックは外しておきます。［Redirect URL:］に設定した REQUEST_URI にクエリ文字列は含まれるので不要なはずです。

［Redirect type:］はデフォルトで［Permanent (301)］となっているはずなのでそのままにしておきます。今回のような HTTP から HTTPS へのリダイレクトでは 301 Moved Permanently が SEO 的に望ましいそうです。

(6) ルールの適用

入力・設定が完了したら右側の「操作」欄の下のメニュー［適用］をクリックします。

(7) web.config

アプリの web.config に以下のコードが追加されているはずなので確認してください。

<system.webServer>
  <rewrite>
    <rules>
      <rule name="Redirect HTTP to HTTP" stopProcessing="true">
        <match url="(.*)" />
        <conditions>
          <add input="{HTTPS}" pattern="^OFF$" />
        </conditions>
        <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" 
                appendQueryString="false" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

(8) ブラウザで確認

ブラウザのキャッシュを削除してからアドレスバーに http で始まる URL を入力して要求をかけ、上に設定したとおりリダイレクトが行われるか確認してください。

上の画像は Chrome のディベロッパーツールの Network でキャプチャした要求・応答を見たものです。設定どおり 301 Moved Permanently 応答が返ってきて、https で始まる URL にリダイレクトされています。

確認後、上の (7) の xml コードをホスティングサービスのサイトの web.config にコピーします。結果、期待通り HTTP から HTTPS へリダイレクトされることが確認できました。

Fiddler は、ブラウザなどの HTTP 通信を行うアプリケーションと Internet / Intranet の間の要求・応答をキャプチャして表示してくれる、Web アプリ開発には欠かせないツールです。（注: この記事は Windows OS 専用の Fiddler Classic の話です）

HTTPS 通信もキャプチャ・復号して内容を表示してくれますが、そのために Fiddler は、Fiddler とクライアントの間に独自のサーバー証明書を利用します。

下の画像で赤枠で囲った DO_NOT_TRUST_FiddlerRoot がそれで、Fiddler のオプション設定によって「信頼されたルート証明機関」にインストールされます。

証明書 NOT_TRUST_FiddlerRoot には有効期限があります。自動的には更新してくれないので、忘れた頃に突然証明書が無効だというエラーが出て焦ることになると思います。

下の画像がそれで、Fiddler を起動して、Visual Studio で起動した Web アプリを Chrome から呼び出して表示しようとしたら NOT_TRUST_FiddlerRoot の有効期限切れでエラーになったというものです。

上の画像の NET::ERR_CERT_DATE_INVALID をクリックすると Subject:localhost 以下の詳細情報が表示されますので、その中の Issuer でどの証明書に問題があるのかが分かります。

（ちなみに、Fiddler と Web サーバーの間は別の証明書を使っており、それが開発用の証明書の場合は有効期限が切れることがままあって、その場合は Issuer が上の画像の DO_NOT_TRUST_FiddlerRoot とは異なるので分かります）

NOT_TRUST_FiddlerRoot の有効期限を延長するにはどうするかと言うと、Fiddler のツールバーの [Tools] ⇒ [Options] をクリックして Options ダイアログを開き、[HTTPS] タブの [Actions] ボタンをクリックしてプルダウンを表示し、[Reset All Certificates] をクリックしてやります。

その先は表示される案内に従って進めていけば、「信頼されたルート証明機関」にインストールされた古い NOT_TRUST_FiddlerRoot 証明書が削除され、有効期限が延長された新しい証明書がインストールされます。

その際、[Decrypt HTTPS traffic] のチェックが外れることがあるようで、確認して外れていてらチェックを入れてください。

以上でエラーは解消できて、HTTPS 通信のトラフィックをキャプチャして表示できるようになるはずです。

dotnet dev-certs https コマンドについて調べたことを備忘録として残しておきます。

dotnet dev-certs コマンドは、Microsoft のドキュメント dotnet dev-certs に書いてありますように、開発用のサーバー証明書の作成・管理を行うためのツールです。

具体的には、フレンドリ名が ASP.NET Core HTTPS development certificate という自己署名証明書を作成・管理するツールです。その証明書を使って、ASP.NET Core Web アプリの開発中に、Web サーバーの Kestrel がブラウザなどのクライアントと HTTPS 通信ができるようになります。

（注: IIS Express でホストする場合は IIS Express Development Certificate というフレンドリ名の証明書が使用されます。このスレッドの話は関係ないので注意してください。）

このコマンドの実行によって証明書マネージャーに表示される証明書がどのようになるか、証明書がないときアプリを Kestrel で動かそうとするとどうなるかも以下に合わせて書いておきます。

(1) 初期状態

Visual Studio を開発に使っていれば自力で dotnet dev-certs コマンドを打って証明書を作る必要はなく、Visual Studio がコマンドを使って必要な証明書を生成してくれます。下の証明書マネージャーの画像がその結果で、発行先が localhost となっているのが開発用サーバー証明書です。

有効期限切れのものが含まれていますが (何年か Visual Studio で作業しているうちに追加されたものです)、作業していて支障はなかったのでそのままにしていました。

この中のフレンドリ名 ASP.NET Core HTTPS development certificate という証明書をすべて削除してから、新しく証明書を作成し、開発環境でそれを使って HTTPS 通信ができるようにします。

(2) dotnet dev-certs https --clean 実行

既存の証明書を削除するためコマンドラインから dotnet dev-certs https --clean を実行します。

コマンドを打つと下の画像の「ルート証明書ストア」というダイアログが出て削除してよいかが確認されるので［はい］をクリックします。（上の画像のように複数証明書がある場合は複数回ダイアログが出ます）

削除に成功するとコマンドラインに "HTTPS development certificates successfully removed from the machine." と表示され、証明書マネージャーの［個人］>［証明書］および［信頼されたルート証明書］>［証明書］にあったフレンドリ名 ASP.NET Core HTTPS development certificate の証明書はすべて削除されます。

（IIS Express 用の証明書 IIS Express Development Certificate にはこのコマンドは影響ありません）

この状態でコマンドラインから dotnet dev-certs https --check を実行すると "No valid certificate found." と表示されます。

(3) アプリの実行

証明書を削除した後、Visual Studio 2022 で Kestrel を使って ASP.NET Core Web アプリを実行すると「ASP.NET Core SSL 証明書を信頼する」というダイアログが出ます。

［いいえ］を選択すると下の画像のダイアログが出て「Web サーバー 'MvcCore6App2' に接続できません。Web サーバーはもう実行されてません」というメッセージが表示されて終わってしまいます。

コンソールを見ると以下の例外が出ていました。

Unhandled exception. System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date. To generate a developer certificate run 'dotnet dev-certs https'. To trust the certificate (Windows and macOS only) run 'dotnet dev-certs https --trust'.

（IIS Express 用の証明書 IIS Express Development Certificate には影響はありませんので、Visual Studio 2022 の設定を IIS Express を使うようにしてアプリを実行すれば上のような問題はありません）

(4) dotnet dev-certs https 実行

証明書を作成するためコマンドラインから dotnet dev-certs https を実行します。作成に成功すると "The HTTPS developer certificate was generated successfully." というメッセージが表示されます。

証明書マネージャーを見ると［個人］>［証明書］にフレンドリ名 ASP.NET Core HTTPS development certificate という証明書が追加されています。

ただし、この時点では［信頼されたルート証明書］>［証明書］には ASP.NET Core HTTPS development certificate は存在しません。

この状態で上の (3) と同様にアプリを実行してみます。同じく「ASP.NET Core SSL 証明書を信頼する」というダイアログが出るので［いいえ］を選択すると、今度は InvalidOperationException 例外はスローされず、自己署名証明書を使った場合の警告がブラウザに表示されます。

警告を無視して進めればブラウザにコンテンツの表示はできます。

(5) dotnet dev-certs https --check 実行

コマンドラインから dotnet dev-certs https --trust を実行しても証明書が発行されたかどうかを確認できます。発行されていると以下のようなメッセージが返ってきます。

A valid certificate was found: 8216607E62A7221B7EFEC3022C8AD599DC1728B1 - CN=localhost - Valid from 2023-03-28 13:07:39Z to 2024-03-27 13:07:39Z - IsHttpsDevelopmentCertificate: true - IsExportable: true
Run the command with both --check and --trust options to ensure that the certificate is not only valid but also trusted.

このコマンドは証明書の情報を確認するためだけのものです。証明書を作成することもなく、作成済みの証明書には何も影響しません。

(6) dotnet dev-certs https --trust 実行

上の (4) で発行した証明書を「信頼されたルート証明書」として登録するため、コマンドラインから dotnet dev-certs https --trust を実行します。

コマンドを入力すると、コマンドラインには "Trusting the HTTPS development certificate was requested. A confirmation prompt will be displayed if the certificate was not previously trusted. Click yes on the prompt to trust the certificate." というメッセージが表示され、下の画像のセキュリティ警告ダイアログが表示されます。

［はい］をクリックして処理を継続します。成功するとコマンドラインには "Successfully trusted the existing HTTPS certificate." というメッセージが表示されます。

証明書マネージャーを見ると［信頼されたルート証明書］>［証明書］に ASP.NET Core HTTPS development certificate が追加されています。

この後で Visual Studio からアプリを実行すれば証明書の問題はなくなり HTTPS 通信を使っての開発ができるようになります。