証明書の更新完了は、利用者が接続する経路で新しい証明書を確認し、業務に必要な通信が成功した時点で判断します。Key Vaultへの登録完了や、Azure Portalの操作成功だけでは、作業を閉じられません。

実際の公開相談には、証明書のValidateは通るのにAddで落ちる、同じKey Vaultの更新をApp Serviceは認識したのにFront Doorは旧版を選ぶ、という報告があります。¹² 画面が一部成功しているぶん、何をやり直せばよいか分からなくなる状況です。

以下では、設定ミスと配備待ちを切り分け、サポートへ渡す記録まで具体化します。

App Service、Azure Front Door、Key Vaultを組み合わせると、発行、保管、取り込み、バインド、配信が別々の処理になります。その途中で止まっても、古い証明書が有効な間は障害として表れないことがあります。

更新前に確認するのは次の五点です。

App Serviceのマネージド証明書、有料のApp Service Certificate、持ち込み証明書を区別する。
Front Doorの入口と、Front Doorからオリジンへの接続を別々に確認する。
Key Vaultの新バージョンと、各サービスが参照・配信するバージョンを照合する。
自動更新の条件となるDNS、権限、ネットワーク設定も変更管理の対象にする。
期限監視と、利用者側からのTLS・HTTP監視を併用する。

仕様確認日：2026年10月26日（JST）。対象は主にAzureパブリッククラウドのApp ServiceとAzure Front Door Standard / Premiumです。Front Door classicの手順は扱いません。価格、対応条件、画面、CLIは変わりうるため、作業時は最新の公式資料を確認してください。

「公開相談」は利用者本人の投稿の要約です。投稿で確認できた経過と、公式資料に基づく仕様を分けています。「説明例」と記した場面や報告文は架空であり、筆者の経験談ではありません。

1. 証明書を一枚更新しても、確認する場所は一か所ではない

次の構成を考えます。

破線は、持ち込み証明書を利用する場合の取り込み関係です。すべての構成で、両方のサービスに同じKey Vault証明書を設定する必要があるわけではありません。

確認対象	接続・処理	調べる内容
公開側TLS	利用者からFront Door	公開FQDNに合う証明書、信頼、有効期間
オリジン側TLS	Front DoorからApp Service	オリジン接続名に合う証明書、信頼、チェーン
証明書の保管	Key Vault	更新版の存在、バージョン、有効状態
サービスへの取り込み	Key Vaultから各サービス	読み取り権限、ネットワーク、同期・配備状況
アプリ内利用	アプリから外部APIなど	アプリがロードしている証明書、選択方法、外部側の登録

Front Doorは利用者側のTLSを終端し、HTTPS転送ではオリジンへ別のTLS接続を作ります。公開側が正常でも、オリジン側の証明書に問題があれば、アプリへの到達は失敗します。³

「ブラウザーの証明書は新しくなっています」という報告に対して、確認したFQDNと接続経路を聞き返せる手順書が必要です。

2. 「Azureの証明書」を一括りにしない

2.1 選択肢と、自動化される範囲

方式	主な用途	更新・反映の扱い	選ぶ条件と負担
App Service Managed Certificate（ASMC）	App Serviceのカスタムドメイン	前提条件を満たす限り、更新と関連バインドの更新を管理	証明書自体は無料。非エクスポートなどの制限あり
有料のApp Service Certificate（ASC）	Azureで購入する証明書	更新設定、ドメイン再検証、Key Vaultへの保存、App Serviceへの同期を管理	証明書購入費と関連運用が必要
App ServiceへのKey Vault証明書インポート	自社で発行・調達する証明書	Key Vault更新後の自動同期に対応	発行元との更新処理と取り込み経路を管理
App ServiceへのPFX直接アップロード	手動配布など	新しいPFXのアップロードとバインド更新が必要	導入は単純でも、配布先が増えると手作業が増える
Front Doorのマネージド証明書	Front Doorの公開カスタムドメイン	Front Door側で更新。DNS等の条件を維持する	証明書の発行・配布作業を減らせる
Front DoorのBYOC	指定CAや持ち込み証明書	Key Vaultを参照。Latestとバージョン固定で挙動が異なる	CA、Key Vault、権限、反映確認を管理

各方式の条件は、App Serviceの証明書管理資料⁴、有料ASCの管理資料⁵、Front DoorのHTTPS構成資料⁶で確認できます。

無料のASMCは、ワイルドカード、エクスポート、プライベートDNSには対応していません。無料であることだけを理由に、別サービスへの配布や閉域ドメイン向けの証明書として設計すると成立しません。⁴

要件に合うならマネージド証明書を使い、持ち込みが必要な箇所を絞ると、発行・配布の手作業を減らせます。CAの指定や他製品への配布が必要な場合はBYOCを検討します。DNSを他社が管理する場合も、マネージド証明書の検証に必要な変更を依頼できるか確認します。

費用は証明書代だけでなく、Key Vault、監視・通知、作業・レビュー時間を含めて比較します。Front Doorなどのサービス利用料は別途必要です。価格は最新の公式料金で確認してください。

2.2 2026年は「一年分を購入したから一年間触らない」が危ない

Microsoftの2026年10月15日更新資料では、ASCは2026年3月から有効期間198日の証明書を発行し、購入期間をカバーするよう重複期間のある証明書を自動発行すると説明されています。購入期間と、一枚の証明書のNotAfterは別に記録してください。⁷

また、ASCのドメイン再検証は自動ではありません。必要な再検証を完了しないと、注文がPending issuanceのままになり、発行・更新に失敗する可能性があります。⁵⁷

特に確認したいのは、エクスポートしたPFXを別環境へ配っている構成です。エクスポートしたコピーはApp Serviceの自動同期対象ではなく、更新版の再配布が必要です。⁵

年間契約の更新予定だけをカレンダーに入れているなら、実際に配信中の証明書のNotAfterを起点に予定を組み直します。

3. 公開相談から考える落とし穴――権限を付ける主体を取り違える

2025年10月30日（UTC）にMicrosoft Q&Aへ投稿された相談では、Web App側に複数のKey Vault関連ロールを付けても、Key Vaultから証明書を追加できない状況が報告されています。直接アップロードでは使え、Key Vault経由の追加でアクセスエラーになる、という内容でした。¹

追加投稿を読むと、困り方が具体的です。11月3日には、証明書のValidateは通り、その後のAddで失敗すると説明されています。11月5日には、Web AppのマネージドIDにKey Vault Certificate Userを追加して再試験しても、同じアクセスエラーになったと報告されています。さらに11月10日には、Front Doorへは取り込めるのにWeb Appへは取り込めない、と状況が補足されています。日付はいずれもUTCです。¹

