WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

dotnet dev-certs https コマンドについて

by WebSurfer 2023年3月30日 21:43

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

dotnet dev-certs コマンド

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 証明書を信頼する」というダイアログが出ます。

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 --check を実行しても証明書が発行されたかどうかを確認できます。発行されていると以下のようなメッセージが返ってきます。

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 通信を使っての開発ができるようになります。

Tags: , , , ,

CORE

IIS Express で SSL 通信

by WebSurfer 2018年9月9日 14:12

Visual Studio Community 2015 で ASP.NET Web アプリケーションの開発を行う際、IIS Express で SSL 通信を利用できるようにする方法を書きます。

IE11 の実行画面

上の画面は、Visual Studio での設定完了後、Web Forms アプリケーションを IIS Express 上で実行させて IE11 に表示させたものです。

赤枠で囲ったアドレスバーに示される URL が https で始まっているのが分かるでしょうか? IE11 と Edge の場合は上の画像のように警告なしで表示されます。

そのための Visual Studio での設定方法は以下の通りです。

プロジェクトのプロパティ設定

Visual Studio のテンプレートを使って Web アプリケーションのプロジェクトを作成したら、ソリューションエクスプローラーでプロジェクトのノードをクリックしてプロパティを表示します。

プロパティウィンドウで[SSL 有効]を True に設定します。すると、[SSL URL]に自動的に SSL 通信用のプロジェクトの URL が設定されます。上の画像を見てください。

その操作を行う際に警告ダイアログが出て(正確なタイミングとダイアログの内容は忘れました)、自動的にフレンドリ名 IIS Express Development Certificate というサーバー証明書が発行されます。

サーバー証明書

上の画像で赤枠で囲ったものが発行されたサーバー証明書です。発行場所は上の画像の通り「現在のユーザー」です。MMC で確認する場合は、スナップインを追加する際[ユーザーアカウント(M)]を選んでください。

サーバー証明書なので発行されるのは最初の一回だけです。この後、新たに別のプロジェクトを作って同じ操作を行ってもダイアログは出ませんし証明書は発行されませんので注意してください。

仮想ディレクトリの作成

Visual Studio のソリューションエクスプローラーで Properties を右クリックして開きます。表示される画面で[Web]タブをクリックし、上の画像のように[プロジェクトの URL(J)]のテキストボックスに、プロジェクトのプロパティウィンドウの[SSL URL]に設定された URL をコピーします。

その後[仮想ディレクトリの作成(Y)]ボタンをクリックすると「仮想ディレクトリは正しく作成されました」というダイアログが出ます。

binding の設定

作成された仮想ディレクトリは applicationHost.config ファイルの binding タグを見ると確認できます。上の画像の赤枠部分を見てください。

applicationHost.config ファイルはプロジェクトのフォルダにあります。詳しくは先の記事「ApplicationHost.config の場所」を見てください。

以上の設定後、[ファイル(F)]⇒[すべて保存(L)]してから、[デバッグ(D)]⇒[デバッグの開始(S)]または[デバッグなしで開始(H)]で、上の画像のように既定のブラウザが立ち上がって SSL 通信で要求・応答が行われ、結果が表示されます。

Chrome の実行画面

Chrome などの他のブラウザでも、上の画像のような警告は出ますが、Visual Studio を使って IIS Express で SSL 通信を行っての開発は可能なようです。

全てのブラウザで、IE11、Edge を使った場合と同様か、100% 問題ないかはまでは確認していませんが。

Tags: ,

DevelopmentTools

iframe の src 設定と SSL 通信

by WebSurfer 2011年11月15日 22:35

SSL (Secure Sockets Layer) 通信を行っているページで、"セキュリティで保護されているコンテンツのみ表示されます。"(IE9 の場合。他のバージョン、ブラウザではメッセージが異なります。)という警告が表示されることがあります。

SSL 通信での IE9 の警告

原因は、https:// で接続したページ内に https (SSL) と、http (非SSL) の接続が混在しているからです。例えば、そのページで使用している画像、CSS、JavaScript などのリソースへの参照を http で始まる URL で行っているケースです。

解決方法は、参照するファイルの URL を次のいずれかの形式に設定することです。

  • httpsで始まる絶対 URL パスを使う。
  • / (スラッシュ)で始まるサイトルート相対パスを使う。
  • 相対パスを使う。

上記のパスの具体的な例はそれぞれ以下のとおりです。

<img src="https://www.aaa.co.jp/images/sample.jpg" />
<img src="/images/sample.jpg" />
<img src="../images/sample.jpg" />

上記のようなケースは、html ソースを見れば気がつくので容易に対処できると思います。

気がつきにくいのが iframe の src 属性です。src を省略したり、http で始まる URL に設定したりすると警告が出ます。実は、自分は、これが問題になることすら知りませんでした。(汗)

特に問題なのは、動的に iframe がページに追加される場合です。さらに、ライブラリとして dll で提供されているカスタムコントロールの場合は、いくらソースを眺めていても、iframe は出てこないのでわかりません。

カスタムコントロールの具体的な例としては、AJAX Control Toolkit の AsyncFileUpload コントロールに使用されている iframe があります。このコントロール場合、src 属性には about:blank が設定されるのですが、about:blank も非 https と見なされるらしく、やはり警告が出ます。

解決方法は、KB261188 にあるように、iframe の src 属性の初期値を設定しない場合は、ダミー html ページを設定しておくことだそうです。

ただし、ダミーといっても存在しないファイルを設定するとサーバー側でエラーログが残るという話があるので(確かめたわけではありません)、中身は空でも実存するファイルを指定するのがよいそうです。

AJAX Control Toolkit の場合はソースが入手できますので、ソースを修正して再コンパイルするなりして解決できますが、そうでない場合は手の打ちようがないですね。

Tags: , ,

ASP.NET

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar