Azure VM拡張機能の自己署名証明書は自動更新されるのか？Microsoft.Azure.AzureDefenderForServers.MDE.WindowsとAzureSecurityWindowsAgentの運用ポイント

Azure VM 上で Defender for Servers や Azure Monitor、Azure Arc を導入すると、知らないうちに自己署名証明書が増え「これって自動更新されるの？」「期限切れがいっぱい並んでいるけど消していいの？」という疑問を持つ方は多いと思います。本記事では、特に CN=Microsoft.Azure.AzureDefenderForServers.MDE.Windows と CN=Microsoft.Azure.Security.Monitoring.AzureSecurityWindowsAgent の証明書を中心に、仕組みと運用ポイントを整理します。

Azure VM 拡張機能が作成する自己署名証明書とは

まず押さえておきたいのは、今回話題になっている自己署名証明書は「OS やアプリ用に管理者が発行する証明書」ではなく、「Azure VM 拡張機能が 自動で作成する内部用証明書」だということです。

Azure VM や Azure Arc 有効サーバーでは、さまざまな VM 拡張機能（Azure Monitor Agent、Defender for Endpoint エージェントなど）が、Azure のバックエンドサービスと安全に通信するために独自の証明書を生成して利用します。

今回の対象となる CN は次の 2 つです。

CN=Microsoft.Azure.AzureDefenderForServers.MDE.Windows
CN=Microsoft.Azure.Security.Monitoring.AzureSecurityWindowsAgent

どちらも自己署名証明書（Issuer も同じ CN）であり、通常は Windows の「ローカルコンピューター > 個人（My）」ストアに格納されます。多くの環境では、Defender for Servers や Defender for Cloud を有効化したタイミングで、これらの拡張機能が自動的に展開され、その副作用として証明書が作成されます。

対象証明書と拡張機能・サービスの対応関係

2 つの CN が、どの拡張機能・サービスと紐づいているかを整理すると、次のようになります。

証明書の Subject CN	拡張機能の種類	主な関連サービス・役割	格納場所の例
`Microsoft.Azure.AzureDefenderForServers.MDE.Windows`	MDE.Windows 拡張機能 (Publisher: Microsoft.Azure.AzureDefenderForServers)	Defender for Servers / Microsoft Defender for Endpoint 連携用エージェント。Azure VM / Arc サーバーからセキュリティ関連データを送信。	ローカルコンピューター > 個人 (My)
`Microsoft.Azure.Security.Monitoring.AzureSecurityWindowsAgent`	AzureSecurityWindowsAgent 拡張機能 (Publisher: Microsoft.Azure.Security.Monitoring)	Azure Security Center（現 Defender for Cloud）向けのセキュリティイベント収集用の軽量エージェント。セキュリティ関連のイベントを収集してクラウドへ送信。	ローカルコンピューター > 個人 (My)

どちらも共通して、

VM 拡張機能が自動生成する自己署名証明書
Azure のバックエンドサービスとの TLS 通信および相互認証 に利用
エンドユーザーが更新・再発行を設計する前提ではない

という性質を持っています。Microsoft Q&A でも「各拡張機能はバックエンド（MDE や Azure Monitor 等）との安全な接続と認証に使うための証明書を作成する」と明記されています。

結論：これらの自己署名証明書は自動更新されるのか？

Microsoft の公式な立場（Q&A より）

Microsoft Q&A で、まさに同じ 2 つの証明書について質問されたスレッドでは、Microsoft の担当者から次のように回答されています。

これらの証明書は、Azure サービス側で定義された 事前定義のしきい値 を過ぎると、新しい証明書が自動的に発行 される。
証明書は、それぞれの VM 拡張機能がバックエンドサービスと安全に通信するために利用される。
サービス側には、期限切れとなった古い証明書を VM から自動削除する仕組みはない。

したがって、

「これら 2 種類の自己署名証明書は、Azure のサービス側で自動更新される」

というのが公式なスタンスです。

更新タイミング（しきい値）は公開されていない

一方で、「有効期限の何日前に更新されるのか？」といった具体的なしきい値は、セキュリティ上の理由から 公開されていません。Q&A でも「しきい値はサービス内部で定義されており、セキュリティ上の観点から可視化されていない」と回答されています。

実運用上のイメージとしては、次のような動きをするケースが多いと考えてよいでしょう（あくまで概念的な例です）。

