Azure App ServiceでTLS/SSL証明書を設定・更新する場合、まず確認すべきなのは「どの証明書方式を使っているか」と「App Service マネージド証明書（ASMC）の発行・更新条件に該当するか」です。2026年5月8日に更新された公式ドキュメントでは、証明書の追加方法だけでなく、2025年7月28日以降のASMC変更によって、一部構成で証明書の発行・更新に影響が出る点が明記されています。特に、Azure Traffic Managerのネスト／外部エンドポイント、*.trafficmanager.net ドメイン、Key Vault連携、証明書バインディングの更新順序は、管理者と開発者が早めに確認すべきポイントです。(Microsoft Learn)
この記事では、Azure App ServiceのTLS/SSL証明書について、公式情報の変更点、影響を受ける構成、移行・展開時の注意点を実務目線で整理します。単に「証明書を追加する手順」ではなく、更新失敗やHTTPSエラー、IPアドレス変更、アプリ側の証明書参照切れを防ぐための確認観点まで解説します。
Azure App ServiceのTLS/SSL証明書設定で押さえるべき結論
Azure App ServiceのTLS/SSL証明書は、カスタムドメインをHTTPS化するためだけでなく、アプリケーションコードから外部サービスへの証明書認証に使うケースもあります。今回の公式情報で重要なのは、無料のApp Service マネージド証明書（ASMC）を使っている環境では、DigiCertの検証方式変更により、発行・更新条件の確認が必要になった点です。(Microsoft Learn)
まずは、次の3点を確認してください。
| 確認項目 | 見るべき場所 | 判断のポイント |
|---|---|---|
| 証明書の種類 | App Serviceの「証明書」「カスタムドメイン」 | ASMC、App Service証明書、Key Vaultインポート、PFXアップロードのどれか |
| 対象ドメイン | DNS、Custom domains、Traffic Manager | trafficmanager.net 依存や中間CNAME、プライベートDNSのみの構成がないか |
| 更新方式 | 証明書の有効期限、バインディング、Key Vault同期 | 自動更新か、手動アップロード後にバインディング更新が必要か |
特にASMCを使っている場合、「無料で自動更新されるから放置でよい」と考えるのは危険です。サポート外のTraffic Manager構成やDNS条件に該当すると、既存証明書は期限まで使えても自動更新されず、期限切れ後にHTTPSエラーが発生する可能性があります。(Microsoft Learn)
Azure App Serviceで使える証明書の種類
Azure App Serviceでは、証明書の追加方法が複数あります。どれを選ぶべきかは、コスト、更新の自動化、エクスポート可否、ワイルドカード対応、Key Vault運用の有無で変わります。公式ドキュメントでは、無料のマネージド証明書、App Service証明書、Key Vaultからのインポート、PFX形式のプライベート証明書アップロード、CER形式のパブリック証明書アップロードが整理されています。(Microsoft Learn)
| 証明書の種類 | 主な用途 | 向いているケース | 注意点 |
|---|---|---|---|
| App Service マネージド証明書（ASMC） | カスタムドメインのHTTPS化 | 単純なカスタムドメインを低コストで保護したい | ワイルドカード、エクスポート、プライベートDNSなどに制限がある |
| App Service証明書 | Azureで購入・管理する証明書 | 更新やエクスポートも考慮したい | 証明書購入・構成後にApp Serviceへインポートする |
| Key Vaultからのインポート | Key Vaultで管理するPKCS12証明書の利用 | 複数環境で証明書を集中管理したい | App Serviceリソースプロバイダーへの読み取り権限が必要 |
| PFXプライベート証明書のアップロード | 外部CAで取得した証明書の利用 | 既存の証明書運用をApp Serviceへ持ち込みたい | 更新時にバインディング更新が必要になる |
| CERパブリック証明書のアップロード | アプリコードからの外部リソース接続 | 外部APIや認証先に公開証明書を使う | カスタムドメインのHTTPS保護には使わない |
無料のASMCは手軽ですが、証明書のルート発行者やキー情報を含む証明書階層が変わる可能性があります。証明書ピンニングのように証明書や証明書階層へ強く依存する設計では、ASMCではなく別の証明書方式を検討すべきです。(Microsoft Learn)
ASMCの変更点：DigiCertの検証方式がHTTPトークン検証へ
2025年7月28日以降、ASMCはDigiCertの新しい検証プラットフォームへの移行により、発行・更新時の検証要件が変わりました。背景には、MPICと呼ばれる業界全体のコンプライアンス対応があります。ASMCでは、 apexドメインとサブドメインの両方でHTTPトークン検証が使われ、DigiCertが次の検証エンドポイントに到達してドメイン所有権を確認する仕組みになっています。(Microsoft Learn)
https://<hostname>/.well-known/pki-validation/fileauth.txtただし、利用者がこのトークンを自分で配置する必要はありません。App Serviceが必要なトークンを自動的に配置し、ASMCの作成・更新に使うAPIやCLIのリクエストペイロードも基本的には変更されません。(Microsoft Learn)
さらに2025年11月の更新では、DigiCertの検証リクエストをApp Serviceのフロントエンド層で処理する動作が既定になりました。これにより、App Service認証、パブリックアクセス無効化、IP制限、プライベートエンドポイント、クライアント証明書など、公開アクセスを制限する多くの構成でもASMCが継続サポートされると説明されています。一方で、パブリックDNSレコードは引き続き必要です。プライベートDNSだけでカスタムドメインを解決している構成では、ドメイン所有権を検証できない可能性があります。(Microsoft Learn)
影響を受ける構成と受けにくい構成
ASMCの変更で最も注意すべきなのは、すべてのApp Service利用者が影響を受けるわけではない点です。通常のカスタムドメインでASMCを使い、DNS設定も要件を満たしている場合は、大きな変更作業が不要なケースもあります。一方で、Traffic Managerやtrafficmanager.netドメインに依存している環境では、更新失敗のリスクがあります。(Microsoft Learn)
| 構成 | 影響 | 対応方針 |
|---|---|---|
| 通常のカスタムドメイン + ASMC | 多くの場合は継続利用可能 | DNS、CAA、証明書有効期限、バインディングを確認 |
| App Service認証やIP制限があるサイト | 2025年11月更新で多くの制限シナリオに対応 | パブリックDNSが存在するか確認し、ASMC作成テストで検証 |
| プライベートDNSのみのカスタムドメイン | ASMC検証に失敗する可能性 | 公開DNSレコードを用意するか、別方式の証明書運用を検討 |
| Traffic Managerのネスト／外部エンドポイント | ASMCの作成・更新がサポートされない | Azureエンドポイントへ変更、または独自証明書へ移行 |
*.trafficmanager.net ドメインの証明書 | ASMCの作成・更新がサポートされない | カスタムドメインと独自証明書へ移行 |
*.azurewebsites.net の既定ホスト名 | ASMC変更の対象外 | 通常は個別対応不要 |
既存のASMCは有効期限まで使えますが、サポート外構成では自動更新されない可能性があります。証明書の期限切れはブラウザー警告だけでなく、API連携、Webhook、外部認証、監視エンドポイントにも影響します。期限が近い証明書だけでなく、Traffic ManagerやDNS構成に依存する証明書から優先的に洗い出してください。(Microsoft Learn)
管理者が確認すべき設定
App Serviceプランの価格レベル
TLS/SSL証明書を使ったカスタムドメイン保護では、App Serviceプランが対応する価格レベルである必要があります。公式ドキュメントでは、証明書追加の前提としてBasic、Standard、Premium、Isolatedなどのレベルが示されています。また、カスタムドメインのHTTPSバインディングではBasic、Standard、Premiumが前提として案内されています。(Microsoft Learn)
開発環境や検証環境でFreeまたはSharedを使っている場合、本番と同じTLS/SSL証明書運用を再現できないことがあります。証明書の検証は、できるだけ本番に近いApp Serviceプラン、DNS、バインディング構成で行ってください。
DNSレコードとCAAレコード
ASMCでは、ドメインがApp Serviceへ正しくマップされている必要があります。サブドメインの場合、CNAMEを<app-name>.azurewebsites.netまたはTraffic Managerに直接向ける必要があり、中間CNAMEを挟むと証明書の発行・更新がブロックされる可能性があります。apexドメインでは、WebアプリのIPアドレスを指すAレコードが必要です。(Microsoft Learn)
また、一部ドメインではDigiCertを証明書発行者として明示的に許可するCAAレコードが必要になる場合があります。DNSを外部ベンダーや別チームが管理している場合は、証明書更新の直前ではなく、事前にDNS変更のリードタイムを確認しておくと安全です。(Microsoft Learn)
Key Vaultのアクセス権限
Key Vaultから証明書をApp Serviceへインポートする場合、App ServiceリソースプロバイダーがKey Vaultを読み取れるようにする必要があります。ここで間違えやすいのは、WebアプリのマネージドIDに権限を付ければよいと考えてしまうことです。公式ドキュメントでは、App Serviceリソースプロバイダー、つまりMicrosoft.WebまたはMicrosoft.Azure.WebSitesに対する権限付与が説明されています。(Microsoft Learn)
IaCでKey VaultのRBACロールを付与する場合は、アプリケーションIDではなく、テナント内のサービスプリンシパルのオブジェクトIDが必要になるケースがあります。Azure CLIではアプリケーションIDで動作する場面があっても、ARMテンプレートやBicepでは失敗することがあるため、展開方式ごとに検証してください。(Microsoft Learn)
証明書バインディング
証明書をApp Serviceに追加しただけでは、カスタムドメインのHTTPS保護は完了しません。カスタムドメインに対して証明書バインディングを作成し、TLS/SSLの種類としてSNI SSLまたはIPベースSSLを選択する必要があります。一般的なWebサイトではSNI SSLで十分なことが多く、IPベースSSLは専用パブリックIPが必要なケースで使います。(Microsoft Learn)
注意したいのは、App Serviceのカスタムドメイン画面で「セキュリティで保護された」と表示されても、証明書が自己署名か期限切れかまではApp Serviceが確認しない点です。ブラウザー警告や証明書検証エラーが出る場合は、有効期限、中間証明書、証明書チェーン、ホスト名一致を別途確認してください。(Microsoft Learn)
開発者が確認すべきアプリ側の影響
WEBSITE_LOAD_CERTIFICATESを使っているか
App Serviceでは、アプリケーションコードから証明書を利用するためにWEBSITE_LOAD_CERTIFICATESアプリ設定を使います。証明書のサムプリントを指定するか、すべての証明書を読み込む場合は*を設定します。証明書を後から追加した場合、設定によってはアプリの再起動や新しいサムプリントの追加が必要です。(Microsoft Learn)
WEBSITE_LOAD_CERTIFICATES=<comma-separated-certificate-thumbprints>証明書を更新するとサムプリントも変わります。手動アップロードした証明書を使っている場合、古いサムプリントだけを参照しているコードやアプリ設定は、更新後に証明書を見つけられなくなる可能性があります。Key Vault経由の証明書では日次同期によって更新される仕組みがありますが、アプリの設計や設定値によって挙動が変わるため、ステージング環境で確認してから本番反映するのが安全です。(Microsoft Learn)
コンテナー環境では証明書パスをハードコードしない
LinuxまたはWindowsコンテナーで証明書を使う場合、証明書はファイルとして特定ディレクトリに配置されます。Windowsコンテナーでは環境変数として証明書パスが挿入されるため、将来のパス変更に備えて、固定パスではなく環境変数を参照する実装が推奨されます。(Microsoft Learn)
証明書関連の障害は、デプロイ直後ではなく、証明書更新やスロットスワップのタイミングで表面化しやすいものです。外部APIへのmTLS接続、SAML/OIDC連携、署名処理、Webhook受信など、証明書を使う処理はアプリログと合わせて監視対象に入れておきましょう。
ASMCを使い続ける場合の確認手順
ASMCを継続利用する場合は、以下の順で確認すると漏れを減らせます。
| 手順 | 作業 | 失敗しやすいポイント |
|---|---|---|
| 1 | App Serviceの「証明書」と「カスタムドメイン」を確認する | 証明書が追加済みでもバインディングされていない |
| 2 | 対象ドメインのDNSを確認する | CNAMEの中継、Aレコード不備、公開DNSなし |
| 3 | Traffic Manager構成を確認する | ネスト／外部エンドポイントを使っている |
| 4 | trafficmanager.net ドメインの証明書を洗い出す | カスタムドメインではなくTraffic Manager既定ドメインに依存している |
| 5 | 新規ASMC作成または更新テストを行う | 本番だけ成功条件が異なる構成になっている |
| 6 | 証明書期限と監視を設定する | 自動更新前提で期限切れアラートがない |
公式のASMC変更ページでは、構成がASMCをサポートするかどうかを確認する方法として、対象サイトでASMCの作成を試すことが案内されています。初回リクエストが成功し、他の要件も満たしていて、サポート外シナリオに該当しなければ、更新も機能する見込みです。(Microsoft Learn)
ASMCから独自証明書へ移行する場合の流れ
Traffic Managerのネスト／外部エンドポイントや*.trafficmanager.net依存がある場合は、ASMCの継続利用ではなく、カスタムドメインと独自証明書への移行を検討します。移行は次の順序で進めると、ダウンタイムや証明書エラーを避けやすくなります。
| フェーズ | 実施内容 | 補足 |
|---|---|---|
| 設計 | 実際に公開するカスタムドメインを決める | trafficmanager.net ではなく自社ドメインを使う |
| 証明書取得 | 外部CAまたは証明書プロバイダーで証明書を取得する | App Service要件を満たすPFXまたはKey Vault管理にする |
| 登録 | Key Vaultからインポート、またはPFXをアップロードする | Key Vault運用ならApp Serviceリソースプロバイダー権限を確認 |
| バインディング | カスタムドメインに新証明書をバインドする | 古いバインディングを先に削除しない |
| アプリ確認 | HTTPS、外部認証、API接続、証明書参照を確認する | WEBSITE_LOAD_CERTIFICATESのサムプリントも確認 |
| 後片付け | 不要なASMCを削除する | 誤再利用を防ぎ、将来の更新失敗を避ける |
手動アップロードした証明書を更新する場合は、古いバインディングを削除してから新しいバインディングを作るのではなく、新しい証明書をアップロードし、既存のカスタムドメインのバインディングを更新してから古い証明書を削除します。特にIPベースSSLでは、バインディング削除によって受信IPアドレスが変わる可能性があるため、DNS変更やダウンタイムにつながるリスクがあります。(Microsoft Learn)
PFX証明書をアップロードする場合の注意点
外部CAで取得した証明書をApp Serviceにアップロードする場合、証明書はパスワード付きPFXファイルである必要があります。また、証明書チェーンには中間証明書とルート証明書を含め、カスタムドメインのTLSバインディングに使う場合はサーバー認証の拡張キー使用法と信頼された証明機関による署名が必要です。(Microsoft Learn)
証明書エラーの原因として多いのは、秘密キーなしの証明書をアップロードしている、PFXのパスワードを間違えている、中間証明書を含めていない、ホスト名と証明書のSANが一致していない、といった基本的な不備です。OpenSSL v3で作成したPFXがうまく扱えない場合は、公式ドキュメントにあるPFXエクスポート時の暗号方式に関する注意も確認してください。(Microsoft Learn)
展開前にチェックしたい実務用リスト
本番反映前には、次の項目をチェックリストとして使うと安全です。
| チェック項目 | 確認内容 |
|---|---|
| 証明書方式 | ASMC、Key Vault、PFX、App Service証明書のどれか |
| 証明書期限 | 期限、更新予定日、更新担当、監視アラート |
| DNS | A/CNAME、CAA、公開DNS、Traffic Manager構成 |
| バインディング | カスタムドメインに正しい証明書が割り当てられているか |
| TLS種別 | SNI SSLかIPベースSSLか |
| Key Vault | App Serviceリソースプロバイダーに権限があるか |
| アプリ設定 | WEBSITE_LOAD_CERTIFICATESの値とサムプリント |
| アプリ実装 | 証明書ピンニング、固定パス、古いサムプリント依存がないか |
| 切り戻し | 旧証明書、旧バインディング、DNS TTL、検証手順 |
| 監視 | HTTPS監視、証明書期限監視、外部API接続監視 |
「証明書を追加したら終わり」ではなく、DNS、バインディング、アプリコード、監視まで含めて1つの変更として扱うことが重要です。特に証明書更新は、普段は正常に動いている構成の弱点が期限直前に露呈しやすいため、更新期限の30日前には棚卸しを始めるのが現実的です。
よくある疑問
無料のASMCは今後も使ってよいのか
通常のカスタムドメインで、ASMCの要件を満たしている場合は、有力な選択肢です。コストを抑えて自動更新したいWebアプリには向いています。ただし、ワイルドカード証明書、エクスポート、証明書ピンニング、プライベートDNSのみの構成、Traffic Managerのネスト／外部エンドポイントなどが必要な場合は、独自証明書やKey Vault管理を検討してください。(Microsoft Learn)
*.azurewebsites.net の証明書も影響を受けるのか
ASMCの変更は、App Serviceの既定ホスト名である*.azurewebsites.netの証明書には適用されません。ASMCは顧客のカスタムドメインに発行される証明書であり、既定ホスト名とは扱いが異なります。(Microsoft Learn)
Key Vaultで更新すればApp Service側も自動で切り替わるのか
Key Vaultからインポートした証明書は、Key Vault側で証明書を更新するとApp Serviceが24時間以内に同期し、該当する証明書バインディングを更新すると説明されています。ただし、同期に必要なKey Vault権限を削除している場合や、アプリコード側が古いサムプリントに依存している場合は、期待どおりに切り替わらない可能性があります。(Microsoft Learn)
カスタムドメインが「セキュリティで保護された」と表示されていれば問題ないのか
完全には判断できません。App Serviceの画面上で「セキュリティで保護された」と表示されても、証明書が自己署名か期限切れかまではApp Serviceが検証しないとされています。実際のブラウザー表示、外部SSLチェック、証明書チェーン、ホスト名一致、アプリ側ログを合わせて確認してください。(Microsoft Learn)
まず実施すべきアクション
Azure App ServiceのTLS/SSL証明書運用では、証明書の追加方法そのものよりも、更新時に失敗しない構成になっているかが重要です。最初に、App Serviceごとに証明書の種類、対象ドメイン、有効期限、バインディング、Traffic Manager依存、Key Vault連携、WEBSITE_LOAD_CERTIFICATESの使用有無を棚卸ししてください。
ASMCを使っている場合は、Traffic Managerのネスト／外部エンドポイントと*.trafficmanager.netドメインを優先的に確認します。該当する場合は、カスタムドメインと独自証明書への移行計画を立て、古い証明書を削除する前に新しい証明書の登録、バインディング更新、HTTPS疎通確認、アプリコードの証明書参照確認まで完了させましょう。
コメント