証明書の検証は通り、ロールを追加しても同じアクセスエラーが続いています。この相談の最終的な解消結果は確認できません。回答欄の案を、解決済みの手順としては扱いません。

現行のApp Service公式資料では、Key Vaultから証明書を取り込む主体はApp Serviceリソースプロバイダーです。⁴

操作ごとのアクセス主体と必要な権限は次のとおりです。

操作	Key Vaultにアクセスする主体	RBAC利用時の確認例
App ServiceのTLS証明書取り込み	App Serviceリソースプロバイダー	Key Vault Certificate User
有料ASCの保存・更新	証明書登録側のリソースプロバイダー	Key Vault Secrets Officer
Front DoorのBYOC取り込み	Front Doorに設定したマネージドID	Key Vault Secrets User
アプリコードからのKey Vault読み取り	コードで使う資格情報。マネージドID利用ならそのID	読み取るオブジェクトと操作に合う権限

表の権限は、App Serviceの証明書取り込み手順⁴、有料ASCの保存・更新手順⁵、Front DoorのマネージドID構成手順⁸に基づいています。これらを同じ主体として扱わないでください。

有料ASCには、Key Vaultへの保存・更新を担う証明書登録側の主体もあります。Web Appへの取り込み権限だけを残して、保存・更新に必要な権限を削除してよいわけではありません。⁵

権限を追加する前に、失敗した操作、呼び出し主体、対象、アクセス経路を記録します。

操作：Key VaultからApp ServiceへTLS証明書を取り込む
主体：App Serviceリソースプロバイダー
対象：運用台帳に記録したKey Vaultと証明書
権限モデル：Azure RBAC
ネットワーク：証明書取り込みに利用する経路の許可を確認

「Web Appには十分な権限がある」という調査結果だけでは、この操作の権限確認は終わりません。

ValidateとAddのどちらで止まったかも記録します。一部の検証成功から、後続の取り込み主体やネットワークまで正常と判断しないためです。調査目的で権限を追加した場合は、変更内容を残し、原因を確認した後で不要な付与を戻します。

なお、IaCでロール割り当てを作る場合は、アプリケーションIDと、そのテナントのサービスプリンシパルのオブジェクトIDを混同しないようにします。App Serviceの公式資料にも注意書きがあります。⁴

4. 公開相談：App Serviceは新しい版、Front Doorは古い版

2026年1月20日（UTC）のMicrosoft Q&Aでは、セキュリティ上の変更に伴ってKey Vaultの証明書を更新し、旧版を無効化した担当者が、Front Doorが旧版を選び続けると報告しています。同じ投稿では、App Serviceは新しい版を認識したとも説明されています。²

さらに、マネージド証明書へ一時的に切り替えてBYOCへ戻すとアクセスエラーになり、旧版を再び有効化すると操作は通るものの、旧版が選ばれたままだった、と記しています。これは投稿者の観測です。旧版を再有効化する操作を、一般的な復旧策として勧めるものではありません。

回答欄には、対象ドメインの再作成と配備待ちで解消したという、投稿者が承認した回答があります。² ドメイン削除は、ルートやWAFとの関連付け、再検証、DNS作業にも影響します。最初に試す操作にはせず、既存Secretの参照と配備状況から確認します。

App Serviceの更新成功だけでは、Front Doorの更新完了を確認したことになりません。次の三つを照合します。

Key Vaultの更新版が、どの証明書名のどのバージョンにあるか。
Front Doorのカスタムドメインが、どのFront Door Secretを参照しているか。
そのSecretがLatestか、特定バージョン固定か。

4.1 Latestとバージョン固定の選び方

Front DoorのBYOCは、Latestを選ぶとKey Vaultの新しい版への自動ローテーションに対応します。特定バージョンを選んだ場合、新しい版への変更を自分で実施する必要があります。⁶

参照方式によって、更新版を登録した後に必要な操作が変わります。

選択	利点	運用上の負担	適する条件
Latest	版変更の手作業を減らせる	更新版を登録した時点で、取り込み対象になることを想定する	登録前検証と反映後監視がある
特定バージョン	本番へ入れる版を明示できる	版変更の実施忘れが期限切れにつながる	自動化された昇格処理や厳密な変更管理がある

Latest運用では、本番の参照名へ登録する前にSANや形式を検証します。登録後に配布先が取り込むことを前提に、更新版の登録権限も管理してください。

また、参照先がsite-tlsなら、別名のsite-tls-nextを作っても、その名前を追従する設定にはなりません。同じ名前の新バージョンを作るのか、参照先を切り替えるのかを手順書に明記してください。

4.2 Front Doorへの持ち込み条件を先に確認する

確認日時点の公式資料では、次の条件があります。⁶⁹

Key VaultはFront Doorプロファイルと同じサブスクリプションに置く。
証明書はPFX形式で、Key VaultのCertificateオブジェクトとして取り込む。
PFXとして対応する秘密鍵を取得できることを確認する。非エクスポートの鍵では、Secretを取得しても秘密鍵は含まれない。¹⁰
Secretだけを作る手順と混同しない。
EC暗号の証明書はFront Doorの持ち込み証明書としてサポートされない。
対象名の一致、必要な中間証明書、信頼されるCAを確認する。

Key VaultのCertificateには、公開証明書のメタデータと、対応するKey・Secretが関連付けられます。¹¹ 公開証明書を読めることと、秘密鍵を含むPFXを取り込めることは別です。秘密鍵を取得できるロールの付与先とスコープも確認してください。

Front Doorの設定画面にある「Secret」、Key Vaultの「Secret」、Key Vaultの「Certificate」は同じものを指す言葉ではありません。会話で「シークレットは更新済み」と報告されたら、リソース名とIDまで確認します。

4.3 自動反映の時間には公式資料でも記載差がある

2026年10月26日時点では、Front Doorの公式資料に次の差があります。

公式資料	BYOCの反映についての記載	資料更新日
Domains in Azure Front Door	自動配備に最大72時間	2026年7月9日
TLS encryption with Azure Front Door	自動ローテーションに3〜4日	2026年8月1日
TLS encryption with Azure Front Door	特定版を選び直す場合の配備に最大24時間	2026年8月1日

上表はDomains資料⁹とTLS資料³の記載を比較したものです。この差を解消する統一的な保証時間は、今回確認した資料からは確認できません。

したがって、期限前日の更新を前提にした手順にはしません。通常の計画では配備待ちに4日程度の枠を置き、CA側の発行、承認、休日、再試行の余裕を別に確保する、というのが本記事の運用提案です。4日での完了保証を示すものではありません。

