なぜApplication Gatewayに「証明書」が必要なのか？
Application Gateway（App Gateway）で証明書が必要な理由は、一言でいうと「ユーザーとWebサイトの間の通信を安全に暗号化（HTTPS化）するため」です。
① データの盗聴や改ざんを防ぐ（HTTPS化）
通常のHTTP通信は、パスワードや個人情報が「プレーンテキスト（生データ）」のままインターネット上を流れるため、悪意ある第三者に盗聴される危険があります。
証明書（正しくはTLS/SSL証明書）を使うことで、通信データを複雑に暗号化し、万が一盗聴されても中身が解読できないようにします。
② 「SSL/TLS 終端（ターミネーション）」を行う
App Gatewayのようなロードバランサーにおいて、SSL/TLS 終端を行うことが最も重要な役割です。
ユーザーから届いた大量の暗号化通信（HTTPS）を、App Gatewayが代表して受け取り、ここで暗号を解除（終端）して、後ろのWebサーバー（VMやApp Service）には通常のHTTPで転送する、という仕組みです。
暗号化・復号の処理はサーバーにとって非常に「重い」負荷がかかります。
これをApp Gatewayが一手に引き受けることで、後ろのWebサーバーは本来のWeb処理に専念でき、システム全体のパフォーマンスが向上します。
証明書を「キーコンテナー」と連携させるメリット
App Gateway自体に直接証明書ファイル（PFXなど）をアップロードして使うことも可能ですが、実務でそれをやると運用が地獄になります。
そこで登場するのが「キーコンテナー（Key Vault）」との連携です。
以下のうち1つでも必要と感じたらApp Gatewayとキーコンテナーを連携させましょう。
証明書の自動ローテーションが可能
従来のやり方だと、1年に1回などの証明書更新のたびに、エンジニアが手動で新しい証明書ファイルをダウンロードし、App Gatewayの設定画面から再アップロードする必要がありました。
これには、「更新を忘れてサイトが閲覧不可になる」という致命的なリスクが常に付きまといます。
キーコンテナーと連携しておくと、キーコンテナー側の証明書を新しくするだけで、App Gatewayが自動的にそれを検知して新しい証明書に切り替えてくれます。
手動での再設定や、反映のためのダウンタイムがなくなる
秘密鍵（証明書データ）を安全に一元管理できる
証明書、特に「秘密鍵」が含まれるデータは、漏洩すると致命傷になる超重要情報です。
これを色々なサーバーやサービスに個別にアップロードしてバラバラに管理していると、どこから漏洩するか分かりません。
「秘密鍵はキーコンテナーの中だけに安全に保管し、各サービスにはそこへアクセスする権限（マネージドID）だけを与える」という形にすることで、セキュリティレベルが格段に上がります。
マルチ環境や他のリソースへの使い回しが楽
例えば、同じ証明書を「App Gateway」だけでなく、後ろにある「App Service」や「Azure Front Door」など、複数のリソースでも使いたいケースがあります。
キーコンテナーに1つ入れておけば、すべてのリソースがそこを参照しに行くだけで済むため、管理コストが圧倒的に下がります。
キーコンテナーで作成できる証明書の種類
キーコンテナー（Key Vault）で証明書を作成しようとすると、作成画面の「証明機関 (CA) の種類」という項目でこれら3つの選択肢が出てきますよね。
それぞれの違いや特性、そして「実務でどう使い分けるべきか」を分かりやすく解説します。
| 証明書の種類 | 信頼性 | 費用 | 自動更新 | 主な用途 |
| 自己署名証明書 | ❌ (警告が出る) | 無料 | 可能 | 開発・テスト環境での検証 |
| 統合された CA | ⭕ (公的信頼) | 有料 (実費) | 完全自動 | 本番環境 |
| 統合されていない CA | ⭕ (公的信頼) | CAによって異なる | 手動更新 | 本番・社内環境 |
1. 自己署名証明書（オレオレ証明書）
「自分で自分を本物だと証明する」スタイルの証明書（いわゆるオレオレ証明書）
通常、証明書は「信頼できる第三者（認証機関）」に身元を保証してもらうものですが、自己署名証明書は第三者の保証を一切受けず、自分自身の鍵で署名して作ります。
キーコンテナー内でボタンをポチッと押すだけで、完全無料＆一瞬で作成できるのが最大のメリットです。
⚠️ デメリット
公的な身元保証がないため、この証明書を使ったWebサイトにブラウザでアクセスすると、「この接続は安全ではありません」という赤い警告画面が表示されてしまいます。
開発環境やテスト環境での動作検証や外部には一切公開しない、社内ネットワーク内（検証用）の通信で使用されます。
2. 統合された CA によって発行された証明書（運用の完全自動化）
「Azureと連携している認証局」に、キーコンテナーの中から自動で発行してもらう証明書
Azureは、一部の有名なパブリック認証機関（DigiCert や GlobalSign など）と連携しています。
あらかじめキーコンテナーと認証機関（CA）のアカウントを紐付けておくことで、キーコンテナーの画面から申請を出すだけで、公的な証明書を自動で取得・格納してくれます。
最大の強みは「自動ローテーション（更新）」です。有効期限が近づくと、キーコンテナーが裏側で自動的にCAへ更新申請を出し、新しい証明書に入れ替えてくれます。
認証機関（DigiCert等）の証明書利用料金（実費）がかかります。
また、事前に認証機関との契約や、Azure上でのAPI連携設定が必要です。
3. 統合されていない CA によって発行された証明書（自由度重視の手動組込）
「Azureとは連携していない認証局」から、手動で証明書をもらってくる設定
キーコンテナーと直接提携していない認証機関（Let’s Encryptや、企業独自の社内プライベート認証局など）の証明書を使いたい場合に使用します。
手順としては、まずキーコンテナー側で「CSR（証明書署名要求）」という申請書ファイルを生成し、それをダウンロードして手動で認証機関に提出します。その後、発行された証明書データを再び手動でキーコンテナーにアップロード（マージ）して登録します。
発行・登録の手順がやや複雑で手間がかかります。
有効期限が切れる際、自動更新（ローテーション）ができないため、次回の更新時もまったく同じ手動作業を人間がやる必要があります。
企業指定の「社内プライベート認証局」から発行された証明書を使いたい場合や予算の兼ね合いで、無料の Let’s Encrypt 等を手動で組み込んで運用したい場合に利用されます。
キーコンテナとApp Gatewayを連携する4ステップ
いざ設定しようとすると「権限エラーが出た！」「どこから設定すればいいの？」と迷いがちなポイントでもあります。
今回は、順番にマネするだけで確実に設定ができる【4つのステップ】を、実際の画面を交えながら分かりやすく解説します！
【事前準備】作業者にキーコンテナーの操作権限を付与する
まず、あなたがキーコンテナーで証明書を作れるように権限を設定します。
Azureでは、たとえ「所有者」や「共同作成者」であっても、キーコンテナーの中身（証明書やシークレット）を操作する権限はデフォルトで持っていません。
- キーコンテナーの左メニューにある「アクセス制御 (IAM)」を開きます。
- 「+ 追加」 ＞ 「ロールの割り当ての追加」 をクリックします。
- ロール一覧から 「Key Vault 証明書担当者」
（または最強権限のキーコンテナー 管理者）を選択します。 - メンバーにあなた自身のサインインアカウント（メールアドレス）を指定して、保存します。
キーコンテナー画面に「この操作は RBAC で許可されていません」というエラーが出ている場合は、この手順が必要です。
ステップ1：キーコンテナーで証明書を作成する
作業者の権限が付与されたら、まずはベースとなる「証明書」をキーコンテナーの中に作成します。
Azureポータルでキーコンテナーのページを開き以下の手順を実行してください。
- 左メニューの「オブジェクト」配下にある「証明書」をクリックします。
- 「+ 生成/インポート」をクリックします。
- 以下の内容を入力して、画面左下の「作成」ボタンを押します。
- 証明書の名前：任意の名前（例：
ait-test） - 件名：
CN=あなたのドメイン名（テストならCN=ait-test.localなどでOK） - コンテンツの種類：環境に合わせて PKCS #12（Windows/Web Apps向け）または PEM（Linux向け）を選択します。
- 証明書の名前：任意の名前（例：
これで、キーコンテナー内に証明書が用意されました！裏側では自動的に同じ名前の「シークレット」も生成されています。
「オブジェクト」配下にある「証明書」を開いて、作成した証明書が表示されているか確認しましょう。
ステップ2：App Gateway用の「マネージドID」を作る＆紐付ける
次に、App Gatewayがキーコンテナーに証明書を自動で取りに行くための「身分証明書」を用意してあげます。
- Azureポータルの検索窓から「ユーザー割り当てマネージドID」を検索し、新しく1つ作成します。
- 作成後、設定したい Application Gateway の画面を開きます。
- 左メニューの「設定」配下にある「ID」メニューを開き、先ほど作ったマネージドIDを追加（登録）します。
これで、App Gatewayが「私はこのID（身分証）を持っています」と言える状態になりました。
ステップ3：キーコンテナー側でマネージドIDに権限をあげる
ステップ2で作ったApp Gatewayの身分証（マネージドID）に対して、キーコンテナーの中を覗いてOK、という許可（権限）を与えます。
- キーコンテナーの「アクセス制御 (IAM)」を開きます。
- 「+ 追加」 ＞ 「ロールの割り当ての追加」 をクリックします。
- 今度は 「Key Vault シークレット ユーザー」 というロールを選択します。
- メンバーの選択画面で「マネージドID」を選択し、ステップ2で作ったIDを指定して保存します。
【ここが超重要！】
App Gatewayが裏側で秘密鍵付きの証明書データを引き抜く際は、証明書権限ではなくシークレットの読み取り権限が必要になります。
ステップ4：App Gatewayのリスナーで証明書を指定する
最後にApp Gatewayに「キーコンテナーにあるあの証明書を使う」ための指示を出します。
- Application Gateway の設定画面を開きます。
- 左メニューの一番下にある「リスナー」をクリックし、上部の「リスナー TLS 証明書」タブに切り替えます。
- 「+ 証明書を追加する」をクリックします。
- 右側に出てくるパネルで、以下のように設定します。
- 証明書名：App Gateway内で管理するための任意の名前
- 証明書の選択方法：「キーコンテナー から選択」にチェックを入れる
- マネージドID：ステップ2で紐付けたIDを選択
- キーコンテナー：証明書を作成したキーコンテナー を選択
- 証明書：ステップ1で作った 証明書を選択
- 最後に「追加」を押し、App Gatewayの設定を保存（更新）します。
この設定を行うことで、App Gatewayはキーコンテナーに格納している証明書を安全に使用できます。
まとめ
キーコンテナーとApplication Gatewayの連携は、初期設定の手間こそ少しありますが、一度構築してしまえば運用フェーズでの「証明書の更新忘れによるダウンタイム」を完全にゼロにできる強力なメリットがあります。
本番運用のインフラ構築には必須のスキルですので、ぜひ本手順を参考に構築してみてください！
