プライベート IP への HTTPS：証明書の識別情報かホスト名か

https://10.60.0.25 のサービスは、DNS 名がなくても認証済み TLS を使えます。アドレスがクライアントの検証すべき識別情報であり、証明書はそれを正確に記述する必要があります。判断すべきは、そのアドレスが識別情報として十分に安定しているか、それともホスト名のほうが維持しやすいかです。VPN は到達性に答えるものであり、この問いには答えません。

識別情報と信頼を正しく整えれば、IP ベースの URL は正当な設計です。

クライアントが実際に検証するもの

クライアントは URL の参照識別情報を、証明書のサブジェクト代替名と照合します。IP アドレスの場合、それはアドレスと等しい iPAddress エントリを意味します。親しみやすいコモンネームはその代わりになりません。

RFC 9525 は IP アドレスの識別情報を DNS 名から分離し、照合規則を定義します。アドレスをサブジェクトのラベルだけに置いたり、DNS 種別のエントリにしたりしても一致しません。だからこそ、警告が出たときに確認すべきフィールドは SAN です。

信頼は二つ目の独立した確認です。名前の一致は、信頼できないチェーン、期限切れの証明書、別の目的で発行された証明書を直しません。

判断その一：アドレスは識別情報として十分に安定しているか

アドレスが配備の全期間にわたって固定なら、IP SAN 証明書は単純で正直です。サービスが移転しうるなら、移転のたびに証明書の交換とクライアントの協調更新が必要になります。

安定したホスト名はその結合を減らします。クライアントは名前を使い、承認された DNS がそれを現在のアドレスに対応づけ、アドレス変更は識別情報の変更ではなくなります。証明書の更新は必要ですが、URL は変わりません。

管理された hosts ファイルのエントリは、小規模な環境で対応づけを提供できます。配布の責任が増えますが、TLS 検証の代わりにはなりません。

判断その二：クライアントが発行者をどう信頼するか

プライベート CA の場合は、承認された仕組みで信頼の基点を対象デバイスに配布します。警告をクリックで通過したり、サインインページが渡す証明書をインストールしたりするよう利用者を慣らしてはいけません。公的に信頼される証明書が必要なら、それを前提に計画する前に、プライベートアドレスに対する発行者の現在の規則を確認してください。ほとんどの公開発行者は、プライベート IP を公開の識別情報として検証しません。

実際のブラウザーまたはアプリケーションを確認します。その信頼ストアと検証の挙動は、オペレーティングシステムの一般的な証明書ドキュメントより重要です。コンソールだけでなく、実際のデバイスで確認してください。

Web アプリケーションを動かしているマシンが VPN ゲートウェイとは限らないため、トンネルの証明書がこれと関係していると決めつけないでください。

アドレス変更は起こる前に計画する

10.60.0.25 が 10.60.0.40 になれば、古い証明書はもはや URL を記述しません。交換とクライアントの更新を一緒に計画し、移行中に検証を決して無効にしないでください。

利用者が入力する、またはアプリケーションが設定する識別情報を選び、その周りに発行、信頼、配備、更新を揃えます。警告を閉じた到達可能なページは、クライアントが識別情報を検証するサービスと同じ結果ではありません。