Latestと特定版の方式を変更するときは、Domains資料では新しい証明書の追加が案内されています。現行設定を削除してから作り直す手順にせず、新しいFront Door Secretを用意し、対象ドメインとの関連付けを計画します。⁹

4.4 「反映待ちです」で止めず、待つ条件と期限を書く

次は調査の分岐例です。V1・V2は説明用の版名で、実際のバージョンIDではありません。

観測結果	次に行うこと	ここで判断できないこと
Key VaultにV2があり、Front DoorはV1固定	意図した固定か確認し、更新対象のSecret・ドメイン関連付けを変更計画へ載せる	待てば固定が解除されるとはいえない
Latestだが参照元の証明書名が別	更新した名前と実際の参照先を照合する	Latestという表示だけでは参照先の正しさを証明できない
参照は意図どおりだが、取得・配備エラーがある	主体、権限、ネットワーク、証明書要件を調べる	時間経過だけで直るとはいえない
参照は正しく、配備中で、通信は旧版	残存時間と利用者影響を確認し、次の観測時刻を決める	反映完了時刻の確約はできない
配備完了表示でも特定の監視点だけ異常	時刻、接続先IP、証明書、地域・経路をそろえて比較し、サポートへ渡す	一台のPCの成功で他地域の障害は否定できない

旧版の無効化は、Front Door全体から旧版が消えた証拠にはなりません。旧版の退役と、各配布先での反映確認は別の作業として扱います。¹²²

たとえば残り18時間なのに、手動配備について最大24時間という資料を根拠に「明日まで待つ」と判断するのは、期限内に戻せる計画になっていません。これは架空の数値例です。待つ場合にも、残時間、次回確認時刻、改善がなければ誰へ引き上げるかをセットにします。

新しい証明書の発行、ドメイン再作成、HTTPSの無効化・再有効化を次々に試すと、どの変更が効いたのか分からなくなります。現在値を保存し、変更単位を分けます。公式トラブルシューティングでは、Front Door Secretを新たに作り、対象ドメインへ関連付ける経路も示されています。¹²

5. 公開相談：表示上の期限は残っていたのに、本番APIが止まった

2026年8月13日（UTC）の公開相談では、ASCを使うFunction Appの担当者が、8月15日という期限表示に対して、8月7日から本番HTTPSクライアントに拒否されたと報告しています。投稿上の発生日と表示期限の差は8日です。¹³

担当者によれば、Rekey／再発行を開始して更新版は存在していたものの、本番の切り替えは低トラフィックの時間帯に行う予定でした。緊急対応ではSyncだけでバインドが移らず、更新版をFunction Appへ取り込み、SNIバインドを更新した後にAPIが復旧した、と記しています。¹³

期限前に拒否された原因や失効の有無は、この公開相談からは確認できません。記載されているのはFunction Appの個別事例です。

復旧手順と原因調査は分けて記録します。この報告でも、バインド更新後の復旧は記されていますが、それだけで期限前に拒否された原因は特定できません。

証明書の登録、カスタムドメインへのバインド、実際のクライアント接続を別々に確認します。

5.1 Key Vault経由とPFX直接アップロードを分ける

App Serviceの公式資料では、Key Vaultからインポートした証明書は更新後24時間以内に自動同期され、該当するバインドも更新されると説明されています。手動で同期する場合は、Certificatesの持ち込み証明書一覧から対象を選び、Syncを実行します。⁴

対して、直接アップロードしたPFXには、更新版をアップロードしただけでバインドも更新される仕組みはありません。⁴

直接アップロードの更新は、次の順序にします。

新しいPFXをアップロードする。
Custom domainsで対象FQDNのUpdate bindingを選ぶ。
新しい証明書へ更新する。
TLS接続とアプリの動作を確認する。
利用箇所と切り戻し期間を確認し、旧証明書を整理する。

App Serviceへ取り込んだ秘密鍵付き証明書は、同じデプロイ単位（webspace）のアプリ間で共有されます。公式資料では、リソースグループ・リージョン・OSの組み合わせでこの単位が決まると説明されています。⁴ 削除前には、今回作業したアプリ以外のバインドやアプリ内利用も確認します。

公式手順も、新しい証明書へのバインド更新を先に行う構成です。既存バインドの削除を先に行うと、IPアドレス変更やHTTPSエラーによる停止につながる可能性があります。⁴

「一覧に新しい証明書がある」と「対象FQDNに新しい証明書が結び付いている」を、同じチェック欄にしないでください。

5.2 アプリ内利用は別の確認が必要

アプリが外部API認証などに証明書を使う場合、受信HTTPSが正常でも、その用途が正常とは限りません。

WEBSITE_LOAD_CERTIFICATESはアプリコードへ証明書を公開する設定です。Key Vault経由の更新では日次同期による設定更新も説明されていますが、アプリコードや独自設定に固定した古いthumbprintまで自動で書き換える意味ではありません。¹⁴

アプリ内で長期間保持する証明書オブジェクト、独自の選択処理、接続先へ登録した証明書も確認対象にします。再起動の要否は、このロード方法を調べて判断します。

また、2026年の公開TLS証明書の変更では、クライアント認証EKUの削除も案内されています。サーバーHTTPS用とクライアント認証用を兼用している構成は、更新前に用途を分けて確認してください。¹⁵

6. 切り分け例：入口の証明書は正常なのに502

Front Doorの公開FQDNは新しい証明書でTLS接続できる。それでもアプリの画面は502。App Serviceを再起動しても改善しない――という説明例です。

この場合、まずFront DoorからオリジンへのTLSを調べます。

Microsoftのトラブルシューティング資料にも、オリジンの名前不一致や中間証明書不足によって、Front Door経由だけ502になるケースが挙げられています。¹⁶

確認項目	見落としやすい点
Origin hostname	接続先として設定したFQDNは何か
SNIと証明書名	その接続名で期待する証明書が返るか
SAN	更新で必要な名前が落ちていないか
チェーン	オリジンが必要な中間証明書も返すか
Origin host header	HTTPのHostがアプリの受け付ける名前か
ヘルスプローブと実リクエスト	プロトコル、パス、期待応答が適切か

ブラウザーでオリジンを直接開けても、送信されたチェーンが完全だとは断定できません。ブラウザーがチェーンを補完し、問題が見えにくくなる場合があることも公式資料で説明されています。¹⁶

証明書名チェックを無効にして終了する手順は推奨しません。接続先の名前と証明書の関係を直します。公式TLS資料も、セキュリティ上、このチェックを無効にしないよう注意しています。³

