【Azure入門】Application GatewayのTLS/証明書を理解する｜TLS終端・HTTP→HTTPSリダイレクト・エンドツーエンドTLS・Key Vault連携を解説

Azure

「Application GatewayでHTTPS化したいけど、証明書ってどこに、どうやって載せるの？」——Azureを学習していると、リスナーの設定画面で必ずこの壁にぶつかります。

さらに「TLS終端って何が終わるの？」「Key Vaultを使うと何がうれしいの？」「バックエンドまで暗号化するエンドツーエンドTLSってどう違うの？」と、TLSまわりは用語が多くて混乱しがちです。ですが、ここを整理できると、Application Gatewayの理解が一気に立体的になります。

証明書を「載せる場所」と「載せ方」、それにTLS終端とE2E TLSの違いが、いつもごちゃごちゃになる…

この記事は、Application Gatewayシリーズの3記事目「TLS／証明書」です。作成手順やWAFの深い設定には立ち入らず、「TLSと証明書をどう扱うか」だけに絞って、次の5つを順番に整理します。読み終えたときに、この5つを自分の言葉で説明できることをゴールにしています。

  • リスナーで TLS終端（証明書） を構成できる
  • HTTP → HTTPSリダイレクト を設定できる
  • 証明書の登録方法（PFXアップロード / Key Vault参照）を理解している
  • エンドツーエンドTLS（バックエンド再暗号化） を構成できる
  • Key Vault連携 でTLS証明書を一元管理できる

前半（1〜3）は「クライアント ↔ Application Gateway 間」のTLS、後半（4〜5）は「Application Gateway ↔ バックエンド 間」のTLSとKey Vaultでの一元管理という流れです。各セクションの最後に「これが説明できればOK」という自己チェックの目安を置いていますので、学習の到達度確認にも使ってください。

リスナーでTLS終端（証明書）を構成する

TLS終端（TLS termination）とは、暗号化されたHTTPS通信の「暗号を解く（復号する）」処理を、Application Gateway側でまとめて肩代わりすることです。

「終端」という言葉が分かりにくいのですが、要は「クライアントとの暗号化のやりとりが、Application Gatewayのところで一度”終わる”」という意味です。クライアントとApplication Gatewayの間はHTTPSで暗号化されていますが、そこで暗号を解いてしまい、バックエンドサーバーへは（既定では）暗号化なしのHTTPで渡す——これがTLS終端です。

身近な例で言うと、会社の受付で「封をした親展の手紙」を開封してくれる担当者のようなものです。外から来る手紙（クライアントからのHTTPS）は封がされていますが、受付（Application Gateway）が開封し、中身を読んでから社内の担当部署（バックエンド）へ回す。おかげで各部署は開封の手間（暗号処理）から解放されます。

TLS終端をApplication Gatewayで行うと、次のようなメリットがあります。

  • バックエンドの負荷軽減：CPUに重いTLSの暗号／復号処理をAGW側に集約でき、バックエンドはコンテンツ配信に専念できる。
  • 賢いルーティングが可能：復号することでURLパスやヘッダーの中身が読めるようになり、L7ルーティング（パスベース振り分けなど）が使える。
  • 証明書管理がラク：証明書はAGWに1か所置けばよく、バックエンドの全サーバーに配る必要がない。

証明書は「HTTPSリスナー」に載せる

TLS終端を構成するには、HTTPSリスナー（プロトコル=HTTPS / ポート=443）に、TLS/SSL証明書を紐づけるだけです。証明書を載せる「場所」はリスナーである、と覚えてください。ここが分かると設定画面で迷いません。

載せる証明書には、いくつか守るべき条件があります。

  • 証明書は PFX形式（秘密鍵と公開鍵の両方を含む形式）であること。
  • 証明書チェーン全体（ルート証明書・中間証明書・リーフ証明書）を含めてアップロードすること。信頼の連鎖を確立するために必要です。
  • 証明書の CN（コモンネーム）が、アクセスするホスト名と一致していること。https://www.contoso.com/ にアクセスするなら、CNは www.contoso.com でなければなりません。
  • 証明書の 有効期限内（Valid from 〜 Valid to の範囲内）であること。

なお、Application Gateway自身には証明書を新規発行したりCAに申請したりする機能はありません。証明書は別途、認証局（CA）から取得したものを持ち込む形になります。テスト用途なら自己署名証明書も使えますが、その場合ブラウザは「信頼されていない」と警告を出します（本番では使わないこと）。

設定できたら、ブラウザで https://（AGWのIPまたはドメイン） にアクセスし、鍵マークが付いてHTTPSでページが表示されることを確認します。これがTLS終端が動作している証拠です。