証明書の有効期限がある程度近づく
Azure サービス側がしきい値を超えたと判断すると、新しい自己署名証明書を VM にプッシュ
新旧証明書がしばらくストア内で並存
新しい証明書のみが実際の通信で利用され、古い証明書はそのまま残存（自動削除はされない）

このため、「期限切れ証明書がストアに残っている = 今の通信が止まる」という単純な関係ではありません。

期限切れ証明書は削除してよいのか？

Microsoft Q&A の見解

Azure Arc 連携サーバーで、これらの CN の期限切れ証明書が多数たまってしまう事象に対する Microsoft の回答では、次のように説明されています。

各拡張機能ごとに、バックエンドとセキュアに通信するための証明書が発行される。
新しい証明書は、定義されたしきい値を過ぎたタイミングで自動的に更新される。
サービス側には VM / Arc サーバーから古い証明書を削除する仕組みがない。
従って、期限切れの証明書は管理者が手動で削除して問題ない。

さらに、別の公式トラブルシュート記事では、VM 拡張機能用の証明書が複数たまり過ぎた場合、最新の証明書だけ残して古いものを削除してよい と明示されています。

削除してよい証明書／残すべき証明書の考え方

実務的には、次のように整理すると運用しやすくなります。

証明書の状態	推奨アクション	補足
同一 CN で有効なものが 1 枚だけ	何もしない	通常の状態。拡張機能が利用中と考えられる。
同一 CN で「有効」「期限切れ」が混在	最新（有効期限が最も新しい）以外の期限切れを削除してよい	既に新しい証明書が発行済みと判断できるため、古い分はクリーンアップして問題ない。
同一 CN で期限切れしか存在しない	直ちに削除する前に、更新失敗の可能性を確認	拡張機能が正常動作していれば、別の証明書を使っている可能性が高いが、念のためエージェントやログを確認する。

特に、Defender for Cloud の「証明書インベントリ」機能などでこれらが大量に「期限切れ」として検出されてしまう環境では、定期的にクリーンアップしてノイズを減らす運用が現実的です。

証明書が自動更新される仕組みのイメージ

「拡張機能 <-> Azure サービス」間の TLS 通信

これらの証明書は、一般的な Web サーバーの SSL/TLS 証明書とは異なり、VM 拡張機能が Azure のバックエンドと通信するための内部的なエンドポイント証明書です。

クライアント役：VM 上の拡張機能（MDE.Windows、AzureSecurityWindowsAgent など）
サーバー役：Azure のバックエンドサービス（Defender for Cloud、Defender for Endpoint、Azure Monitor 等）
証明書の用途：双方向の TLS 通信と拡張機能側の認証

つまり、これらは「人間がブラウザでアクセスするための公開サイト証明書」ではなく、「エージェントと Azure のサービス間の機械的な認証用」の証明書です。

更新タイミングの一般的なパターン

しきい値は非公開ですが、よくある動きのパターンを図式化すると次のようになります。

拡張機能インストール時に、自己署名証明書 A が作成される。
有効期限が近づくと、Azure 側の判定により新しい自己署名証明書 B が発行される。
一定期間、証明書 A（古い）と B（新しい）がストア内に共存する。
拡張機能は B を優先的に利用し、A は実質的に使われなくなる。
A は自動削除されないため、管理者が任意のタイミングで削除して構わない。

この挙動は、VM 拡張機能用の他の証明書（例：Windows Azure CRP Certificate Generator）にも共通しており、Microsoft のトラブルシュート記事でも「古い証明書を削除してよい」「必要であれば VM エージェントが自動再作成する」と明記されています。

更新がうまくいかない場合の初動対応

まれに、何らかの理由で拡張機能の証明書更新がうまく行かず、拡張機能のステータスが「失敗」になったり、Defender for Cloud 上でヘルスエラーが表示されることがあります。その場合の初動として、次の 3 ステップを押さえておくとトラブルシュートがスムーズです。

1. 拡張機能の状態確認と再適用

Azure ポータルの VM / Arc サーバーの「拡張機能」ブレードで、対象の拡張機能（MDE.Windows、AzureSecurityWindowsAgent など）の状態を確認。
状態が「失敗」や「警告」の場合は、一度「再適用（Reapply）」やバージョン更新を試す。
それでも改善しない場合は、拡張機能のアンインストール → 再インストールを検討（本番環境ではメンテナンス時間などに配慮）。