構成を簡素化できるなら、公開カスタムドメインはFront Doorで管理し、オリジンはApp Serviceの既定ホスト名とそのTLSを使う案も検討できます。ただし、Hostの扱いはアプリのリダイレクト、Cookie、認証に影響するため、証明書の枚数だけで決めないでください。元のホスト名を保持する設計も公式に説明されています。¹⁷

6.1 トップページの200だけでは、オリジンの復旧を確認できない

Front Doorがキャッシュから応答できる構成では、静的なトップページが200でも、その一回の結果でオリジンへの接続成功を証明できません。運用では、キャッシュを無効にした確認用パスと、そのパスを処理したオリジンのログを使う案を検討します。¹⁸

URLの末尾へ毎回違うクエリを付ける方法も、クエリ文字列を無視するキャッシュ設定なら同じキャッシュキーになりえます。¹⁸ 確認用パスに対するルート・ルールセットの実効設定を見ます。

Front DoorのヘルスプローブはHTTP・HTTPS、GET・HEADを選べます。¹⁹ HTTPプローブの成功ではオリジン側TLSを検証できず、HEADだけ通るパスでは実際のGETまで確認できません。プローブの成功と、利用者の重要な処理の成功を分けて記録します。

7. DNSとネットワークの変更は、次回更新に効いてくる

7.1 Front Doorのマネージド証明書はDNS経路を確認する

Front DoorのTLS資料では、カスタムドメインのCNAMEがFront Doorエンドポイントへ直接向く場合の自動ローテーションが説明されています。間接CNAMEでは検証成功が保証されず、BYOCの利用が案内されています。³

「いまHTTPSで開く」という試験だけでは、次回の所有確認が通るかは分かりません。

DNS変更を別会社が担当するなら、再検証が必要になったときの依頼先、実施できる時間帯、更新するTXT値の受け渡し方法を決めます。古いTXT値を残すだけでは、新しい検証要求を満たせない場合があります。⁹

公開相談：Azure側の担当だけでは復旧を完結できなかった

2026年8月6日（UTC）の相談には、Provisioning StateがSucceeded、Validation StateがApprovedなのに、Certificate StateがExpiredと表示され、SSL検証に問題が出たという報告があります。²⁰

翌7日、投稿者はドメインを再作成し、新しく発行されたTXT値を顧客へ渡し、顧客によるDNS更新と検証の完了後にHTTPSが復旧したと報告しています。再作成前には、ルート、エンドポイント、WAFとの関連も外したと記しています。²⁰

この事例では、Azure側の操作後に顧客のDNS作業を待っています。ドメインを再作成する前に、関連付けの復元手順とDNS担当者の作業時間を確保する必要があります。再作成の要否は、現在の状態と公式手順を確認して判断します。

DNS担当への依頼には、次を含めます。これは依頼項目の例です。

対象FQDNと、変更するDNSゾーン：
レコード種別と完全なレコード名：
Front Doorが今回発行したTXT値：
既存値の追加・置換など、今回必要な変更内容：
依頼日時、対応希望時刻、作業担当と代理担当：
作業後に返してほしい権威DNSでの応答と確認時刻：
Azure側で検証完了を確認する担当：

「TXTを入れました」という連絡だけで作業を閉じず、対象ゾーン・名前・今回の値が一致することと、Front Door側の検証結果を確認します。検証トークンのRegenerateを繰り返すと、依頼済みの値と現行値がずれるため、誰が再生成したかも共有します。

App ServiceのASMCは、Front Doorとは別の発行・更新条件を持ちます。DNSや到達性は、ASMC向けの最新資料で確認してください。⁴

7.2 Key Vaultの権限とネットワークは別々に確認する

ロールを付けても、必要な経路が拒否されれば取り込みは成功しません。反対に、ネットワークを許可しても、データ操作の権限は必要です。

Key VaultのTrusted services例外は、すべてのAzureサービスや、サービス上のすべての処理を通す設定ではありません。App Serviceについても、証明書配備の用途と、アプリコードからのアクセスを区別する必要があります。²¹

確認日時点の資料では、Trusted servicesのバイパスはpublicNetworkAccess=Disabledでも適用されます。一方、publicNetworkAccessをSecure by perimeterに設定する構成では、そのバイパスは上書きされ、明示的なペリメーターのアクセスルールが必要と説明されています。²²

したがって、「Private Endpointがあるから取り込みも通る」「公開アクセス無効だから必ず取り込めない」という一行の判断は避けます。設定した権限モデルとネットワーク制御に沿って、そのサービスの証明書取り込み経路を試験します。

運用上の変更試験には、少なくとも次を入れます。

Key Vaultの権限モデルやネットワークを変えた後、新しい版の取り込みを検証する。
既存サイトが表示できることだけで変更を完了にしない。
本番更新を待たず、検証用の証明書・ドメインで次回更新までの流れを試す。

変更後も既存サイトが表示できることと、更新版を取り込めることは、別々に試験します。

8. 監視は「保管中」「設定中」「配信中」の三つを突き合わせる

8.1 期限通知だけでは旧証明書の配信を見逃す

Key Vaultには新しい証明書がある。しかし、Front Doorが旧版に固定されている。この状態では、新しい版の期限だけを監視しても利用者側の危険を捉えられません。

監視には、次の三層を用意します。

層	取得する情報	検知したい状態
保管側	Key Vaultの名前、バージョン、NotAfter、有効状態	更新未実施、発行失敗、対象名の誤り
設定側	App Serviceのバインド、Front DoorのSecret参照・配備状態	旧版固定、参照先違い、更新未反映
通信側	公開・オリジンのTLSとHTTP、配信証明書	期限不足、名前・信頼の問題、業務通信失敗

監視経路も台帳に記録します。HTTPSを復号・再暗号化するTLS検査経路では、接続先が提示した証明書と、監視端末が受け取る証明書が異なる場合があります。公開側は検査の有無が分かる監視点、閉域オリジンは必要な名前解決と到達性を持つ監視点で確認します。

8.2 Event Gridは有効。ただし配信完了通知とは違う

Key Vaultの公式イベントには次があります。²³

イベント	意味
`Microsoft.KeyVault.CertificateNewVersionCreated`	Certificateの作成・新バージョン作成
`Microsoft.KeyVault.CertificateNearExpiry`	現在のCertificateバージョンの期限30日前
`Microsoft.KeyVault.CertificateExpired`	現在のCertificateバージョンが期限切れ

30日前はこのイベントの仕様であり、この記事で決めた通知間隔ではありません。任意の45日・14日・7日前通知が必要なら、別途定期確認を実装します。

