Azure FilesをマウントしたIIS WebサーバーをHTTPS化する手順
はじめに
前回の記事では Azure Files をIISにマウントし、Webサーバーとして公開する方法を紹介しました。
🔗 前回の記事: Azure FilesをIISにマウントしてWebサーバーとして公開する方法
今回は、そのWebサーバーを HTTPS化 する手順を解説します。
AD CSを使って証明書を発行し、IISでHTTPSを有効にするまでの流れを紹介します。
また、 Edgeの証明書検証仕様の変更による落とし穴 についても紹介します!
1. 環境構成
📌 システム構成
-
ドメインコントローラー (AD DS + AD CS)
- Active Directory Certificate Services (AD CS) を使って証明書を発行
-
Webサーバー
- IISをインストール
- Azure Filesをマウントし、Webコンテンツをホスト
-
クライアント
- WebサーバーにHTTPSでアクセス
構成図
2. 証明書の発行
(1) 証明書テンプレートの作成
Webサーバーが証明書を取得できるように、AD CSの証明書テンプレート をカスタマイズします。
📌 手順
- AD CSの「証明書テンプレート」を開く
- 「Webサーバー」テンプレートをコピー
- 「セキュリティ」タブでWebサーバーに「登録」権限を付与
- テンプレートを公開する
(2) Webサーバーから証明書を要求
今回はCSRを手動で作成してCAに送信する方法ではなく、Webサーバーの certlm.msc
から直接証明書を要求・取得しました。
📌 手順
- Webサーバーで
certlm.msc
を開く - 「個人」→「証明書」→右クリック →「すべてのタスク」→「新しい証明書の要求」
- 作成したテンプレートを選択
- サブジェクトの種類:共通名(CN)にFQDNを入力して追加
- そのまま証明書を取得(インポートまで自動で実施)
3. IISでHTTPSを有効化する
(1) IISに証明書をバインド
取得した証明書をIISに設定し、HTTPSでアクセスできるようにします。
📌 手順
- IISマネージャーを開く
- 対象サイトの「バインドの編集」
- ポート443(HTTPS)を追加し、発行した証明書を選択
- 設定を保存
4. EdgeでHTTPSにアクセス…できない!?
HTTPSバインドまで完了し、期待してアクセスしたところ…
🔴 エラーメッセージ
「サーバーの証明書にサブジェクトの別名が設定されていません」
NET::ERR_CERT_COMMON_NAME_INVALID
5. 原因は「サブジェクトの別名」がないことだった
証明書の共通名(CN)にはFQDNを設定していたのに、Edgeではアクセスできませんでした。
原因は、最近のEdge(および他のモダンブラウザ)では、CNではなく「サブジェクトの別名(SAN)」を優先して検証する仕様になっているからです。
つまり、証明書に 「サブジェクトの別名」にFQDNが設定されていないとブラウザは許可してくれないということです。
6. サブジェクトの別名(SAN)を設定して再発行
ということで、もう一度証明書要求をやり直し、今回は 「サブジェクトの別名(DNS)」にFQDNを明示的に追加しました。
📌 手順
- 再度
certlm.msc
を開き「新しい証明書の要求」 - サブジェクトに共通名(CN)を、サブジェクトの別名(DNS)にFQDNを追加
- 証明書を取得し、IISのHTTPSバインドを更新
7. HTTPS通信が成功!
証明書の再発行後、Edgeで再度アクセスすると…
今度はHTTPSで正しくアクセスできました!🔓
まとめ
✅ AD CSで証明書テンプレートを作成
✅ certlm.mscから証明書を要求(初回は共通名のみ)
✅ EdgeでHTTPSアクセス時にエラー発生
✅ 原因は「サブジェクトの別名」が未設定だったこと
✅ 再度証明書要求を行い、サブジェクトの別名にFQDNを追加
✅ HTTPS通信が正常に行えるようになった!
役に立ったら「いいね」やフォローお願いします!🙏
質問やフィードバックは コメントでどうぞ! 😊