Azure Front DoorのmTLS設定では、クライアント証明書を必須にするか、証明書をFront DoorとOriginのどちらで検証するかを最初に決めます。4つのモードから選択でき、Front Doorで検証する構成では、信頼するCAチェーンをAzure Key Vaultに登録し、Custom Domainに関連付けます。2026年9月3日時点では、Azure Front Door Premium向けのPublic Previewです。
取引先や管理端末など、証明書を持つクライアントだけにアクセスを許可したい場合は「必須＋Edge検証」が基本候補です。ただし、証明書の関連付けだけで設定を終えてはいけません。Originへの直接アクセス防止と、証明書なし・不正な証明書を使った拒否テストまで含めて設計しましょう。
Azure Front DoorのmTLSは4つのモードから選ぶ
mTLSは、通常のHTTPSで行うサーバーの確認に加えて、クライアント証明書を使って接続元を確認する仕組みです。Azure Front Doorでは、証明書の提示を必須にするかどうかと、検証を担当する場所を分けて設定できます。ここでいうEdgeはFront Doorのエッジ、Originは背後のアプリケーションやAPIサーバーです。
4つの検証モードの違い
| モード | クライアント証明書 | 証明書の検証担当 | 証明書が提示されない場合 |
|---|---|---|---|
| 必須＋Edge検証 | 必須 | Front Door | 拒否 |
| 必須＋Origin検証 | 必須 | Origin。Front Doorは提示の有無を確認 | 拒否 |
| 任意＋Edge検証 | 任意 | 提示された場合にFront Doorが検証 | Originへ転送 |
| 任意＋Pass-through | 任意 | 提示された証明書をOrigin側で検証 | Originへ転送 |
Microsoftの告知では、それぞれ「Require and validate」「Require without validation」「Validate when presented」「Pass through to the origin」と説明されています。「Origin検証」は、Front DoorがOrigin側の検証処理まで自動構成するという意味ではありません。 アプリケーション側で検証を実装・設定する必要があります。
どのモードを選べばよいか
取引先向けAPIや管理端末専用のサービスでは、まず「必須＋Edge検証」を検討します。証明書による接続制限を入口で完結させ、アプリケーション側では「どの取引先に、どの操作を許可するか」という業務上の認可に集中しやすい構成です。
既存アプリケーションに独自の証明書検証処理があり、その判定を維持したい場合は「必須＋Origin検証」が候補になります。ただし、「証明書が届いたので許可する」という実装では不十分です。信頼する発行元、有効期間、用途、失効状態などをOrigin側で判断できることが前提になります。
「任意」の2モードは、証明書を使わないクライアントも同じ入口で受け付ける設計に向いています。例えば、一般ユーザーにはトークン認証、管理端末には証明書認証を使う場合です。ただし、任意モードでは証明書なしの要求がOriginへ進むため、保護対象のAPIで別の認証・認可が必要かを明確にしてください。
段階導入で任意モードを選ぶ場合は、「いつ必須へ切り替えるか」と「未移行クライアントをどう把握するか」も先に決めておくと、暫定設定の固定化を防げます。
Pass-throughはTLS接続をそのままOriginへ通す機能ではない
Azure Front Doorは、クライアントとのTLS接続をエッジで終端します。OriginへHTTPSで転送する場合は、Front DoorからOriginに対して別のTLS接続を開始します。(Microsoft Learn)
したがって、mTLSのPass-throughは、クライアントとのTLS接続を透過的にOriginまで延ばす機能ではありません。 証明書をHTTPヘッダーでOriginへ渡し、Origin側で利用する方式です。既存システムが「OriginとのTLSハンドシェイクで提示された証明書」を前提としている場合、ヘッダー経由の証明書を扱うための変更が必要になります。
また、このmTLS設定だけでFront DoorからOriginへの接続にクライアント証明書が設定されるわけではありません。クライアント認証と、Front Door―Origin間の通信保護は分けて考えましょう。
設定前に準備する証明書とCAチェーン
HTTPS用証明書とクライアント認証用の証明書を区別する
設定時に混同しやすいのが、Custom DomainのHTTPS用証明書と、クライアント証明書を検証するためのCAチェーンです。
| 証明書・鍵 | 役割 | 主な配置先 |
|---|---|---|
| Custom DomainのHTTPS用証明書 | クライアントが接続先サーバーを確認する | Front Door。マネージド証明書または持ち込み証明書を使用 |
| クライアント証明書と対応する秘密鍵 | クライアントが自身を証明する | 接続する端末やアプリケーション |
| 信頼するCAチェーン | クライアント証明書の発行元を検証する | Key Vaultに登録し、Front Doorから参照 |
Custom DomainのHTTPS証明書にはFront Doorのマネージド証明書を利用できます。一方、mTLSで信頼するCAチェーンは別途用意します。HTTPS用証明書を設定しただけでは、クライアント証明書の信頼設定は完了しません。(Microsoft Learn)
CAチェーンとして登録するのはCAの公開証明書です。CAの秘密鍵や、各クライアントの秘密鍵をFront Doorへ渡す必要はありません。 クライアント側では、証明書とそれに対応する秘密鍵を組み合わせて接続します。(Microsoft Learn)
CAチェーンとクライアント証明書の条件を確認する
プレビューのCAチェーンには、ルートCAと最大3つの中間CAを含められます。形式はPEMで、サイズは25KB未満です。まず、クライアント証明書から信頼するルートCAまでの発行関係がつながる構成を用意してください。(Microsoft Learn)
クライアント証明書では、有効期間だけでなく用途も確認します。拡張キー使用法、いわゆるEKUが存在する場合、クライアント認証用途を含む必要があります。サーバー認証用の証明書を、用途を確認せず流用しないようにしましょう。(Microsoft Learn)
社内CAを使う場合も、発行できれば準備完了ではありません。証明書の配布、秘密鍵の保護、端末紛失時の失効、期限前の更新を誰が担当するかまで決めておく必要があります。
Azure Front DoorでmTLSを設定する手順
以下は、新しいCustom Domainで「必須＋Edge検証」を構成する流れです。既存の公開ドメインを直接変更する前に、検証用のエンドポイントとドメインで動作を確認する進め方が安全です。
Key VaultにCAチェーンを登録する
信頼するCAチェーンをPEMファイルとして用意し、Key Vaultのシークレットへ登録します。Azure CLIでファイル内容を保存する基本例は次のとおりです。<Key Vault名>とファイルパスは実際の値に置き換えてください。(Microsoft Learn)
az keyvault secret set \
--vault-name "<Key Vault名>" \
--name "afd-mtls-client-ca" \
--file "./trusted-client-ca-chain.pem" \
--encoding utf-8--fileと--encodingを使うことで、ファイル内容を指定した文字コードでシークレットに保存できます。登録後は、対象のシークレット名とバージョンを確認します。(Microsoft Learn)
次に、Front DoorのマネージドIDがKey Vaultを読み取れるようにします。Front Doorの［Security］→［Identity］でマネージドIDを有効にし、Key Vault側で読み取り権限を付与します。RBACを使う場合の代表的なロールは「Key Vault Secrets User」です。アクセスポリシー方式では、シークレットのGetとListを設定します。(Microsoft Learn)
登録作業を行う管理者の権限と、Front Doorが実行時に利用する権限は別です。「管理者からはシークレットが見えるのに、Front Doorから読み込めない」場合は、Front DoorのマネージドIDに対する権限を確認してください。
Front DoorにCAチェーンを取り込む
Azure Portalで対象のFront Doorプロファイルを開き、［Security］→［Mutual TLS CA certificates］→［Add］を選びます。先ほど登録したKey Vaultとシークレットを選択し、Front Doorで利用するCAチェーンとして追加します。(Microsoft Learn)
ここで登録するものは、クライアント証明書を検証するための信頼情報です。Custom Domainの通常のHTTPS証明書を追加する操作と取り違えないようにしてください。
mTLS専用のエンドポイントを作成する
［Settings］→［Front Door manager］からエンドポイントを追加し、［Enforce mutual TLS］を有効にします。エンドポイント側のmTLS強制設定は、その配下のルートにmTLSを有効にしたCustom Domainだけを関連付けるための制御です。(Microsoft Learn)
このエンドポイントでは、Front Doorが発行する既定のazurefd.netドメインをルートに関連付けられません。次の手順で作成するCustom Domainを使ってアクセスします。(Microsoft Learn)
Custom DomainにモードとCAチェーンを関連付ける
［Settings］→［Domains］→［Add］でCustom Domainを追加します。［Advanced settings］の［Enable mutual TLS］を有効にし、［Client certificate required and validated］を選択して、登録済みのCAチェーンを関連付けます。(Microsoft Learn)
Edgeで検証するモードでは、信頼するCAチェーンに加えて、証明書失効チェックや許可するFQDNの設定を扱います。API上でも、検証モードとCA参照、許可FQDN、失効チェックは区別された設定項目です。(Microsoft Learn)
SAN/CNによる名前の照合を設定する場合は、クライアント証明書の値と許可リストを整合させます。製品の説明では、Custom Domainのホスト名も許可リストへ明示的に含める必要があります。DNSの所有権確認とは別の設定なので、混同しないようにしてください。(Microsoft Learn)
ドメイン検証、HTTPS、ルートを完成させる
Custom Domainを追加したら、Azure Portalに表示されるDNSのTXTレコードでドメイン所有権を確認します。通常は_dnsauth.<サブドメイン>形式のレコードを使用します。HTTPS用証明書の状態も確認してください。(Microsoft Learn)
その後、作成済みのmTLSエンドポイントにルートを追加し、Custom Domainと適切なOrigin Groupを関連付けます。Originへの転送プロトコルはHTTPSを使用する構成にします。(Microsoft Learn)
DNSのCNAMEを本番向けに切り替える前に、後述するcurl --resolveなどで検証しましょう。ドメイン所有権の確認、ルートへの関連付け、証明書の配置が済んだことを確認してからテストします。
証明書ヘッダーをOriginで安全に扱う
X-Azure-ClientCertificateがあるだけでは検証済みとは限らない
Front DoorがOriginへクライアント証明書を渡す中心的なヘッダーは、X-Azure-ClientCertificateです。Edgeで検証するモードだけでなく、Front Doorでは検証せずOriginへ渡すモードでも使用されます。したがって、ヘッダーの存在だけを「Front Doorで検証済み」の証拠にしてはいけません。
Origin側の処理は、採用したモードに合わせて設計します。Edge検証を前提とする構成では、信頼できるFront Door経由の要求であることを確認したうえで、証明書の識別情報を登録済みクライアントや権限に対応付けます。Origin検証の構成では、受け取った証明書の検証自体もOrigin側の責任です。
例えば、信頼するCAが発行した証明書でも、契約終了済みの取引先に発行したものかもしれません。証明書の信頼性を確認する処理と、現在そのAPIを使わせてよいかを判断する処理は分けておくと、アクセス制御を整理できます。
クライアントが手動で付けたヘッダーを認証に使わない
Front Doorは、クライアントから送られたX-Azure-ClientCertificateなどの予約された証明書関連ヘッダーを削除します。クライアントは証明書文字列をHTTPヘッダーへ手動で追加するのではなく、TLS接続で証明書を提示する必要があります。(Microsoft Learn)
アプリケーションの検証でも、「TLSで証明書を提示した要求」と「証明書らしいヘッダーだけを送った要求」を区別してください。ヘッダーの解析に成功することと、接続元を認証できたことは同じではありません。
Originへの直接アクセスを防ぐ
Originがインターネットから直接アクセスできるままだと、Front Doorを経由しない要求でアプリケーションを呼び出される可能性があります。
公開Originでは、AzureFrontDoor.Backendサービスタグによる接続元制限と、X-Azure-FDIDが自分のFront DoorプロファイルのIDに一致することの確認を組み合わせます。Front DoorのIPアドレス範囲は他の利用者とも共有されるため、IP制限だけでは自分のFront Doorからの要求に限定できません。(Microsoft Learn)
対応するOriginではPrivate Linkも選択肢です。どちらの方式でも、「正規のFront Doorを通った要求だけを信頼する」という境界を作ってから証明書ヘッダーを利用します。(Microsoft Learn)
curlでmTLSの成功と拒否を確認する
DNS切り替え前にCustom Domainで接続する
以下は、BashとOpenSSLを利用するcurlで、PEM形式の証明書を使う例です。HOST、AFD_IP、証明書ファイル、APIのパスは実際の環境に置き換えてください。
client-fullchain.pemにはクライアント証明書と必要な中間証明書を、client.keyには対応する秘密鍵を用意します。curlの証明書形式や秘密鍵の扱いはTLS実装によって異なるため、WindowsのSchannel版などでは同じ指定をそのまま使えるとは限りません。(Curl)
HOST="mtls-api.example.com"
AFD_IP="<Front DoorエンドポイントのIPv4アドレス>"
# クライアント証明書を提示する
curl -sS -i \
--resolve "${HOST}:443:${AFD_IP}" \
--cert-type PEM \
--cert "./client-fullchain.pem" \
--key "./client.key" \
-H "X-Azure-DebugInfo: 1" \
"https://${HOST}/api/ping"
# クライアント証明書を提示しない
curl -sS -i \
--resolve "${HOST}:443:${AFD_IP}" \
-H "X-Azure-DebugInfo: 1" \
"https://${HOST}/api/ping"--resolveは、指定したホスト名とポートに対して接続先IPを指定する機能です。URLはCustom Domainのままにします。IPアドレスのURLへアクセスしてHostヘッダーだけを書き換える方法とは異なります。(Curl)
サーバー証明書の検証を無効にする-kは付けずに確認してください。mTLSの検証と同時に、通常のHTTPS接続も正しく成立していることを確かめます。
正常系だけでなく拒否されるケースも試す
「必須＋Edge検証」を採用する場合の検証計画例です。
| テスト | 確認する結果 |
|---|---|
| 許可したCAが発行した有効な証明書を提示 | Originへ到達し、アプリケーションが想定する応答を返す |
| 証明書を提示しない | 保護対象の処理へ到達できない |
| 信頼していないCAの証明書や期限切れ証明書を提示 | 保護対象の処理へ到達できない |
| 証明書を提示せず、証明書ヘッダーだけを付ける | 認証済みクライアントとして扱われない |
| Front Doorを経由せずOriginへ直接アクセス | アクセス制限により拒否される |
これは、証明書必須・Edge検証という動作と、Origin保護を組み合わせて確認するためのテストです。任意モードでは「証明書なし」の期待結果が変わるため、採用モードに合わせて判定基準を調整します。
成功判定をHTTP 200だけに限定する必要はありません。業務APIが追加の認証を要求する設計なら、その認証がない状態で処理が完了しないことも想定内です。「Front Doorで拒否されたのか」「Originまで届いて業務上の判定を受けたのか」を分けて確認しましょう。
403が返る場合はデバッグヘッダーで切り分ける
要求にX-Azure-DebugInfo: 1を付けると、mTLS関連の403について、応答のX-Azure-ExternalErrorに原因を示す値が返される場合があります。代表例は次のとおりです。(Microsoft Learn)
| エラー値 | 最初に確認する点 |
|---|---|
ClientCertMissing | クライアントがTLS接続で証明書を提示しているか |
ClientCertExpired | 証明書の有効期限が切れていないか |
ClientCertRootCAUntrusted | 正しいCAチェーンを対象ドメインに関連付けたか |
ClientCertIncorrectPurpose | 証明書の用途がクライアント認証に適しているか |
これらはFront DoorのmTLS診断用に説明されているエラーです。まず証明書の未提示、期限、信頼するCA、用途の順に確認すると、問題を整理しやすくなります。(Microsoft Learn)
Originが返したステータスの確認にはX-Azure-OriginStatusCode、アクセスログとの突き合わせにはX-Azure-Refも役立ちます。403というステータスだけで、すべてをmTLS設定の問題と判断しないようにしてください。(Microsoft Learn)
本番移行で見落としやすい制約
mTLSを有効にしたルートではキャッシュを使えない
プレビューでは、mTLSを有効にすると、ルートのキャッシュや、キャッシュを有効にするルールエンジンのルート上書きを利用できません。既存のキャッシュ配信を前提としているサービスは、設定変更前に影響を確認してください。(Microsoft Learn)
例えば、一般公開の静的コンテンツと証明書必須のAPIを同じ構成へまとめるよりも、公開用とmTLS用で入口を分ける設計のほうが、キャッシュと認証の責任範囲を整理しやすくなります。
既存ドメインの有効化・無効化には停止を伴う
既存ドメインでmTLSを有効化する場合、ルートやエンドポイントとの関連付けを変更する必要があり、Microsoftはダウンタイムが発生すると説明しています。無効化する場合も、関連付けの解除と再構成が必要です。(Microsoft Learn)
切り戻しを「mTLSのチェックを外せば即座に元通り」と考えないことが重要です。現在のルート構成、DNSの向き先、証明書、Originのアクセス制限を記録し、変更前の状態へ戻す手順を用意してください。
CAチェーンの更新を自動ローテーション任せにしない
mTLS用CAチェーンは自動ローテーションに対応していません。一方、Edge検証の設定では2つのCAチェーンを関連付けられるため、更新時に旧CAと新CAを併用する構成を取れます。(Microsoft Learn)
通常の計画更新では、新CAを追加し、新CA発行のクライアント証明書で接続を確認してから、クライアント側を移行します。旧証明書の利用がなくなったことを確認した後、旧CAを信頼設定から外す流れにすると、切り替えを管理しやすくなります。
ただし、CAの侵害や秘密鍵の漏えいが疑われる場合は、通常の更新と同じ長い併用期間を設けない判断が必要です。可用性のための切り替え手順と、信頼を緊急に停止する手順は分けて用意しましょう。
社内CAでは失効確認の方式も合わせる
Front Doorのクライアント証明書の失効確認はOCSPを使用し、既定で有効です。CRLだけを運用している社内CAでは、既存の失効確認方式がそのままFront Doorで使われるとは考えないでください。(Microsoft Learn)
CAの選定時には、証明書に設定する失効確認情報と、実際に失効させた証明書での拒否テストまで確認します。接続できない問題を解決するために失効チェックを無効化する前に、CA側の運用と要件を見直しましょう。
まずは「必須＋Edge検証」で拒否テストまで完了させる
Azure Front DoorのmTLS設定は、証明書を関連付ける操作よりも、「誰が検証し、どこでアクセスを拒否するか」を決めることが重要です。
証明書を持つクライアントだけに公開したいサービスでは、まず検証用ドメインで「必須＋Edge検証」を構成します。そのうえで、有効な証明書による接続、証明書なしの拒否、不正な証明書の拒否、Originへの直接アクセスの拒否を確認してください。
これらのテストを通し、CA更新と切り戻しの手順を用意してから本番へ移行すると、設定直後だけでなく、証明書の更新や端末の入れ替えにも対応しやすい運用になります。
コメント