Certificateイベントだけで、Secretとして保管されている対象もすべて監視できるとは扱わないでください。Secret用イベントもあり、実際の保管オブジェクトに合わせて購読します。²³

新バージョンイベントを受けた後は、更新確認タスクを起票し、各配布先の反映確認へ進めます。イベント受信だけでタスクを完了させません。

Event Gridは少なくとも一回の配信を試み、順序も保証しません。処理は重複や順不同に耐えるようにし、再試行やデッドレターも設計します。²⁴ 導入時には既存証明書を棚卸しし、イベントが届かなかった場合にも定期照合で検出できるようにします。

Key VaultのCA連携による自動更新も、持ち込み証明書を置くだけで成立するわけではありません。統合CAの構成、非統合CA、インポートを区別し、発行元から新しい版を得る処理を確認します。²⁵

8.3 通知基準の提案

次は運用設計例です。Azureの一律の保証・推奨値ではありません。

残日数・状態	通知・対応の例
45日前	BYOCの発行手続き、担当、DNS依頼先、変更枠を確認
30日前	更新計画と進捗を点検。新しい版があれば反映差分を確認
14日前	計画未達を担当者と副担当へ通知し、復旧時間を再計算
7日前	未反映なら通常の更新作業から障害予防対応へ引き上げる
3日前	即時対応。サポート連絡、切り戻し可否、事業影響を判断
TLS検証失敗・期限切れ	残日数の段階を待たずインシデントとして通知

マネージド証明書は、サービスの更新開始時期に合わせて判定を変えます。正常な自動更新を毎回「45日前なのに未更新」と警告すると、通知が読まれなくなります。

Front Door Standard / Premiumのマネージド証明書については、残存期間が30日未満の場合にサポートへ問い合わせるよう、公式TLS資料に案内があります。³

通知には、FQDN、接続区間、残時間、配信中の証明書、期待する版、作業チケット、担当と副担当を含めます。通知を受けた人が対象を探し直さずに済む内容にします。

9. 確認コマンド：参照先と配信結果を照合する

以下のAzure CLIは読み取り用の例です。Azureへのログイン、対象サブスクリプションの確認、必要な参照権限を前提とします。Key Vaultのデータ取得には実行元からの到達性も必要です。

本記事のAzureコマンドは公式リファレンスと照合していますが、Azure実環境では実行検証していません。CLI・拡張機能の版で出力差がある場合は、まずJSON全体と現行ヘルプを確認してください。²⁶²⁷²⁸²⁹

9.1 対象環境を確認する

az version

az account show \
  --query '{subscriptionId:id,tenantId:tenantId,name:name}' \
  --output json

以下はBash用です。リソース名は例示なので、対象に置き換えます。リソースグループは共通とは限りません。

KV_NAME='kv-cert-example'
CERT_NAME='site-tls'
APP_RG='rg-app-example'
APP_NAME='app-example'
AFD_RG='rg-edge-example'
AFD_PROFILE='afd-example'
AFD_SECRET='site-tls-reference'
AFD_DOMAIN='www-example-com'

AFD_DOMAINはFront Doorのカスタムドメインリソース名です。FQDNと同じ文字列とは限りません。

9.2 Key Vaultの確認対象をバージョンIDで固定する

確認の途中で別の更新が走っても、比較対象が変わらないようにします。まず、その時点の最新バージョンのIDを取得し、以降のメタデータ確認とダウンロードには同じIDを使います。²⁶

if ! CERT_ID=$(az keyvault certificate show \
  --vault-name "$KV_NAME" \
  --name "$CERT_NAME" \
  --query id --output tsv); then
  printf '%s\n' 'Failed to resolve the certificate version' >&2
  exit 1
fi

if [ -z "$CERT_ID" ]; then
  printf '%s\n' 'Certificate ID is empty' >&2
  exit 1
fi

printf 'Certificate ID: %s\n' "$CERT_ID"

az keyvault certificate show \
  --id "$CERT_ID" \
  --query '{id:id,secretId:sid,enabled:attributes.enabled,notBefore:attributes.notBefore,expires:attributes.expires}' \
  --output json

az keyvault certificate list-versions \
  --vault-name "$KV_NAME" \
  --name "$CERT_NAME" \
  --query '[].{id:id,enabled:attributes.enabled,expires:attributes.expires}' \
  --output json

取得したCERT_IDが意図した更新版か、名前・バージョン・有効状態・内容を確認します。過去の特定版を調べる場合は、その版のIDを指定してください。メタデータの取得成功だけでは、配布先の主体による秘密鍵の取得まで確認したことにはなりません。

9.3 App Serviceのバインドを確認する

az webapp config hostname list \
  --resource-group "$APP_RG" \
  --webapp-name "$APP_NAME" \
  --query '[].{name:name,sslState:sslState,thumbprint:thumbprint}' \
  --output json

対象のカスタムFQDNが、期待する証明書へバインドされているかを調べます。既定のホスト名の表示だけで、カスタムドメインのバインドが正常と判断しないようにします。

デプロイスロットを調べる場合は、対象スロットを--slotで指定します。²⁷ 本番スロットだけを確認して、別スロットの確認まで済ませたことにしないようにします。

9.4 Front Doorの参照関係を確認する

az afd custom-domain show \
  --resource-group "$AFD_RG" \
  --profile-name "$AFD_PROFILE" \
  --custom-domain-name "$AFD_DOMAIN" \
  --output json

az afd secret show \
  --resource-group "$AFD_RG" \
  --profile-name "$AFD_PROFILE" \
  --secret-name "$AFD_SECRET" \
  --output json

カスタムドメイン側のTLS設定が指すSecret IDを確認し、そのリソースを調べます。変数に入れたSecret名が実際の参照先と一致することも確認してください。

Secret側では、証明書の参照元、バージョン、Latestを使う設定、配備状況を確認します。代表的なフィールドはsecretSource、secretVersion、useLatestVersionです。取得したJSONの構造に合わせて読み取ります。

Azure Portalに表示される操作成功と、一回の外部確認だけで、全エッジ拠点への配備完了を証明できるとは扱いません。

9.5 Key Vaultの公開証明書を確認する

9.2で取得した、バージョンを含むCERT_IDを使います。ダウンロードに失敗した場合は処理を止め、以前のファイルを読んで正常と誤認しないようにします。

if ! az keyvault certificate download \
  --id "$CERT_ID" \
  --encoding PEM \
  --file expected-leaf.pem; then
  printf '%s\n' 'Failed to download the selected certificate version' >&2
  exit 1
fi

openssl x509 \
  -in expected-leaf.pem \
  -noout -subject -issuer -dates -serial \
  -fingerprint -sha256 -ext subjectAltName