【ここが説明できればOK①】
「HTTPSリスナーにPFX証明書を紐づけると、AGWがクライアントとの暗号を解くTLS終端が行われ、ブラウザからHTTPSでアクセスできる」——これを言えれば1つ目のチェックはクリアです。

HTTP → HTTPSリダイレクトを設定する

HTTPS化しても、ユーザーがうっかり http://（80番ポート）でアクセスしてくることは避けられません。そのままだと暗号化されない通信になってしまうため、HTTPで来たアクセスを自動でHTTPSへ振り向ける（リダイレクトする）設定を入れます。

HTTP → HTTPSリダイレクトとは、ポート80（HTTP）に来たリクエストを、ポート443（HTTPS）へ自動的に転送する設定です。

仕組みはシンプルで、「HTTPリスナー」＋「リダイレクト用のルーティングルール」の組み合わせで実現します。1記事目でやった「リスナー → ルール」の関係を、リダイレクトに応用する形です。

  1. HTTPリスナー（プロトコル=HTTP / ポート=80）を用意する。
  2. そのリスナーに ルーティングルール を紐づけ、バックエンドターゲットの種類を 「リダイレクト（Redirection）」 にする。
  3. リダイレクト先（Redirection target）を 「リスナー」＝先ほど作ったHTTPSリスナー に指定する。
  4. リダイレクトの種類は、通常 「Permanent（恒久的＝HTTP 301）」 を選ぶ。

図にすると、リクエストの流れはこうなります。

  ブラウザ  ──①  http://example.com  (ポート80) ──▶
        │
        ▼
 【HTTPリスナー(80)】
        │ ②
        ▼
 【リダイレクトルール】── ③ 「HTTPSリスナーへ飛ばせ」
        │
        ▼
  ブラウザに 301 を返す ──④  https://example.com (443) へ再アクセス
        │
        ▼
 【HTTPSリスナー(443)】── TLS終端 ──▶ バックエンド

設定時のポイントとして、「クエリ文字列を含める（Include query string）」「パスを含める（Include path）」を”はい”にしておくと、http://example.com/blog?id=5 のようなアクセスも、パスとクエリを保ったまま https://example.com/blog?id=5 へ正しく転送されます。ここを”いいえ”にすると、リダイレクト後にトップページへ飛んでしまうので注意しましょう。

リダイレクトは「バックエンドに流す」んじゃなくて「ブラウザに飛び先を教えて再アクセスさせる」んだね。だからバックエンドプールは要らないんだ！

確認方法は簡単です。ブラウザや curl で http://（AGWのアドレス） にアクセスし、自動的に https:// に切り替わることを見ればOKです。curl -I http://... なら、応答に 301 と Location: https://... が返ってくることで確認できます。

【ここが説明できればOK②】
「HTTPリスナー(80)にリダイレクト種別のルールを付け、ターゲットをHTTPSリスナー(443)に指定すれば、80→443の転送ができる」——これを言えれば2つ目のチェックはクリアです。

証明書の登録方法（PFXアップロード / Key Vault参照）

証明書を「リスナーに載せる」と説明しましたが、その載せ方（証明書をAGWに渡す方法）には2つの方式があります。ここを理解しておくと、実務での証明書運用がぐっとイメージしやすくなります。

  • ① PFXを直接アップロードする方式：手元のPFXファイルとパスワードを、リスナー設定に直接アップロードする。昔からある伝統的な方法。
  • ② Key Vaultを参照する方式：Azure Key Vaultに保管した証明書を、リスナーから「参照」する。証明書の実体はKey Vault側に置いたまま。v2 SKU（Standard_v2 / WAF_v2）でのみ利用可能。

例えるなら、①は「証明書のコピーを手渡しする」方式、②は「金庫（Key Vault）に原本を預けておき、AGWには金庫の鍵を渡して必要なときに取りに行かせる」方式です。②のほうが一手間かかるように見えますが、運用面で大きな利点があります。

Key Vault参照の利点

  • セキュリティの分離：証明書（＝秘密鍵）をアプリ開発チームが直接触らずに済む。セキュリティ担当チームがKey Vaultで証明書を管理し、AGWには「取得の許可」だけを与える、という役割分担ができる。
  • 一元管理：複数のAGWや他サービスで同じ証明書を使う場合も、Key Vaultの1か所を更新すればよい。
  • 自動更新に対応：Key Vault側で証明書が更新されると、AGWがそれを自動で取り込む（詳細は後半のセクションで解説します）。

PFX直接アップロードは手軽ですが、証明書の期限が切れるたびに手動で新しいPFXを入れ直す必要があります。本番運用で更新の手間や証明書切れの事故を減らしたいなら、Key Vault参照が推奨——という位置づけで押さえておきましょう。

