最近、Azure VMに関連して、 TRACKING ID : J_Z9-7QZ として「Action required: Update certificates for Azure Instance Metadata Service」というタイトルのサービス正常性の通知されているようで、この内容について、チーム内で内容の補足を行ったので、そのまとめです。
TL;DR
- IMDS の中間証明書が 2026 年 1 月から 2026 年 4 月までの間に順次切り替わります。
- 多くの環境では自動で中間証明書が更新されるため影響はありません。
- 証明書をピン留めしているアプリケーション、または外向きのインターネット接続が制限された環境では、対策が必要になります。
- 特に Azure 上での動作が必須な、Windows Server の Azure Edition や Azure 上で無償で ESU を受けている場合は注意が必要です。
- そのほかにも Azure 上でのみ動作を保証している OS やアプリケーションは注意が必要です。
- 問題が起きた場合は、証明書のインストールや外向きインターネットへのアクセス許可(宛先はこちら)などを検討しましょう。
通知の内容について
TRACKING ID : J_Z9-7QZ にて通知されている内容は、以下の内容となります。
You're receiving this notification because you're associated with one or more Azure subscriptions that uses Azure Instance Metadata Service (IMDS) Attested Data.
Starting in January 2026, Microsoft will introduce new certificates issued by new Subordinate Certificate Authorities (Sub CAs).
These will replace the current Sub CSs, which expire in April 2026. The Azure instance Metadata Service will start using these new certificates in January 2026Most Customers don't need to take action.
You can ignore this message if your application does not use certificate pinning on IMDS Attested data.
日本語で概要を簡単にまとめると以下の通りとなります。
- AzureのIMDS Attested Dataで使っている証明書のうち、中間証明書が変わります
- 既存の証明書は2026年4月までだから、2026年1月から、新しい証明書に順次切り替えます
- 証明書のピニングをしていない人は特に問題無いです
この証明書の変更でどういった影響があるか
Microsoft からの通知や、この通知に関して Azure IaaS サポートチームがまとめているブログ に記載の通り、多くの方には影響がありません。
しかし、この変更内容で影響を受ける人を正しく理解するには、
- IMDSの Attested Data がどういうものなのか
- 証明書の検証がどういう仕組みか
を理解する必要があります。
IMDSのAttested Data(構成証明済みデータ)がどういうものか
IMDS のAttested Data(構成証明済みデータ) は大雑把に簡単化して言うと、VM が Azure上で動いていることを確認するために使われるものです。
仕組みの考え方はそれほど難しくありません。
Azure Instance Metadata Service 自体は、Azure 上の VM 内からのみアクセス可能なサービスとなっています。そのサービスが返すサーバ証明書を検証することで、 VM がAzure 動作していることを確認するような仕組みです。
即ち、今回の通知に関しては、この検証に使う証明書が変わりますよということになります。
証明書の検証がどういう仕組みか
一般的に、サーバ証明書というのは、より上位の証明書の署名が行われています。
簡単化して書くと、ルート証明機関が、ある機関Aの証明書に対して、あなたの証明書は信頼できるので私の証明書で署名してあげますよ。同様に機関Aが別の機関Bが持つ証明書が信頼できるので機関Aの証明書で署名してあげますよ、と進んでいき、最終的にサーバの証明書について、機関Bが確かにこのサーバの証明書として機関Bの証明書で署名してあげますよといったような形になっていて、誰かの証明書をより上位の機関が自分の証明書で署名する形になっています。
この署名のチェーンによって、証明書が信頼できるものとなっています。
要するに、ルート証明機関 --(署名) --> 機関A --(署名) --> 機関B -- (署名) --> サーバ証明書のような形になっています。
サーバ証明書が正しいかを検証する際には、サーバ証明書を検証する際に、署名している機関Bの証明書が正しいかを検証し、機関Aの証明書を検証し、という形で、上へ上へとたどっていって、自分が信頼しているルート証明機関の証明書となっているかといった具合で証明書の検証していきます。
詳細は省略しますが、一般的に、この中間にある機関の証明書(この例では機関A、B の証明書) は、自分の証明書ストアに登録しておくか、証明書ストアにない場合は、インターネットから取得が可能となっており、検証時に証明書が無い場合は、自動でダウンロードされます。
今回の通知に戻ると、通知では、「サーバ証明書からルート証明書までの証明書チェーンにおけるどこかの中間にある機関の証明書(中間証明書)が新しいものに変わります」ということなので、前述の例の機関Aや機関Bに相当する証明書が変わるということが読み取れます。
しかし、上述の通り、中間証明書は、必要に応じて、インターネットから自動でダウンロードされるため、インターネットにアクセスできる環境下では、Microsoftの通知の通り、ピン留めされていなければ特に気にすることはありません。
注意: 証明書のピン留めについて
証明書のピン留めとは、アプリケーション内で信頼する証明書を固定する方法です。今回の例でいうと、中間証明書として機関Aの特定の証明書でないと信頼しない（検証に失敗する）ようにする設定になります。別の機関の証明書になったり、証明書が変更されると検証に失敗することがあります。
結局どういった人が影響を受けるのか
前述の通り、中間証明書は自動でダウンロードされるので、多くの方には問題無いのですが、エンタープライズ環境で利用している場合は、インターネットへのアクセスを制限している環境ということも多くあると思います。
この場合、中間証明書のダウンロードがうまくできずに、証明書検証に失敗するようになる可能性があります。
それでも、IMDSを使っていなかったら問題無いのですが、一部のOS環境に関しては、IMDSの利用が必須のものがあります。
それが、Windows Server の Azure Edition です。
具体的には、Windows のアクティブ化基準値が引き続き表示される を見る限り、「原因 2: 証明書に関連する問題」の部分で、IMDSのAttested Dataの証明書を利用しているようですので、新しい証明書の検証ができない場合、OSのアクティベーションに失敗するようになることが想定されます。
それ以外でも、公開されていない情報なのでおそらくですが、Windows OS の EUS に関しても、Azure 上の VM は無償で ESU が受けられますので、Azure Edition のようにAttested Data を利用して Azure VM であることを確認している可能性があります。（もし本当にAttested Dataを使って確認している場合は影響を受ける可能性があります）
また、他の MarketPlace から提供されているOSに関しても、Azure 上でのみ動作が許可されている場合などには、Attested Dataを利用している可能性があります。(これらが、Attested Dataを利用しているかは提供元に確認が必要となります)
問題が起きた場合の解決策
これは基本的に Windows のアクティブ化基準値が引き続き表示される の解決策2 にかかれている内容で解決できることが想定されます。
即ち、Azure 証明機関の詳細 に記載されている証明書をすべて、適切にローカルの証明書ストアにインストールするか、中間証明書をダウンロードできるようにするかのどちらかになります。
事前に問題が起きないようにするためにも、これらを確認することが大事となります。
結論
IMDS の中間証明書の切り替えは、多くの環境で自動的に処理され問題になりません。ただし、証明書をピン留めしているアプリケーションや、外向きのインターネット接続が制限されているエンタープライズ環境では証明書の検証エラーが発生し、意図せず通信ができない、エラーが発生するといった可能性があります。
以下の環境でご利用の場合は対策の実施が推奨されます。
- アプリケーションで証明書ピン留めしている
- インターネット接続が制限されている環境下で、Windows Server Azure Edition など、Azure 上で動作が必須である OS を利用している
もし上記に当てはまる場合は、リソース正常性の通知や、 Windows のアクティブ化基準値が引き続き表示される を参考に、主に解決策2 にかかれている内容の対策を行いましょう。