Certificateのdownloadコマンドは公開部分を取得します。秘密鍵を含むPFXをダウンロードする操作とは分けています。²⁶

このSHA-256フィンガープリントと、通信で取得したリーフ証明書のSHA-256を照合します。SHA-1形式のthumbprintと比較する場合は、同じ公開証明書からSHA-1を計算します。CLIの公式資料にもSHA-1による照合例があります。²⁶

openssl x509 -in expected-leaf.pem -noout -fingerprint -sha1

同じ証明書でもSHA-1とSHA-256の値は異なります。ここでのハッシュ値は証明書を識別するためのもので、TLSの署名アルゴリズムや信頼の検証とは別です。³⁰

10. 配信中の証明書を監視するPythonスクリプト

次はPython 3の標準ライブラリを使う例です。SNIには指定したホスト名を送り、証明書のDNS名（SAN）、信頼チェーン、有効期間を検証します。SANがない証明書をCNだけで受け入れるフォールバックは無効にします。³¹

check_tls.pyとして保存します。

import argparse
import datetime as dt
import hashlib
import json
import socket
import ssl
import sys

parser = argparse.ArgumentParser()
parser.add_argument("hostname", help="SNI and certificate verification name")
parser.add_argument("--connect-to", help="Optional destination hostname or IP")
parser.add_argument("--port", type=int, default=443)
parser.add_argument("--warn-days", type=int, default=30)
args = parser.parse_args()

if args.warn_days < 0 or not 1 <= args.port <= 65535:
    parser.error("warn-days must be nonnegative and port must be 1..65535")

target = args.connect_to or args.hostname
checked_at = dt.datetime.now(dt.timezone.utc)
peer_ip = None

try:
    context = ssl.create_default_context()
    context.hostname_checks_common_name = False
    with socket.create_connection((target, args.port), timeout=10) as raw:
        peer_ip = raw.getpeername()[0]
        with context.wrap_socket(raw, server_hostname=args.hostname) as tls:
            cert = tls.getpeercert()
            cert_der = tls.getpeercert(binary_form=True)
            tls_version = tls.version()

    expires = dt.datetime.fromtimestamp(
        ssl.cert_time_to_seconds(cert["notAfter"]), dt.timezone.utc
    )
    now = dt.datetime.now(dt.timezone.utc)
    remaining = expires - now
    warning = remaining < dt.timedelta(days=args.warn_days)
    result = {
        "status": "WARN" if warning else "OK",
        "hostname": args.hostname,
        "connect_to": target,
        "peer_ip": peer_ip,
        "checked_at_utc": checked_at.isoformat(),
        "not_after_utc": expires.isoformat(),
        "days_remaining_floor": remaining.days,
        "sha256": hashlib.sha256(cert_der).hexdigest().upper(),
        "dns_names": [
            value for kind, value in cert.get("subjectAltName", ())
            if kind == "DNS"
        ],
        "tls_version": tls_version,
    }
    code = 1 if warning else 0
except (OSError, ValueError, KeyError) as exc:
    result = {
        "status": "ERROR",
        "hostname": args.hostname,
        "connect_to": target,
        "peer_ip": peer_ip,
        "checked_at_utc": checked_at.isoformat(),
        "error_type": type(exc).__name__,
        "error": str(exc),
    }
    if isinstance(exc, ssl.SSLCertVerificationError):
        result["verify_code"] = exc.verify_code
        result["verify_message"] = exc.verify_message
    code = 2

print(json.dumps(result, ensure_ascii=False))
sys.exit(code)

実行例です。

python3 check_tls.py www.example.com --warn-days 30

終了コードは、0が期限警告なし、1が期限警告、2がTLS検証や接続などの失敗です。監視側で終了コードを拾い、JSONを記録します。スケジューラーでは実行全体の制限時間も設定してください。

オリジンのSNIを保ちつつ、到達先を明示する例は次です。

python3 check_tls.py origin.example.com \
  --connect-to 192.0.2.10 \
  --warn-days 30

192.0.2.10は説明用のアドレスです。実際の接続先へ置き換え、閉域なら許可された監視ネットワークで実行します。ここでhostnameに渡す名前は、検証したいオリジン側のTLS名です。

エラー時はerror_typeと、証明書検証エラーならverify_code・verify_messageも記録します。TCP接続まで成功した場合は、TLS検証に失敗してもpeer_ipを残します。

検証環境はPython 3.12.14 / OpenSSL 3.5.8です。ローカルTLS環境で、正常接続、期限警告、名前不一致、期限切れ、未信頼CA、SANなし・CNのみ、有効期間開始前の7ケースを確認しています。Azureの配信先への実接続は未検証です。

このスクリプトには限界があります。

実行環境の信頼ストアと時刻に依存する。
HTTP CONNECTプロキシを扱う実装ではない。通常のHTTPS_PROXY環境変数を読むcurlとは経路が異なりうる。
DNSで選ばれた一つの接続結果であり、全IP・全エッジ拠点を網羅しない。
HTTPリクエストやログイン、業務処理は確認しない。
OCSPやCRLによる失効確認を網羅する実装ではない。
取得したフィンガープリントは変更確認用であり、クライアントの固定ピンニングを推奨するものではない。

複数拠点からの実行や、オリジンごとの監視を組み合わせて使います。監視ジョブ自体の停止も別途検知してください。

「自分のPCでは新しい」と「利用者の経路では古い」が両立した場合、どちらかを見間違いと決めつけず、同時刻の観測条件をそろえます。Front Doorの公式資料にも、特定地域で期待しない証明書が返る問題と、地域・応答情報を集める手順があります。¹²

HTTPの確認も分けて実行する

次は、200を返す仕様の確認用パスを監視するBashの例です。HTTP転送成功と、期待ステータスを別々に判定します。

if ! HTTP_STATUS=$(curl --silent --show-error \
  --connect-timeout 10 --max-time 20 \
  --output /dev/null --write-out '%{http_code}' \
  'https://www.example.com/health'); then
  printf '%s\n' 'TLS or HTTP transfer failed' >&2
  exit 2
fi

if [ "$HTTP_STATUS" != '200' ]; then
  printf 'Unexpected HTTP status: %s\n' "$HTTP_STATUS" >&2
  exit 1
fi

printf 'HTTP status: %s\n' "$HTTP_STATUS"

/healthは、そのシステムに実在するパスへ置き換え、キャッシュ対象から外れていることを事前に確認します。200以外を正常とするAPIなら、その仕様に合わせて判定を変更してください。200を返すだけの静的ファイルでは、業務APIの動作まで確認できません。