2. VM エージェント・ネットワーク・時刻同期の確認

証明書更新は、VM エージェントが Azure と通信できていることが前提です。次のポイントをチェックします。

VM エージェント（Windows Azure Guest Agent）が最新 & 正常か
Azure ポータルの「拡張機能とアプリケーション」「ブート診断」などでエージェントの状態を確認し、必要に応じてアップデート。
Azure プラットフォーム IP (例: 168.63.129.16) への通信が許可されているか
NSG / Firewall / Proxy でブロックされていないかを確認。
サーバー時刻が大きくずれていないか
証明書検証では時刻が重要なため、NTP による同期状態を確認。

3. 公式トラブルシュートに沿ったログ確認

Microsoft の「Troubleshoot extension certificate issues on a Windows VM in Azure」記事では、主に次のログを確認することが推奨されています。

C:\WindowsAzure\Logs\WaAppAgent.log（ゲストエージェント全般のログ）
C:\WindowsAzure\Logs\Plugins\<拡張機能名>\ 以下の各種ログ（CommandExecution.log など）

また、CollectGuestLogs.exe を利用してログ一式を ZIP にまとめることも推奨されており、サポートケースを開く前の事前調査として有用です。

証明書を監視・運用するうえでのベストプラクティス

1. 「監視対象」にするが、「人間が更新するもの」とは考えない

これらの証明書はあくまで「Azure サービスがライフサイクルを管理する内部証明書」です。運用としては次のように考えると整理しやすくなります。

有効期限の可視化・監視 は行う（期限切れが大量にたまるとインシデント調査のノイズになるため）。
ただし、証明書の 発行・更新スケジュールは Azure サービス側の責務 であり、管理者が更新手順を設計する必要はない。
更新に異常があると判断された場合のみ、拡張機能や VM エージェントのトラブルシュートを行う。

2. 有効期限の可視化例（PowerShell）

例えば、対象 CN の証明書を一覧し、有効期限順に並べる簡単な PowerShell スクリプトは次のように書けます。

$targetSubjects = @(
  'CN=Microsoft.Azure.AzureDefenderForServers.MDE.Windows',
  'CN=Microsoft.Azure.Security.Monitoring.AzureSecurityWindowsAgent'
)

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $targetSubjects -contains $_.Subject } |
  Select-Object Subject, NotBefore, NotAfter, Thumbprint |
  Sort-Object Subject, NotAfter -Descending

この結果から、

最新の証明書（NotAfter が最も新しいもの）が存在するか
期限切れ証明書がどれだけ残っているか

を視覚的に確認し、運用ルールに沿ってクリーンアップしていくことができます。

3. Defender for Cloud / TVM の結果との付き合い方

Defender for Cloud の「証明書インベントリ」や TVM（脆弱性管理）のレポートでは、これらの自己署名証明書もスキャン対象に含まれます。その結果、

数千台単位のサーバーで、同じ自己署名証明書の「期限切れ」が大量検出される

といった状況が起こりがちです。

この場合は、

まずは本記事の方針に沿って、期限切れ証明書のクリーンアップを定期ジョブ化する
必要であれば、レポート側で「既知のシステム管理用証明書」として別カテゴリ扱いにする

といった運用上のルールを決めることで、「本当に対応が必要な証明書の問題」と区別できるようになります。

やってはいけない NG 運用

これらの証明書はサービス側が管理することを前提としているため、善意の「手入れ」がかえって障害の原因になることがあります。特に避けるべきパターンを挙げておきます。

企業内 CA で同じ CN 名の証明書を発行し、置き換える
「社内 PKI に統一したい」という意図で、同じ Subject 名の証明書を配布してしまうと、拡張機能が期待する証明書と食い違い、認証エラーの原因になります。
拡張機能を削除して証明書だけ残す / 証明書だけ削除して拡張機能を放置する
拡張機能と証明書はセットで動きます。運用方針を変える場合は、拡張機能のアンインストールやプラン変更も含めて設計しましょう。
有効な証明書まで一括で削除する
基本的には「期限切れ証明書」あるいは「同一 CN で古い方」だけを削除対象にするのが安全です。
OS イメージのテンプレートに、これらの証明書を含めたまま展開する
VM のクローンやテンプレート化時に証明書がコピーされると、複数の VM 間で同一証明書が共有されることになり、セキュリティ上望ましくありません。