【ここが説明できればOK③】
「証明書の登録には、PFXを直接アップロードする方式と、Key Vaultを参照する方式（v2のみ）の2つがあり、Key Vault参照はセキュリティ分離と自動更新の点で有利」——これを言えれば3つ目のチェックはクリアです。

エンドツーエンドTLS（バックエンド再暗号化）を構成する

ここから後半です。前半のTLS終端は「クライアント ↔ AGW間だけHTTPS」で、AGW ↔ バックエンド間は既定でHTTP（暗号化なし）でした。しかし、医療・金融など「バックエンドまで一切平文にしたくない」要件では、AGWとバックエンドの間も暗号化する必要があります。それがエンドツーエンドTLS（E2E TLS）です。

エンドツーエンドTLSとは、AGWがクライアントとのTLSを一度終端して中身を見た後、バックエンドへ渡す際に「再び暗号化し直して（再暗号化して）」HTTPSで送る構成です。

動作を分解すると、次の流れになります。TLS終端の「その先」に暗号化がもう1回入る、とイメージしてください。

  クライアント
     │  ① HTTPS（暗号化）
     ▼
 ┌───────────── Application Gateway ─────────────┐
 │  ② TLS終端：いったん復号して中身を確認         │
 │  ③ L7ルーティング（パス/ヘッダーで振り分け）    │
 │  ④ 再暗号化：新しいTLSセッションを張り直す       │
 └───────────────────┬───────────────────────────┘
                     │  ⑤ HTTPS（再び暗号化）
                     ▼
              バックエンドサーバー

ポイントは、AGWは「素通し（パススルー）」しているわけではないという点です。①でいったん復号するからこそ、③のL7ルーティングやヘッダー書き換えといった機能が使えます。そのうえで④で暗号化し直すので、両区間ともHTTPSになる——これがE2E TLSです。

設定は「バックエンド設定のプロトコルをHTTPSにする」

E2E TLSを有効にする起点はシンプルで、バックエンド設定（HTTP設定）のプロトコルを HTTP → HTTPS に変えるだけです。これでAGWはバックエンドへHTTPSで接続しにいくようになります。

ただし、AGWは「信頼できるバックエンドとしかHTTPS通信しない」ため、バックエンド側の証明書の扱いに注意が必要です。v2 SKUでは次のようになります（v1の認証証明書は非推奨となり、v2では信頼されたルート証明書に置き換わっています）。

  • 有名なCAが発行した証明書で、そのCNがバックエンド設定のホスト名と一致していれば → 追加設定は不要。プロトコルをHTTPSにするだけでE2E TLSが成立する。
  • Azure App Serviceなどの信頼済みAzureサービスがバックエンドの場合 → こちらも既定で信頼され、追加設定不要。
  • 自己署名証明書や、無名のCAが発行した証明書の場合 → バックエンド設定に「信頼されたルート証明書」をアップロードする必要がある。AGWは、そのルート証明書に連なるバックエンドとだけHTTPS通信する。

もう1つ知っておくと差がつくのが、フロントエンドとバックエンドでTLSバージョンの扱いが違う点です。v2 SKUでは、TLSポリシー（TLSバージョンや暗号スイートの指定）が効くのはフロントエンド側（クライアント↔AGW）のみで、バックエンド側（AGW↔サーバー）は常にTLS 1.3で交渉し、使えなければTLS 1.2にフォールバックします。バックエンドのTLSバージョンは自分では選べない、と覚えておくと混乱しません。

確認は、クライアント↔AGW間・AGW↔バックエンド間の両方がHTTPSであること、そしてバックエンドの正常性プローブが「正常」になっていることを見ます。E2E TLSでは、証明書の信頼関係が崩れているとプローブが失敗し、バックエンドが「異常」と判定されて振り分け対象から外れます。プローブの状態は、証明書設定が正しいかの良いバロメーターになります。

【ここが説明できればOK④】
「バックエンド設定のプロトコルをHTTPSにすると、AGWは復号→ルーティング→再暗号化を行い、両区間がHTTPSになるE2E TLSが構成できる（無名CAや自己署名なら信頼されたルート証明書が必要）」——これを言えれば4つ目のチェックはクリアです。

Key Vault連携でTLS証明書を一元管理する

3つ目のセクションで「Key Vault参照」に触れましたが、ここではその最大の利点である”自動更新”の仕組みを掘り下げます。証明書運用でいちばん怖い事故は「うっかり証明書の有効期限が切れてサイトが落ちる」こと。Key Vault連携は、これを仕組みで防いでくれます。