この例では302や503も異常として扱います。通常のcurlはHTTPエラー応答の受信だけでは転送失敗にならず、--failも3xxを失敗扱いにしないため、期待値を明示します。³² 必要な応答本文や業務処理の確認は別に実施します。

このHTTP判定例は、ローカル環境で200、302、503、接続拒否時の終了コードを確認しています。Azureの実際のルート、認証、ヘルスチェックとの組み合わせは未検証です。

証明書検証を省略するcurl -kを、更新作業の正常性確認に使わないでください。

オリジンが返すチェーンそのものを調べる場合は、OpenSSLも使えます。次はGNU timeoutを利用するLinux / WSL向けの例です。

timeout 15s openssl s_client \
  -connect origin.example.com:443 \
  -servername origin.example.com \
  -verify_hostname origin.example.com \
  -verify_return_error \
  -showcerts </dev/null

検証結果と、サーバーが送信した証明書の並びを確認します。-showcertsは送信された証明書を表示するオプションで、表示された並び自体が検証済みチェーンを意味するわけではありません。³³ App Serviceへ登録するPFXの要件と、TLS接続で送信するチェーンの確認は区別します。⁴¹⁶

11. 更新作業の手順と、作業を閉じる条件

11.1 作業前：誰がどこまで担当するかを決める

最低限、次を台帳へ記録します。

項目	記録内容
FQDN・接続区間	公開側、オリジン側、アプリ内用途
証明書の方式	ASMC、ASC、Key Vault経由、PFX直接アップロード、AFD managed、BYOC
発行・保管	CA、更新手段、Key Vault、オブジェクト名
参照先	App Serviceバインド、Front Door Secret、固定版・Latest
現状	配信中のNotAfter、フィンガープリント、取得日時・監視点
権限・経路	主体、権限モデル、ネットワーク例外と検証結果
担当	発行、DNS、Azure反映、確認、障害判断の担当と副担当
切り戻し	旧版の有効性、残期限、参照先、復旧手順

Key VaultのURIやリソースIDだけでは秘密鍵の値にはなりませんが、内部構成情報です。台帳の閲覧権限は管理します。PFXのパスワードや秘密鍵本文を、台帳や作業チケットに貼り付けないでください。

11.2 作業前：更新版を検証する

持ち込み証明書では、次を本番登録前に確認します。

SANが必要な名前を満たす。
NotBeforeとNotAfterが作業計画に合う。
秘密鍵と証明書が対応し、配布先が取り込める形式・アルゴリズムである。
配布先ごとの要件を満たす証明書チェーンがある。
更新で変わる発行元・中間CAを、利用クライアントが信頼できる。
証明書や公開鍵のピンニング、クライアント認証との兼用がないか確認した。

CAへの依頼では、既存証明書がいつまで有効に使えるか、再発行に失効が伴うか、失効時刻や通知の確認方法も押さえます。旧版のNotAfterだけを根拠に切り替え日を延ばす判断はしません。

Latest運用なら、本番と別の検証用オブジェクトや環境で確認してから、本番の参照名へ更新版を入れる運用を提案します。鍵の保管・移送が増える点も含めて設計してください。

11.3 作業中：一段ずつ証跡を残す

Key Vault経由の持ち込み証明書では、利用する配布先ごとに反映を確認します。次の図は作業と判定の流れです。各サービスの処理が同時に完了することを示すものではありません。

記録する順番は次です。

発行完了と証明書の内容。
Key Vaultの保管先・バージョン。
App Serviceの同期・バインド、Front Doorの参照・配備状態。
公開側TLSとHTTP。
オリジン側TLSと到達性。
認証や外部APIを含む、必要な業務処理。

マネージド証明書では、利用者が新しいPFXを準備する手順はありません。ドメイン検証・更新・配備状況と通信結果を確認する手順に読み替えます。

作業結果には、操作をした時刻と、通信で切り替わりを確認した時刻を分けて残します。後から「反映に何時間かかったか」を調べられる記録になります。

11.4 完了条件

条件	合格の例
公開側のTLS	期待する名前で検証が通り、期限に余裕がある
持ち込み証明書の反映	意図した版と配信中のリーフ証明書が一致する
オリジン側	必要なオリジンとのTLS・到達性が正常
HTTP・業務処理	ヘルス、認証、重要なAPIが期待どおり動く
継続監視	残日数・参照差分・配信状態の監視が動く
引き継ぎ	次回更新条件、担当、副担当、切り戻し条件が記録済み

Front Doorの一回の接続で全拠点を確認したことにはならないため、重要度に応じて複数監視点と継続観測を完了条件へ含めます。

11.5 切り戻しは旧証明書を残すだけでは成立しない

旧証明書へ戻せるのは、残期限、失効状態、鍵の安全性、名前の適合性などを満たす場合です。漏えいや失効への対応で更新したのに、その旧版へ戻すことは復旧策にしません。

また、Latest参照のまま古い版を保持しても、自動的に旧版を選ぶ手順にはなりません。Front Doorなら有効な旧版を参照する別Secretへの関連付け、App Serviceなら利用可能な旧証明書へのバインド更新など、実行する操作を事前に検証します。

Key Vaultの新しい版を無効化・削除すれば必ず直前の版へ戻る、といった未検証の挙動には依存しません。ロールバックにも配備時間がかかることを計画へ含めます。

11.6 金曜に作業を閉じるなら、月曜まで誰が見るかを決める

次は実話ではなく、引き継ぎ内容の比較例です。

「Key Vaultを更新しました。あとは自動反映です」では、週末の担当者は失敗と正常な待ち時間を区別できません。

公開FQDNのBYOC更新版を、指定したKey Vaultの同じ証明書名へ登録済み。
Front Door Secretの参照元とLatest設定は確認済み。
最終確認時点では旧版を配信しており、反映未確認としてチケットを継続する。
旧版の残存時間、次回の観測時刻、当番と副担当をチケットに記録した。
次回確認で取得・配備エラーが出た場合は、待機を続けず調査担当へ連絡する。
残存時間が社内で定めた下限を割る場合は、サポート連絡を含む判断へ進める。

実際の報告には「指定した」「最終確認時点」などの表現を残さず、リソース名、版、時刻、残時間、担当者を記入します。自動処理の完了を待つ作業にも、見届ける人が必要です。

12. 障害時に最初に見る順番

残り時間が短いときほど、同時に複数の設定を変更しないようにします。まず、どの接続が失敗しているかを確定させます。

初動では、次の流れで調査対象を絞ります。HTTP応答だけで証明書の反映完了と判断せず、配信証明書の照合は別に行います。

