何が起きているのか

2026年4月15日、MozillaとGoogle ChromeがDigiCert Global Root（G1ルート）の信頼を廃止する。これに合わせて、Azure Instance Metadata Service（IMDS）がパブリックイシュアをMicrosoft G2-XSへ切り替える予定だ。

「証明書の話なんて自分には関係ない」と思ったエンジニア、ちょっと待ってほしい。IMDSはAzure VM上で動くほぼあらゆるアプリケーションが、インスタンス情報の取得・マネージドID認証・アテスティッドデータの検証に利用している基盤APIだ。ここが壊れると、VM上のワークロードが静かに死ぬ。

Azure IMDSとは何か

Azure Instance Metadata Service（IMDS）は、Azure VM内から169.254.169.254（リンクローカルアドレス）にHTTPリクエストを投げることで、VMのメタデータや認証トークンを取得できる仕組みだ。マネージドIDを使ったAzureリソースへのアクセス（Key Vault・Storage・Azure OpenAIなど）は内部的にこのエンドポイントを叩いている。

Attestedデータ（改ざん検知用の署名付きメタデータ）を使う場合、クライアント側でその署名を検証するためにルート証明書が必要になる。ここに今回の変更が直撃する。

影響を受けるシステムの条件

以下に該当するシステムは今すぐ確認が必要だ：

  • Attesd Data APIを使っている: ?format=json&api-version=2021-01-01などでAttestedデータを取得し、署名を検証しているコード
  • カスタム証明書ストアを持つ環境: OSのシステムストアを使わず、独自のバンドル証明書でTLS検証しているアプリ（Pythonのcertifi、Javaの独自トラストストアなど）
  • エアギャップ環境・オフライン証明書検証: インターネットに出られないVMでルート証明書を静的にバンドルしているケース
  • 古いOSイメージ: 長期間アップデートしていないLinuxやWindowsイメージはルート証明書ストアが古い可能性がある

逆に、最新のOSイメージを使っており、システムのルートストアに依存し、Attesd Dataを署名検証していない場合は影響を受けない可能性が高い。

対処法

ステップ1：IMDSの利用状況を棚卸しする

まずコードベースを検索して、169.254.169.254へのリクエストやManagedIdentityCredentialの利用箇所を洗い出す。Azure SDK（Python・Java・.NET・Go等）を使っている場合、SDKが内部でIMDSを使っているので認識していなくても影響する可能性がある。

ステップ2：Microsoft G2-XSルート証明書を追加する

カスタム証明書ストアを使っている環境では、Microsoft G2-XSルート証明書を事前に追加しておく必要がある。Microsoft PKIリポジトリから最新のルート証明書を取得し、各環境のトラストストアに追加する。

ステップ3：4月15日前にテスト環境で動作確認

ステージング環境で新しいルート証明書のみを使う設定でアプリを動かし、TLSエラーが出ないことを確認しておく。本番切り替えは段階的に。

実務への影響

この変更が日本のIT現場に与える影響は意外と大きい。特に以下のシナリオで問題が出やすい：

SIer・受託開発案件: 納品後に顧客がメンテナンスしていないVMが大量にある場合、OSのルートストアが更新されていない可能性がある。4月15日以降に突然「認証が通らない」という問い合わせが来るパターンが容易に想像できる。

Pythonアプリ: certifiパッケージは独自のCA束を持っており、pipでアップデートしていない環境では古いルートセットのままだ。pip install --upgrade certifiを今すぐ実行すること。

Java・Spring Bootアプリ: JVMに埋め込まれたトラストストアを使っている場合、JDKのバージョンによってはG2-XSが含まれていない可能性がある。最新のJDK/JREへのアップデートを検討すること。

コンテナ環境: Dockerイメージのベースレイヤーが古い場合も同様。FROM ubuntu:22.04のまま何ヶ月もapt updateしていないイメージは要注意。

筆者の見解

率直に言う。この手のルート証明書ローテーションで毎回思うのは、証明書の有効期限やルートの廃止を「知らなかった」で済ませる日本のエンジニアが多すぎるということだ。

セキュリティの話は嫌いだ。細かい話が多いし、関わる人間もなんか面倒くさい人が多い。でも技術的な興味はめちゃくちゃある。特にこういうインフラレベルの変更は、知らないと本当に静かに死ぬのがタチが悪い。HTTPエラーが出るとかならまだいい。Attesd Data検証のエラーは、ログに出るかどうかもアプリの実装次第で、気づかずにセキュリティ検証をスキップしているケースもある。

Azureのプラットフォームとしての信頼性は揺るがない、と今でも思っている。ただMicrosoftが「重大な変更」をTech Communityのブログポストで告知して終わり、というコミュニケーションスタイルはもう少し改善できるんじゃないかとは思う。Azure Portalのバナーで当該サブスクリプションに直接通知するとか、Service Healthで影響リソースを特定するとか、やりようはいくらでもあるはずだ。

4月15日まで時間がない。いますぐAzure上のワークロードを棚卸しして、影響を確認してほしい。「今動いているから大丈夫」は通用しない——これはSID重複問題のときも、Log4Shellのときもそうだったはずだ。

出典: この記事は Azure Instance Metadata Service TLS Critical Changes - DigiCert Root Deprecation の内容をもとに、筆者の見解を加えて独自に執筆したものです。