Key Vault連携とは、AGWがマネージドID（管理された身分証）を使ってKey Vaultから証明書を取得し、更新された証明書を自動で反映する構成です。

連携に必要な3つの要素

  • ユーザー割り当てマネージドID：AGWがKey Vaultにアクセスするための「身分証」。AGWにこのIDを1つ割り当てる。
  • Key Vault側のアクセス許可：そのマネージドIDに、証明書（シークレット）を読む権限を与える。RBACモデルなら 「Key Vault Secrets User」ロール、アクセスポリシーモデルなら Secretの「取得（Get）」権限を付与する。
  • リスナーからの参照設定：HTTPSリスナーで、アップロードではなく「Key Vaultの証明書を選ぶ」を選択する。

自動更新のカギは「バージョンなしのシークレットURI」

自動更新をきかせる最大のコツは、証明書を「バージョンを指定しないシークレットURI」で参照することです。Key VaultのシークレットURIは、末尾にバージョン識別子を付けられますが、これを省いた形で参照します。

# バージョンあり（末尾に長いIDが付く）→ そのバージョンで固定されてしまう


https://myvault.vault.azure.net/secrets/mycert/xxxxxxxxxxxxxxxx
myvault.vault.azure.net


# バージョンなし（末尾のIDを外す）→ 常に最新版を参照＝自動更新される【推奨】


https://myvault.vault.azure.net/secrets/mycert/
myvault.vault.azure.net

バージョンなしで参照しておくと、Key Vault側で証明書が新しいバージョンに更新されたとき、AGWが自動で最新版を取り込みます。その裏側の動きはこうです。

  • AGWの各インスタンスは、4時間ごとにKey Vaultをポーリング（確認）し、証明書の新しいバージョンがあれば取得する。
  • 更新版が見つかると、HTTPSリスナーに紐づく証明書が自動でローテーション（差し替え）される。手動での入れ替え作業は不要。
  • なお、AGWに何らかの変更（リスナーやルール、リソースタグの変更など）を加えると、その時点でもKey Vaultへのチェックが走り、新しい証明書があれば即座に反映される。

「バージョンなしURI＋4時間ごとのポーリング」で自動更新。証明書切れの事故が仕組みで防げるのが、Key Vault連携のいちばんの旨みだね！

1つ注意点として、AGWがKey Vaultにアクセスできなくなると（権限剥奪や証明書の削除など）、該当リスナーが自動的に「無効」状態になることがあります。もし証明書が反映されない・リスナーが落ちるといった場合は、マネージドIDの権限やKey Vaultのファイアウォール設定を疑いましょう。Azure AdvisorやResource Healthに、この種の問題を知らせてくれる仕組みも用意されています。

【ここが説明できればOK⑤】
「マネージドIDでKey Vaultを参照し、バージョンなしのシークレットURIで証明書を設定すると、AGWが4時間ごとのポーリングで更新を自動反映してくれる」——これを言えれば5つ目のチェックはクリアです。

まとめ

今回はApplication GatewayのTLS／証明書に絞って整理しました。この5つを自分の言葉で説明できれば、TLSまわりはバッチリです。

  • TLS終端：HTTPSリスナーにPFX証明書を紐づけ、クライアントとの暗号をAGWで復号する。証明書はチェーン全体を含め、CNをホスト名に合わせる。
  • HTTP→HTTPSリダイレクト：HTTPリスナー(80)にリダイレクト種別のルールを付け、ターゲットをHTTPSリスナー(443)に指定。パス／クエリは含める設定に。
  • 証明書の登録方法：PFX直接アップロード or Key Vault参照（v2のみ）。Key Vault参照はセキュリティ分離・一元管理・自動更新で有利。
  • E2E TLS：バックエンド設定のプロトコルをHTTPSにし、AGWが復号→ルーティング→再暗号化。無名CA／自己署名なら信頼されたルート証明書が必要。
  • Key Vault連携：マネージドID＋バージョンなしURIで、4時間ごとのポーリングにより証明書を自動更新。証明書切れの事故を防げる。

前半（TLS終端）と後半（E2E TLS）の違いは、「暗号化される区間が、AGWまでか／バックエンドまでか」の一点に尽きます。ここを軸に整理すれば、TLSまわりの用語で迷うことはなくなります。

あわせて読みたい

  • 【Azure入門】Application Gatewayとは？L7ロードバランサーの基本（本シリーズ1記事目・概要編）
  • Application Gatewayの作成手順（リスナー・ルール・書き換えの設定）※別記事で解説予定
  • WAF（Webアプリケーションファイアウォール）の仕組みとルール設定 ※別記事で解説予定
  • Azure Key Vaultの基礎（証明書・シークレット・キーの一元管理）
タイトルとURLをコピーしました