よくある質問と実務的な答え

Q1. 期限切れ証明書があるのに、Defender for Servers / Azure Monitor が普通に動いているのはなぜ？

A. 多くのケースでは、

新しい自己署名証明書が既に発行されているが、古いものがストアに残っているだけ
あるいは、その証明書が利用されていた古い構成が既に使われていない

といった理由によるものです。まずは同一 CN で「より新しい有効な証明書」が存在するかを確認し、存在する場合は古い期限切れ証明書のみ削除すれば大きな問題にはなりません。

Q2. 「自動更新されるはずの新しい証明書が見当たらない」場合は？

A. その場合は、更新処理が何らかの理由でうまく実行されていない可能性があります。次の点を確認してください。

対象拡張機能が最新バージョンかつ「成功」状態になっているか
VM エージェント、ネットワーク、時刻同期に問題がないか
拡張機能ログ（C:\WindowsAzure\Logs\Plugins\ 以下）にエラーが出ていないか

これらを確認しても解決しない場合は、Microsoft のトラブルシュート手順に沿って詳細なログを収集し、サポートケースの検討をおすすめします。

Q3. Azure Arc 有効サーバーでも挙動は同じ？

A. はい、Azure Arc 有効サーバーに対しても、VM 拡張機能と証明書の仕組みは基本的に同じです。Azure Arc では、Connected Machine Agent 上で VM 拡張機能が動作し、その拡張機能が同様に自己署名証明書を生成してバックエンドと通信します。

Q4. 証明書の有効期限をどの程度「シビアに」監視すべき？

A. Web サイトや API の公開証明書ほどシビアに「期限切れ＝即障害」と考える必要はありませんが、

新しい証明書が発行されていないのに、有効期限が近づいている場合
期限切れ証明書しか存在しないのに、拡張機能がエラーを出している場合

には注意が必要です。監視設計としては、

「有効な証明書が 1 枚も存在しない状態」を検知
「直近 X 日以内に新しい証明書が発行されていない」場合にアラート

といったルールを設けると、過剰なアラートを避けつつ、更新失敗の兆候をつかみやすくなります。

まとめ：運用ポリシーのサンプル

最後に、本記事の内容を踏まえた運用ポリシーの一例をまとめます。

証明書の位置づけ
CN=Microsoft.Azure.AzureDefenderForServers.MDE.Windows および CN=Microsoft.Azure.Security.Monitoring.AzureSecurityWindowsAgent の証明書は、「Azure VM / Arc 拡張機能が自動管理する内部用証明書」と定義し、従来の Web サーバー証明書とは区別して扱う。
自動更新に関する前提
これらの証明書は、Azure サービス側のしきい値をもとに自動更新されることを前提とし、管理者が手動で更新することは想定しない。しきい値の具体的な値は公開されていない点を関係者に共有する。
期限切れ証明書の運用
同一 CN で新しい有効な証明書が存在する場合、期限切れ証明書は定期的なメンテナンス作業で削除してよい。Defender for Cloud の証明書インベントリなどにノイズが溜まらないよう、少なくとも四半期に一度はクリーンアップを実施する。
異常時の対応フロー
「有効な証明書が存在しない」「拡張機能がエラーを出している」などの異常を検知した場合は、
① 拡張機能の状態確認・再適用
② VM エージェント・ネットワーク・時刻同期の確認
③ 公式トラブルシュートに沿ったログ解析と、必要に応じたサポートケース起票
の順で対応する。
禁止事項
企業内 PKI による同一 CN の証明書の発行・置き換え、拡張機能を残したまま証明書を無差別に削除する運用は行わない。

上記のような方針をあらかじめチーム内で合意しておくことで、「謎の自己署名証明書」がセキュリティレビューや監査のたびに議論になることを避け、Azure VM / Arc サーバーのセキュリティ運用をシンプルに保つことができます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure VM拡張機能の自己署名証明書は自動更新されるのか？Microsoft.Azure.AzureDefenderForServers.MDE.WindowsとAzureSecurityWindowsAgentの運用ポイント

Azure VM 拡張機能が作成する自己署名証明書とは

対象証明書と拡張機能・サービスの対応関係