Azure Certificate Authority details は、Azure のサービス エンドポイントで使われるルート証明機関と下位証明機関を確認するための公式情報です。結論から言うと、通常の OS 標準の信頼ストアを使って Azure に接続しているだけなら、すぐにアプリ改修が必要になるケースは多くありません。一方で、証明書ピン留め、独自の信頼ストア、Java の古い keystore、閉域・プロキシ環境、ファイアウォールの厳格な送信制御を使っている場合は、接続障害を避けるために確認が必要です。Microsoft Learn の該当ページは、Azure のサービス エンドポイントで使用されるルート CA・下位 CA、証明書ダウンロード先、失効確認用の AIA・CRL・OCSP ホスト名を整理した資料で、政府・ナショナルクラウドも対象範囲に含まれます。(Microsoft Learn)
この記事では、2026年7月1日時点で確認すべき Azure Certificate Authority details の読み方、影響を受けやすいシステム、設定変更の判断基準、移行期限の考え方、管理者が実施すべきチェック項目を実務向けに整理します。
まず押さえるべき結論
Azure Certificate Authority details は、新しい管理画面や単独の新機能ではありません。Azure の各種サービスに TLS/SSL で接続するクライアントやアプリケーションが、どのルート証明機関・中間証明機関を信頼できる状態にしておくべきかを確認するための公式リストです。
特に重要なのは、次の4点です。
| 確認ポイント | 実務上の意味 |
|---|---|
| ルート CA と下位 CA の一覧 | Azure 接続時に提示される証明書チェーンを信頼できるか確認する |
| 証明書ピン留めへの影響 | サムプリントや公開鍵を固定しているアプリが接続失敗しないか確認する |
| AIA・CRL・OCSP の通信先 | 証明書チェーン取得や失効確認に必要な外向き通信を許可する |
| Java・Linux・閉域環境の信頼ストア | OS 標準の自動更新に頼れない環境で CA を手動更新する |
Microsoft の公式情報では、Azure で使用される CA の変更や有効期限切れに備えて、OS の更新、信頼されたルートストアの更新、中間 CA ストアの確認、Linux の CA 配置、Java keystore の確認、証明書ピン留めの見直しが必要になる場合があると説明されています。(Microsoft Learn)
Azure Certificate Authority details とは
Azure Certificate Authority details は、Azure のサービス エンドポイントで使われる証明書の信頼チェーンを確認するための Microsoft Learn の公式ドキュメントです。Azure VM やホステッドサービス上の OS が持つ一般的な信頼アンカーとは別に、Azure のサービス エンドポイント側で使用されるルート CA と下位 CA を把握する目的で使います。(Microsoft Learn)
分かりやすく言えば、「Azure に HTTPS で接続するクライアントが、どの証明書発行元を信頼していればよいか」を確認するための台帳です。
たとえば、次のような通信で関係します。
- 社内アプリから Azure API や Microsoft Entra ID に接続する
- プロキシや SSL インスペクション機器を経由して Azure に接続する
- Java アプリケーションが独自の keystore で Azure に接続する
- Linux サーバーやコンテナが古い CA バンドルを使っている
- モバイルアプリや組み込み機器が証明書ピン留めを実装している
- 閉域ネットワークから CRL や OCSP への通信を制御している
Azure Certificate Authority details には、証明書のシリアル番号、SHA1 サムプリント、証明書ダウンロード URL が掲載されています。証明書の有効期限は、証明書ファイルをダウンロードして Windows の証明書ビューアーや openssl x509 -in <certificate-file> -noout -dates で確認できます。(Microsoft Learn)
2026年時点で特に重要な更新ポイント
2026年時点で管理者が注目すべき点は、「証明書が変わること」そのものよりも、「証明書チェーンの変化に追随できない構成が残っていないか」です。
証明書ピン留めをしているアプリは最優先で確認する
証明書ピン留めとは、特定の証明書、サムプリント、公開鍵、Subject Distinguished Name、Common Name、シリアル番号などをアプリ側で固定し、それ以外の証明書を拒否する仕組みです。Microsoft は、アプリが許容する CA のリストを明示している場合、CA の変更や期限切れに合わせてピン留め情報の更新が必要になる場合があると説明しています。(Microsoft Learn)
実務では、次のような実装が危険です。
特定の中間 CA のサムプリントだけを許可している
特定のルート CA 名だけを文字列比較している
証明書チェーンではなくリーフ証明書を固定している
モバイルアプリに古い公開鍵ハッシュを埋め込んでいる
IoT 機器のファームウェア更新なしで証明書を固定しているこのような構成では、Azure 側の証明書が正規のものに更新されても、クライアントが「想定外の証明書」と判断して接続を拒否する可能性があります。セキュリティ目的で導入したピン留めが、運用上の単一障害点になる典型例です。
独自の信頼ストアを使う環境は影響を受けやすい
Windows、macOS、主要ブラウザ、更新済みの Linux ディストリビューションでは、通常は OS やランタイムの信頼ストアが更新されます。しかし、閉域環境や古い OS、コンテナイメージ、Java アプリケーションでは、信頼ストアが古いまま残ることがあります。
Microsoft は、信頼されたルートストアを無効化している場合や切断された Windows クライアントを使う場合、すべてのルート CA を Trusted Root CA ストアに、関連する下位 CA を Intermediate CA ストアに含める必要があると説明しています。また、多くの Linux ディストリビューションでは CA を /etc/ssl/certs に追加する必要がある場合があります。(Microsoft Learn)
Java アプリケーションは OS とは別に確認する
Java は OS の証明書ストアではなく、JVM 側の cacerts を使う構成が多いため、OS を更新しても Java アプリだけ接続に失敗することがあります。
Microsoft は、Java アプリケーションで Microsoft ECC Root Certificate Authority 2017 と Microsoft RSA Root Certificate Authority 2017 が信頼されているか確認する方法として、次の keytool コマンドを示しています。(Microsoft Learn)
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts古い Java ランタイム、固定化されたコンテナイメージ、アプリに同梱された独自 keystore を使っている場合は、OS 更新だけでは不十分です。CI/CD のベースイメージ、アプリケーションサーバー、バッチサーバー、オンプレミス連携基盤まで含めて確認しましょう。
影響範囲：どのシステムを確認すべきか
Azure Certificate Authority details の影響確認は、Azure 全体を闇雲に調べるのではなく、TLS 接続の実装方式で優先順位を付けるのが現実的です。
| 優先度 | 対象 | 確認すべき理由 |
|---|---|---|
| 高 | 証明書ピン留めを使うアプリ | CA 変更や証明書更新で接続拒否が起きやすい |
| 高 | Java アプリケーション | JVM の keystore が OS と別管理になりやすい |
| 高 | 閉域・プロキシ・厳格なファイアウォール環境 | AIA・CRL・OCSP への通信が遮断されると検証に失敗する可能性がある |
| 中 | Linux サーバー・コンテナ | CA バンドルが古いイメージに固定されている場合がある |
| 中 | モバイルアプリ・IoT | アプリ更新やファームウェア更新なしにピン留めを修正できない場合がある |
| 中 | 古い Windows クライアント | 信頼ストアの更新が止まっている可能性がある |
| 低 | 最新 OS・標準ブラウザのみを使う一般端末 | 通常は OS やブラウザの信頼ストア更新で対応できることが多い |
特に見落としやすいのは、Azure そのものではなく「Azure に接続する周辺システム」です。監視ツール、ID 連携基盤、プロキシ、ETL、バッチ、古い業務アプリ、オンプレミスのジョブサーバーが Azure API や Microsoft Entra ID に接続している場合、アプリ担当者だけでなくネットワーク担当者、セキュリティ担当者も巻き込んで確認する必要があります。
現在確認すべき主な CA
Azure Certificate Authority details には、複数のルート証明機関と下位証明機関が掲載されています。ルート CA としては、DigiCert Global Root CA、DigiCert Global Root G2、DigiCert Global Root G3、DigiCert TLS ECC P384 Root G5、DigiCert TLS RSA 4096 Root G5、Microsoft ECC Root Certificate Authority 2017、Microsoft RSA Root Certificate Authority 2017 などが示されています。(Microsoft Learn)
ただし、実務では「この表の名前を覚える」よりも、次の考え方が重要です。
| 管理対象 | 確認方法 | 判断基準 |
|---|---|---|
| OS のルート証明書ストア | Windows 証明書ストア、macOS Keychain、Linux CA bundle を確認 | 公式リストのルート CA を信頼できるか |
| 中間 CA | 証明書チェーン取得、アプリログ、TLS 診断で確認 | 中間 CA が欠けていないか |
| Java keystore | keytool -list で確認 | Microsoft RSA/ECC Root CA 2017 などが含まれるか |
| ピン留め設定 | ソースコード、設定ファイル、モバイルアプリ、SDK を検索 | 古いサムプリントや公開鍵を固定していないか |
| 通信制御 | ファイアウォール、プロキシ、ゼロトラスト製品を確認 | AIA・CRL・OCSP への通信を妨げていないか |
証明書は今後も更新されるため、特定のサムプリントだけに依存する運用ではなく、公式リストを定期的に確認する運用に変えることが重要です。
ファイアウォール許可リストで確認すべき通信先
厳格な送信制御をしている環境では、Azure のサービス本体への通信だけを許可していても不十分な場合があります。証明書チェーンの取得や失効確認のために、AIA、CRL、OCSP の通信先が必要になることがあるためです。
Microsoft Learn では、接続を最適化するために、HTTP/ポート80でファイアウォール許可リストに含める必要がある可能性のあるホスト名として、次のようなドメインを示しています。(Microsoft Learn)
| 種類 | 主なホスト名 |
|---|---|
| AIA | cacerts.digicert.com、cacerts.digicert.cn、cacerts.geotrust.com、caissuers.microsoft.com、www.microsoft.com |
| CRL | crl3.digicert.com、crl4.digicert.com、crl.digicert.cn、www.microsoft.com |
| OCSP | ocsp.digicert.com、ocsp.digicert.cn、oneocsp.microsoft.com |
ここで注意したいのは、Azure の通信先だけでなく、証明書発行元や失効確認先への通信が必要になる点です。プロキシ環境では、宛先ドメインの許可だけでなく、SSL インスペクションの除外、HTTP/HTTPS の扱い、名前解決、認証プロキシの挙動も確認しましょう。
マネージド TLS 利用者は別途変更点を確認する
Azure Certificate Authority details とあわせて確認したいのが、Azure のマネージド TLS 機能の変更です。Microsoft は、2025年後半から、Azure Front Door、Azure API Management、Azure App Service、Azure Container Apps、Azure Static Web Apps、Azure Storage などに発行されるマネージド TLS 証明書に影響する更新を開始したと説明しています。(Microsoft Learn)
マネージド TLS では、すべてのマネージド TLS 証明書が DigiCert Global Root CA 配下から DigiCert Global Root G2 および DigiCert Global Root G3 配下の CA に移行されます。また、新しい CA の証明書は Server Authentication EKU のみを含み、Client Authentication EKU はサポートされません。(Microsoft Learn)
影響を受けやすいのは、次のような構成です。
| 構成 | 影響 |
|---|---|
| Azure App Service のカスタムドメインでマネージド証明書を利用 | 証明書チェーン変更に追随できないクライアントが接続失敗する可能性 |
| Azure Front Door や CDN で証明書ピン留めを前提にしている | 新しいルート・中間 CA をピンセットに含める必要がある |
| クライアント認証 EKU を前提に公開 TLS 証明書を利用 | 他の CA の証明書を使う構成への見直しが必要 |
| 古い CNAME 委任 DCV ワークフローに依存 | ドメイン検証プロセスの変更対応が必要 |
Microsoft は、構成を更新しない場合、現在の証明書の有効期限切れ時に停止が発生すると説明しています。証明書が失効した場合にも停止が発生する可能性があり、CA/Browser Forum の要件により失効時は短時間での対応が求められるため、事前対応が重要です。(Microsoft Learn)
移行期限の考え方
Azure Certificate Authority details のページ自体は、「全ユーザーがこの日までに一律で変更する」という単純な移行期限を示すものではありません。実際の期限は、利用している Azure サービス、証明書チェーン、クライアントの実装、証明書ピン留めの有無、証明書の有効期限によって変わります。
ただし、マネージド TLS に関しては、Microsoft が重要な期限を示しています。Mozilla と Chrome が 2026年4月15日に DigiCert Global Root CA を信頼しなくなるため、信頼を維持する目的で、すべてのマネージド TLS 証明書はその日付より前に DigiCert Global Root G2 と DigiCert Global Root G3 へ移行されると説明されています。(Microsoft Learn)
2026年7月時点で管理者が取るべき姿勢は、「これから期限までに準備する」ではなく、「すでに変更が反映されている前提で、未対応のクライアントが残っていないかを確認する」です。
特に、次の状態が残っている場合は早急に対応しましょう。
- DigiCert Global Root CA だけを信頼するように固定している
- DigiCert Global Root G2 / G3 を許可していない
- 古い中間 CA のサムプリントだけを許可している
- Java keystore が古いまま更新されていない
- AIA・CRL・OCSP の通信がプロキシやファイアウォールで遮断されている
- マネージド TLS 証明書に Client Authentication EKU がある前提で設計している
管理者が実施すべき確認手順
ここからは、Azure 管理者、セキュリティ担当者、アプリ運用担当者が実際に確認すべき流れを整理します。
利用している Azure 接続経路を洗い出す
まず、どのシステムが Azure に TLS 接続しているかを洗い出します。Azure Portal 上のリソース一覧だけでは不十分です。接続元のアプリケーション、バッチ、監視、ID 連携、外部連携まで含めて確認します。
| 確認対象 | 例 |
|---|---|
| ID 連携 | Microsoft Entra ID、OAuth、OpenID Connect、SAML |
| API 連携 | Azure Resource Manager、Microsoft Graph、Azure Storage API |
| Web 公開 | Azure Front Door、App Service、Static Web Apps、API Management |
| 運用基盤 | 監視ツール、バックアップ、ログ収集、SIEM、EDR |
| 開発基盤 | CI/CD、コンテナビルド、IaC、SDK、CLI |
| 閉域接続 | プロキシ、VPN、ExpressRoute、ゼロトラストゲートウェイ |
ここで「ブラウザから Azure Portal に入れるから問題ない」と判断するのは危険です。障害が起きやすいのは、ブラウザではなく、古いランタイムや独自実装を使ったサーバー間通信です。
証明書ピン留めの有無を確認する
アプリケーションのソースコード、設定ファイル、モバイルアプリ、SDK、リバースプロキシ、API ゲートウェイを確認し、証明書に関する固定値がないか探します。Microsoft は、証明書のサムプリント、Subject Distinguished Name、Common Name、シリアル番号、公開鍵、その他の証明書プロパティへの参照を検索することを推奨しています。(Microsoft Learn)
検索キーワードの例は次のとおりです。
thumbprint
sha1
fingerprint
public key
serial number
Subject
Common Name
CN=
DigiCert
Microsoft RSA Root
Microsoft ECC Root
Azure TLS Issuing見つかった場合は、古い CA を削除する前に、新しいルート CA・中間 CA を許可リストへ追加し、本番と同じ通信経路で検証します。
Java keystore を確認する
Java アプリケーションでは、JVM の cacerts に必要な CA が含まれているか確認します。
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacertsコンテナの場合は、実行中のコンテナ内で確認することが重要です。ビルド環境の Java は更新済みでも、実際に稼働している古いイメージ内の Java が古いまま、というケースがあります。
Linux・コンテナの CA バンドルを更新する
Linux 環境では、ディストリビューションに応じて CA バンドルを更新します。多くの Linux ディストリビューションでは CA を /etc/ssl/certs に追加する必要がある場合があると Microsoft は説明しています。(Microsoft Learn)
代表的な確認観点は次のとおりです。
| 環境 | 確認ポイント |
|---|---|
| Ubuntu / Debian | ca-certificates パッケージが更新されているか |
| RHEL / CentOS 系 | ca-certificates と update-ca-trust の運用が整っているか |
| Alpine Linux | ca-certificates が入っているか、古い軽量イメージで止まっていないか |
| Distroless / Scratch | CA バンドルをアプリに同梱している場合、更新手順があるか |
| Kubernetes | ノードではなくコンテナイメージ内の CA が更新されているか |
ファイアウォールとプロキシの許可設定を確認する
AIA・CRL・OCSP への通信が遮断されると、証明書チェーンの取得や失効確認が不安定になります。特に、金融、公共、医療、製造業の閉域環境では、外部向け HTTP/80 を原則遮断していることがあります。
確認すべき観点は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| DNS | cacerts.*、crl*、ocsp* の名前解決ができるか |
| HTTP/80 | 失効確認や証明書取得先への通信を遮断していないか |
| プロキシ認証 | サービスアカウントや非対話プロセスがプロキシを通過できるか |
| SSL インスペクション | 証明書検証通信に余計な置き換えをしていないか |
| ログ | 証明書検証失敗時のブロックログを追跡できるか |
単に「Azure の FQDN を許可している」だけでは不十分です。証明書検証で利用される周辺ドメインも含めて確認しましょう。
本番と同じ経路で TLS 接続を検証する
検証は、管理者の PC からではなく、実際のアプリケーションが動作するネットワーク経路で実施します。
openssl s_client -connect login.microsoftonline.com:443 -servername login.microsoftonline.com -showcertsこのようなコマンドで証明書チェーンを確認し、想定するルート CA・中間 CA に到達できるか確認します。プロキシ経由、コンテナ内、ジョブサーバー上、閉域ネットワーク内など、実際の通信元で試すことが重要です。
よくある失敗パターン
Azure Certificate Authority details への対応で失敗しやすいのは、証明書そのものの理解不足よりも、運用範囲の見落としです。
OS は更新したが Java が古い
OS の信頼ストアを更新しても、Java の cacerts が古いままだと Java アプリだけ失敗します。特に、古い JRE をアプリに同梱している製品や、ベンダー提供アプリケーションでは注意が必要です。
ファイアウォールで Azure 本体だけを許可している
Azure のサービスエンドポイントへの通信は許可していても、CRL や OCSP への通信がブロックされていると、証明書検証が遅延または失敗する可能性があります。証明書検証の通信先は、業務通信の宛先とは別に管理する必要があります。
証明書ピン留めを「セキュリティ強化」として放置している
証明書ピン留めは中間者攻撃対策として使われることがありますが、証明書の正当な更新に追随できないと可用性リスクになります。Microsoft も、ピン留めには証明書の変更や失効に追随するための運用上のコストがあることを説明しています。(Microsoft Learn)
影響範囲を Azure 管理者だけで判断している
証明書検証は、アプリ、ネットワーク、セキュリティ、端末、ランタイムのすべてに関係します。Azure 管理者だけで完結させると、モバイルアプリ、IoT、オンプレミス連携、プロキシ、Java keystore などを見落としがちです。
グローバル環境での確認ポイント
Azure Certificate Authority details の対象範囲には、政府クラウドやナショナルクラウドも含まれます。グローバル企業では、商用 Azure だけでなく、国や地域ごとのネットワーク制御、証明書検証先、プロキシポリシーを確認する必要があります。(Microsoft Learn)
特に、中国向けの通信では digicert.cn 系のホスト名が AIA、CRL、OCSP に含まれる点に注意が必要です。Microsoft Learn でも、cacerts.digicert.cn、crl.digicert.cn、ocsp.digicert.cn が許可リスト候補として示されています。(Microsoft Learn)
グローバル運用では、次のように地域ごとに確認表を作ると管理しやすくなります。
| 地域・環境 | 確認すべき内容 |
|---|---|
| 日本・APAC | プロキシ経由の CRL/OCSP 通信、Java アプリの keystore |
| 欧州 | ゼロトラスト製品やデータ境界ポリシーによる外向き通信制御 |
| 北米 | Azure Front Door、App Service、Storage などのマネージド TLS 利用状況 |
| 中国関連 | digicert.cn 系ドメインの名前解決と通信許可 |
| 政府・公共系 | 閉域環境、手動更新の信頼ストア、中間 CA ストア |
実務で使える確認チェックリスト
最後に、管理者がそのまま使える形でチェックリストをまとめます。
| チェック項目 | 対応状況 |
|---|---|
| Azure に接続するアプリ、バッチ、監視、ID 連携を洗い出した | 未確認 / 対応中 / 完了 |
| 証明書ピン留めの有無をソースコード・設定ファイルで確認した | 未確認 / 対応中 / 完了 |
| 古いサムプリント、公開鍵、CN、シリアル番号の固定値を確認した | 未確認 / 対応中 / 完了 |
| Windows の信頼されたルート CA ストアを確認した | 未確認 / 対応中 / 完了 |
| 中間 CA ストアに必要な下位 CA が含まれるか確認した | 未確認 / 対応中 / 完了 |
| Linux サーバーとコンテナの CA バンドルを更新した | 未確認 / 対応中 / 完了 |
Java の cacerts を keytool で確認した | 未確認 / 対応中 / 完了 |
| AIA・CRL・OCSP の通信先をファイアウォールで許可した | 未確認 / 対応中 / 完了 |
| プロキシや SSL インスペクションの影響を確認した | 未確認 / 対応中 / 完了 |
| Azure Front Door、App Service、API Management などのマネージド TLS 利用状況を確認した | 未確認 / 対応中 / 完了 |
| 本番と同じネットワーク経路で TLS 接続テストを実施した | 未確認 / 対応中 / 完了 |
| ベンダー製アプリや外部サービスの対応状況を確認した | 未確認 / 対応中 / 完了 |
まとめ：Azure の証明機関更新は「信頼ストア」と「ピン留め」を中心に確認する
Azure Certificate Authority details は、Azure のサービス エンドポイントで使用されるルート CA と下位 CA を確認するための重要な公式資料です。通常の最新 OS と標準ブラウザだけで利用している場合、大きな作業が不要なこともあります。しかし、証明書ピン留め、独自 keystore、古い Linux コンテナ、閉域ネットワーク、厳格なファイアウォール、マネージド TLS のカスタムドメインを使っている環境では、設定確認を後回しにすると接続障害につながります。
次に取るべき行動は明確です。まず Azure に接続するシステムを洗い出し、証明書ピン留めと独自信頼ストアの有無を確認してください。そのうえで、Java keystore、Linux CA バンドル、AIA・CRL・OCSP の通信許可、マネージド TLS の利用状況を順番に点検します。証明書の更新は一度きりの作業ではなく、Azure と外部 CA のライフサイクルに追随する運用プロセスとして管理することが重要です。
コメント