症状	最初の確認	次の確認
公開FQDNでTLSエラー	名前、有効期間、信頼、接続経路	Front Doorの証明書種別、参照Secret、検証・配備状態
TLSは通るがFront Door経由で502	オリジン接続の証明書名・チェーン	オリジン設定、到達性、プローブ、アプリ
Key Vaultは新しいが配信は古い	参照先名、固定版・Latest	同期・配備状態、取り込み主体の権限とネットワーク
App Serviceに新証明書があるが配信は古い	対象カスタムFQDNのバインド	直接アップロードかKey Vault経由か、同期状況
HTTPSは正常だが外部API認証に失敗	アプリがロード・選択する証明書	外部側登録、用途・EKU、独自キャッシュ
Key Vaultのデータ取得だけ403	失敗操作と呼び出し主体、拒否理由	RBAC・アクセスポリシー、Firewall・NSPなど

502だけで証明書障害と断定はできません。上の表は調査の入り口です。

サポートへ連絡する際は、SKU、対象リソースID、FQDN、発生時刻とタイムゾーン、証明書バージョン、配備状態、通信結果、直前変更をまとめます。秘密鍵やPFXのパスワードは送付資料に含めません。

復旧操作の前には、可能な範囲で配信証明書、SNIバインド、エラー本文を保存します。復旧を優先しつつ、後から「障害時にどの証明書を返していたか」を追える記録を残します。詳細ログやHARには認証情報が含まれうるため、共有する範囲は確認します。

復旧後の原因調査では、確認したい問いを分けて渡します。

障害時に実際に配信された証明書はどれか。
その証明書の有効期間・信頼・失効状態はどうだったか。
Key Vault更新、取り込み、バインド、配備はそれぞれいつ変わったか。
自分たちの変更と、プラットフォーム側の事象を時刻で対応付けられるか。

「早めに更新してください」という再発防止案だけでは、期限前に拒否されたという報告の原因は説明できません。復旧確認済み、原因未確定という状態も、そのまま記録します。

更新報告の例です。

対象FQDN：
確認した接続区間・監視点：
確認日時とタイムゾーン：
証明書方式：
更新版の保管先・バージョン：
参照設定・バインド：
配信中の証明書のフィンガープリントとアルゴリズム：
配信中のNotAfter：
TLS検証結果：
HTTP・業務確認結果：
未確認箇所と継続監視：
切り戻し可否・条件：
次回対応条件・担当・副担当：

完了報告には、確認したFQDN、接続経路、配信証明書、確認時刻、業務処理の結果を残します。未反映の箇所があれば、次回確認時刻と担当者を決めて引き継ぎます。

参考資料

すべて2026年10月26日に確認しました。資料の更新日と確認日は別です。本文中の日数は、仕様として示した値と、本記事の運用提案を区別しています。

Microsoft Q&A：Web Appへの権限付与とKey Vault証明書取り込みに関する公開相談。資料更新日・投稿日時：質問投稿：2025年10月30日（UTC）。 ↩ ↩² ↩³
Microsoft Q&A：Azure Front Door ignores newer domain certificate version。資料更新日・投稿日時：質問投稿：2026年1月20日（UTC）。 ↩ ↩² ↩³ ↩⁴
TLS encryption with Azure Front Door。資料更新日・投稿日時：2026年8月1日。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Add and manage TLS/SSL certificates in Azure App Service。資料更新日・投稿日時：2026年6月4日。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹
Buy and manage App Service certificates。資料更新日・投稿日時：2026年10月15日。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Configure HTTPS on an Azure Front Door custom domain。資料更新日・投稿日時：2026年4月24日。 ↩ ↩² ↩³
Industry-wide certificate changes impacting Azure App Service。資料更新日・投稿日時：2026年10月15日。 ↩ ↩²
Use managed identities to access Azure Key Vault certificates。資料更新日・投稿日時：2025年5月19日。 ↩
Domains in Azure Front Door。資料更新日・投稿日時：2026年7月9日。 ↩ ↩² ↩³ ↩⁴
About Azure Key Vault certificates。確認日：2026年10月26日。 ↩
Get started with Key Vault certificates。資料更新日・投稿日時：2026年4月10日。 ↩
Troubleshoot Azure Front Door certificate problems。資料更新日・投稿日時：2026年5月8日。 ↩ ↩² ↩³
Microsoft Q&A：Azure App Service Certificate became unusable before displayed expiry after rekey/reissue。資料更新日・投稿日時：質問投稿：2026年8月13日（UTC）。報告された障害日は8月7日。 ↩ ↩²
Use TLS/SSL certificates in your application code。資料更新日・投稿日時：2026年5月7日。 ↩
Changes to the managed TLS feature。資料更新日・投稿日時：2026年7月21日。 ↩
Troubleshoot Azure Front Door common issues。資料更新日・投稿日時：2026年8月31日。 ↩ ↩² ↩³
Preserve the original HTTP host name between a reverse proxy and its back-end web application。資料更新日・投稿日時：2026年3月3日。 ↩
Caching with Azure Front Door。確認日：2026年10月26日。 ↩ ↩²
Health probes。資料更新日・投稿日時：2026年5月1日。 ↩
Microsoft Q&A：Azure Front Door Managed Certificate Showing Expired Status。資料更新日・投稿日時：質問投稿：2026年8月6日、投稿者の復旧報告：8月7日（いずれもUTC）。 ↩ ↩²
Virtual network service endpoints for Azure Key Vault。資料更新日・投稿日時：2026年8月20日。 ↩
Configure network security for Azure Key Vault。資料更新日・投稿日時：2026年6月16日。 ↩
Azure Key Vault as Event Grid source。資料更新日・投稿日時：2026年3月26日。 ↩ ↩²
Event Grid message delivery and retry。資料更新日・投稿日時：2026年2月12日。 ↩
Renew your Azure Key Vault certificates。資料更新日・投稿日時：2026年4月10日。 ↩
Azure CLI：az keyvault certificate。現行リファレンスを確認。 ↩ ↩² ↩³ ↩⁴
Azure CLI：az webapp config hostname。現行リファレンスを確認。 ↩ ↩²
Azure CLI：az afd secret。現行リファレンスを確認。 ↩
Azure CLI：az afd custom-domain。現行リファレンスを確認。 ↩
OpenSSL公式：openssl-x509。OpenSSL 3.0リファレンスを確認。 ↩
Python公式：ssl。現行リファレンスを確認。 ↩
curl公式：マニュアル。現行リファレンスを確認。 ↩
OpenSSL公式：openssl-s_client。OpenSSL 3.0リファレンスを確認。 ↩