【ITニュース解説】Use Your Machine Name (Not Just localhost) with HTTPS on ASP.NET Core — and Make Node.js Trust It

ASP.NET Coreアプリケーションを開発する際、安全な通信のためにHTTPSを利用することは非常に重要である。通常、dotnet dev-certs https --trustというコマンドを使うと、開発用のHTTPS証明書が作成され、https://localhost:ポート番号のようなURLでアプリケーションにアクセスできるようになる。しかし、この証明書はlocalhostという特定の名前に対してのみ有効であり、もし自分のコンピューターをネットワーク上の他のデバイスや別のサービスから「my-machine」といったマシン名でアクセスしようとすると、証明書のエラーが発生してしまう。これは、ウェブサイトの身分証明書である「証明書」が、実際にアクセスしているホスト名（my-machine）をカバーしていないためだ。この状況を解決し、マシン名を使ったHTTPSアクセスを可能にする方法を、システムエンジニアを目指す初心者にもわかりやすく説明する。

まず、なぜHTTPSが開発環境で重要なのかを理解しよう。HTTPSは、インターネット上でデータをやり取りする際に、通信内容を暗号化し、データの盗聴や改ざんを防ぐためのプロトコルである。さらに、アクセスしているウェブサイトが本物であることを証明する役割も果たす。開発段階からHTTPS環境を構築しておくことで、本番環境で発生する可能性のあるセキュリティや設定の問題を、早い段階で発見し対処できるようになる。

今回の設定の中心となるのは、「自己署名証明書」というものだ。一般的なウェブサイトの証明書は、信頼できる第三者機関（認証局）が発行するが、開発環境では自分で証明書を作成し、これを使うことが多い。これが自己署名証明書である。この証明書を作成する際、その証明書が有効であると宣言するホスト名（DNS名）のリストを含めることができる。今回の目的を達成するためには、自分のコンピューターのマシン名（例: my-machine）だけでなく、慣れ親しんだlocalhost、そしてlocalhostのIPアドレスである127.0.0.1の三つをリストに含めることが推奨される。これにより、既存のツールがlocalhostで引き続き動作しつつ、新しくマシン名でのアクセスも可能になるというメリットがある。

証明書は、秘密鍵と公開鍵という二つの部分で構成される。これらの鍵のペアを一つのファイルにまとめ、パスワードで保護したものが「PFX（Personal Information Exchange）ファイル」と呼ばれる形式だ。PowerShellのコマンドレットを使うことで、指定したDNS名を含む自己署名証明書を簡単に作成し、それをPFXファイルとしてエクスポートできる。この際、必ずパスワードを設定し、そのパスワードを安全に管理することが非常に重要である。

作成したPFX証明書をASP.NET Coreアプリケーションで利用する方法は、主に二通りある。一つは、新しく作成した証明書を、dotnet dev-certs httpsコマンドで管理される開発用のデフォルト証明書として置き換える方法だ。この設定を行うと、特に何も設定していないASP.NET Coreアプリケーションでも、新しい証明書が自動的に使われるようになる。もう一つの方法は、アプリケーションのappsettings.jsonという設定ファイル内で、ASP.NET Coreアプリケーションのウェブサーバー機能を提供するKestrelサーバーに対して、使用するPFXファイルのパスとパスワードを明示的に指定する方法である。この方法は、デフォルトの開発証明書には影響を与えず、特定のアプリケーションだけカスタム証明書を使いたい場合に適している。

証明書を作成し、アプリケーションに設定しただけでは、ウェブブラウザや他のシステムがその証明書を自動的に信頼してくれるわけではない。自己署名証明書は、公的な認証局から発行されたものではないため、ブラウザは通常「この証明書は信頼できません」という警告を表示する。この警告を解消するためには、作成した証明書の中から公開鍵の部分だけを抽出したファイル（通常は「CERファイル」という形式）を、自分のコンピューターの「信頼されたルート証明機関」という特別な場所に手動でインポートする必要がある。この「信頼されたルート証明機関」に登録された証明書は、OSやブラウザから信頼されるようになり、警告なしにHTTPS通信が行えるようになるのだ。このインポート作業も、PowerShellのコマンドレットを使って簡単に行うことができる。

さらに、Node.jsで記述された別のサービスから、ASP.NET CoreアプリケーションにHTTPSでアクセスする場合にも、同様の信頼設定が必要となることがある。Node.jsのバージョンによって対応方法が少し異なるため、注意が必要だ。Node.jsのバージョン22.xの場合、WindowsのOSが信頼している証明書ストアをデフォルトでは利用しないため、特別な設定が求められる。具体的には、前述のCERファイルを、certutilというコマンドを使って「PEMファイル」という別の形式に変換する必要がある。PEMファイルは、証明書情報をテキスト形式で記述したもので、Node.jsが外部の信頼できる証明書として読み込む際に利用される。このPEMファイルのパスをNODE_EXTRA_CA_CERTSという環境変数に設定することで、Node.jsアプリケーションは自己署名証明書で保護されたHTTPSエンドポイントを信頼して通信できるようになる。一方、Node.jsのバージョン23.8以降では、--use-system-caというオプションを使用することで、OSの信頼ストアを直接利用できるようになり、設定がより簡単になる予定である。

もし将来、このカスタム証明書が不要になった場合は、作成時に使用した証明書オブジェクトの「サムプリント（Thumbprint）」という一意の識別子を利用して、PowerShellから証明書を簡単に削除できる。これにより、関連する秘密鍵も含めて、コンピューターから証明書情報を安全に消去することが可能だ。

この一連の作業を行う際には、いくつかの一般的な落とし穴があるため、注意が必要だ。最もよくある問題は、「名前の不一致」である。アクセスしようとしているURLのホスト名（例えばhttps://my-machine:ポート番号であればmy-machine）が、作成した証明書に記載されているDNS名リストに正確に含まれていることを必ず確認しよう。また、Node.jsでエラーが続く場合は、NODE_EXTRA_CA_CERTS環境変数がPEMファイルへの正しいパスを指しているか、そしてシェルを再起動して環境変数が正しく反映されているかを確認すること。ブラウザでの信頼に関する問題は、CERファイルが「現在のユーザー」の「信頼されたルート証明機関」に適切にインポートされているかを改めて確認する必要がある。Kestrelの設定でPFXファイルのパスを指定する際は、Windowsの絶対パス形式で記述されているかも重要なチェックポイントである。

これらの手順と注意点を理解し実行することで、localhostという限られた範囲を超えて、自分のコンピューターのマシン名を使ってASP.NET CoreアプリケーションのHTTPSエンドポイントにアクセスし、さらにNode.jsなどの他の開発環境からもその安全性を信頼して利用できる、より柔軟な開発環境を構築できるだろう。これにより、本番環境に近い条件でのテストが可能となり、開発作業の効率と品質の向上が期待できる。