MENU

KB5104021後のAzureホスト検出失敗を解消する方法｜証明書チェーンと通信許可先

Windows10

KB5104021（サービス スタック更新プログラム、SSU 19041.7546）を含む更新後に、Windows 10 21H2／22H2のAzureホスト検出が失敗する場合、最初に確認すべきなのは証明書チェーンの取得・検証に必要な通信です。

KB5104021のロールバックを試すのではなく、同SSUを含む累積更新プログラムを適用したうえで、Microsoftが指定するAIA・CRL・OCSPの接続先をファイアウォールやプロキシで許可します。特に、外向きのHTTP通信を原則遮断している環境では、Azure Instance Metadata Service（IMDS）自体には到達できても、中間証明書の取得や失効確認ができず、Azure上のデバイスかどうかの検証に失敗することがあります。(マイクロソフトサポート)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

KB5104021後のAzureホスト検出失敗は証明書チェーンを疑う

KB5104021は、Windows Updateをインストールする基盤部分である「サービス スタック」を更新するプログラムです。

このSSUでは、デバイスがAzureでホストされているかを確認するロジックが強化され、検証時に更新された証明書チェーンが使用されます。そのため、証明書そのものが端末に存在しない場合でも、AIAから中間証明書を取得できれば検証できますが、ファイアウォールやプロキシによって取得先が遮断されていると、チェーンを完成できません。(マイクロソフトサポート)

まず、KB番号とビルド番号の関係を整理しておきましょう。

項目内容
サービス スタック更新KB5104021
SSUバージョン19041.7546
2026年8月の累積更新KB5120249
Windows 10 22H2のOSビルド19045.7663
Windows 10 21H2のOSビルド19044.7663
主な対象Windows 10 ESU、Enterprise LTSC 2021、IoT Enterprise LTSC 2021

19041.7546はOS全体のビルド番号ではなく、SSUのバージョンです。 KB5120249を適用したWindows 10 22H2でwinverを実行しても、19041.7546とは表示されません。22H2なら19045.7663、21H2なら19044.7663となるのが正常です。(マイクロソフトサポート)

また、KB5120249の対象にはWindows 10 ESUなどが指定されています。通常サポートが終了したWindows 10 Home／Pro 22H2でESUを利用していない場合は、ファイアウォール設定以前に、更新プログラムの提供対象かどうかを確認してください。

証明書チェーンが完成しない仕組み

Azure IMDSの証明書検証では、次のような証明書チェーンが使用されます。

DigiCert Global Root G2
└─ Microsoft TLS RSA Root G2
   └─ Microsoft TLS G2 RSA CA OCSP xx
      └─ metadata.azure.com

ここで注意したいのが、Microsoft TLS RSA Root G2は、名前に「Root」と入っていますが、クロス署名された中間証明書として扱われる点です。

証明書チェーンの検証では、主に次の3種類の通信が発生します。

種類役割
AIA不足している中間証明書の取得先を確認する
CRL証明書失効リストを取得する
OCSP証明書が現在も有効かオンラインで確認する

AzureはOCSP用の中間証明書を定期的に切り替えるため、過去に取得した証明書だけで動作していた環境でも、証明書の切り替え後に突然失敗する可能性があります。(Microsoft Learn)

KB5104021のAzureホスト検出失敗を解消する手順

KB5104021を含む累積更新プログラムを適用する

Windows 10 バージョン2004以降では、SSUは原則として毎月の累積更新プログラムに組み込まれています。そのため、KB5104021だけを個別に探すのではなく、対応する累積更新プログラムを展開します。

2026年8月11日公開の基準では、KB5120249にKB5104021が含まれています。Windows Update、Windows Update for Business、Microsoft Update Catalog、WSUSから取得できます。(マイクロソフトサポート)

端末の現在のビルドは、管理者権限のPowerShellで次のコマンドを実行して確認できます。

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
    Select-Object ProductName, DisplayVersion, CurrentBuild, UBR

KB5120249を適用した直後の目安は次のとおりです。

Windows 10 22H2
CurrentBuild : 19045
UBR          : 7663

または、Windows 10 21H2では次のようになります。

Windows 10 21H2
CurrentBuild : 19044
UBR          : 7663

より新しい累積更新プログラムを適用している場合は、UBRが7663より大きくても問題ありません。

SSUパッケージは、次のコマンドで確認できます。

dism /online /get-packages /format:table | findstr /i "ServicingStack"

出力されたパッケージ名やバージョンに、7546または19041.7546が含まれているか確認します。

WSUSを使用する場合は、製品と分類も確認してください。

対象製品分類
Windows 10 22H2Windows 10, version 1903 and laterSecurity Updates
Windows 10 21H2 LTSCWindows 10 LTSBSecurity Updates

長期間更新していない端末や古いマスターイメージでは、前提SSUが別途必要になる場合があります。Microsoftは、WSUSまたはUpdate Catalogから導入する端末に2021年5月11日のKB5003173以降がない場合、先にKB5005260を適用するよう案内しています。(マイクロソフトサポート)

証明書ダウンロード先をファイアウォールで許可する

MicrosoftのAzure証明機関に関する案内では、次のFQDNをファイアウォールの許可リストへ追加するよう示されています。

用途許可するFQDN基本ポート
AIAcacerts.digicert.com
cacerts.digicert.cn
cacerts.geotrust.com
caissuers.microsoft.com
www.microsoft.com		HTTP／TCP 80
CRLcrl3.digicert.com
crl4.digicert.com
crl.digicert.cn
www.microsoft.com		HTTP／TCP 80
OCSPocsp.digicert.com
ocsp.digicert.cn
oneocsp.microsoft.com		HTTP／TCP 80

証明書関連通信ではHTTPのポート80が使用されます。HTTPSの443番ポートだけを許可しても、AIAやCRLへの通信が失敗する可能性があります。(Microsoft Learn)

一方、www.microsoft.com配下から個別の証明書ファイルをダウンロードする処理では、HTTPSとTLS 1.2が使用される場合があります。URL単位で制御しているプロキシでは、MicrosoftのPKI証明書配布パスに対するHTTPS／TCP 443も確認してください。(Microsoft Learn)

設定時には、次の点も確認します。

  • 通信方向は端末またはAzure VMからインターネットへのアウトバウンド
  • IPアドレス固定ではなく、可能な限りFQDNで許可
  • ブラウザだけでなく、Windowsのシステムサービスが利用する経路でも許可
  • SSL復号やHTTPSインスペクションが証明書を置き換えていないか確認
  • Windows Update用FQDNとは別に、証明書検証用FQDNを登録

*.microsoft.comや*.digicert.comを広範囲に許可する必要はありません。セキュリティポリシー上可能であれば、Microsoftが指定するFQDNを個別に登録する方が管理しやすくなります。

WinHTTPプロキシの状態を確認する

ブラウザでWebサイトを表示できても、Windows Updateや証明書取得を実行するシステム側の通信が成功するとは限りません。

管理者権限のコマンドプロンプトで、WinHTTPプロキシを確認します。

netsh winhttp show proxy

次のように表示された場合、WinHTTPは直接接続を使用しています。

Direct access (no proxy server).

インターネット接続にプロキシが必須の環境で直接接続になっている場合、システムサービスから証明書取得先へ到達できません。反対に、プロキシが設定されていても、プロキシ側のURLフィルターでAIA・CRL・OCSPのFQDNが拒否されていれば失敗します。Microsoftも、Windows Updateクライアントが利用するシステム全体のプロキシをnetsh winhttpで確認できると案内しています。(Microsoft Learn)

プロキシのバイパスリストへ証明書用FQDNを追加する方法もありますが、組織ネットワークで直接インターネット接続が禁止されている場合、バイパスすると通信できなくなります。その場合は、バイパスではなくプロキシの許可リストへ登録してください。

DNSとTCP接続を簡易確認する

直接インターネット接続が許可されている環境では、次のPowerShellでDNS名前解決とTCP 80への接続をまとめて確認できます。

$targets = @(
    'cacerts.digicert.com',
    'cacerts.digicert.cn',
    'cacerts.geotrust.com',
    'caissuers.microsoft.com',
    'www.microsoft.com',
    'crl3.digicert.com',
    'crl4.digicert.com',
    'crl.digicert.cn',
    'ocsp.digicert.com',
    'ocsp.digicert.cn',
    'oneocsp.microsoft.com'
)

$results = foreach ($target in $targets) {
    $dnsResult = Resolve-DnsName $target -ErrorAction SilentlyContinue

    [pscustomobject]@{
        Host  = $target
        DNS   = [bool]$dnsResult
        TCP80 = Test-NetConnection `
            -ComputerName $target `
            -Port 80 `
            -InformationLevel Quiet
    }
}

$results | Format-Table -AutoSize

DNSまたはTCP80がFalseになったホストは、DNS、ルーティング、ファイアウォールのいずれかで遮断されている可能性があります。

ただし、Test-NetConnectionはプロキシ経由のHTTP通信を再現するものではありません。直接接続を禁止している環境ではFalseでも正常な場合があるため、プロキシのアクセスログと併せて判断してください。

Azure IMDS Verification Toolで原因を特定する

対象がAzure VMの場合は、Microsoftが提供するAzure IMDS Verification Toolを利用するのが確実です。

Azureポータルでは、次の順に実行します。

  1. 対象の仮想マシンを開く
  2. 「操作」から「コマンドの実行」を開く
  3. Windows_IMDSValidationを選択
  4. 「実行」を選択
  5. AIA、CRL、OCSP、証明書ストアの結果を確認

結果の見方は次のとおりです。

検出結果主な原因対処
IMDS到達確認が失敗Azure VM内のルート、NVA、ゲストOSファイアウォール169.254.169.254への到達性を確認
Phase 5でAIAがBlocked中間証明書取得先の遮断AIA用FQDNとHTTP 80を許可
CRL／OCSPがBlocked失効確認先の遮断CRL・OCSP用FQDNを許可
[MISS]中間証明書が不足通信許可後に再検証、または正式な証明書を導入
UntrustedRoot証明書チェーンが信頼済みルートまで到達しない中間証明書の有無と格納先を確認
ExplicitDistrust証明書が信頼されない証明書ストアに登録されているグループポリシーとDisallowedストアを確認
NotTimeValid時刻ずれ、期限切れ、未有効の証明書時刻同期と証明書期限を確認

このツールは、IMDSへの到達性、証明書チェーン、証明書ストア、AIA接続、OCSP証明書などをまとめて検査します。(Microsoft Learn)

通信を許可できない環境で証明書を手動導入する方法

インターネットへ接続できない閉域環境では、MicrosoftのAzure Certificate Authority Detailsに掲載された証明書を、接続可能な管理端末から取得して配布する方法があります。

ただし、手動導入はファイアウォール許可の代替として安易に行うべきではありません。AzureではOCSP用中間証明書が切り替わるため、1枚だけ登録しても将来再発する可能性があります。

中間証明書をローカルコンピューターの「中間証明機関」へ追加する場合は、管理者権限で次のように実行します。

certutil -addstore CA "取得した中間証明書.crt"

証明書の状態はPowerShellでも確認できます。

Get-ChildItem Cert:\LocalMachine\CA |
    Where-Object {
        $_.Subject -match 'Microsoft TLS|Microsoft Azure|DigiCert'
    } |
    Select-Object Subject, Issuer, NotAfter, Thumbprint |
    Sort-Object NotAfter

特に、Microsoft TLS RSA Root G2 - xsignは名前に「Root」が含まれていても、クロス署名された中間証明書です。安易に「信頼されたルート証明機関」へ登録せず、Microsoftの案内どおり中間証明機関ストアへ配置します。(Microsoft Learn)

閉域環境でAIAを常時遮断する場合は、次の運用も必要です。

  • 現在使用される中間証明書を事前配布する
  • 証明書の有効期限を定期監視する
  • Azure側のOCSP証明書切り替え情報を確認する
  • 新しい証明書を端末管理ツールやグループポリシーで配布する
  • Microsoft掲載のサムプリントと取得した証明書を照合する

証明書を入れても直らない場合の確認項目

信頼されない証明書ストアを確認する

正しい証明書がインストールされていても、同じ証明書がDisallowedストアに登録されていると検証に失敗します。

Get-ChildItem Cert:\LocalMachine\Disallowed |
    Select-Object Subject, Thumbprint, NotAfter

Get-ChildItem Cert:\CurrentUser\Disallowed |
    Select-Object Subject, Thumbprint, NotAfter

証明書が見つかっても、すぐに削除してはいけません。セキュリティ部門が意図的にブロックしている可能性があるため、グループポリシーや証明書配布ポリシーを確認します。

ローカルで削除しても再び登録される場合は、ドメインのグループポリシーによって管理されている可能性があります。(Microsoft Learn)

Windowsの時刻を確認する

時刻が大きくずれていると、有効な証明書でも期限切れや有効期間前と判断されます。

w32tm /query /status

同期に問題がある場合は、組織の時刻同期構成を確認したうえで再同期します。

w32tm /resync

IMDS検証結果にNotTimeValidが出る場合は、証明書の入れ直しより先に時刻を修正してください。(Microsoft Learn)

CAPI2ログで遮断されたURLを確認する

証明書チェーンの詳細なエラーは、CAPI2のイベントログで確認できます。

  1. イベントビューアーを開く
  2. 「アプリケーションとサービス ログ」を開く
  3. 「Microsoft」→「Windows」→「CAPI2」を開く
  4. 「Operational」を右クリックしてログを有効化
  5. 問題を再現する
  6. エラーイベントのURL、証明書名、エラーステータスを確認

次の文字列がないか確認します。

metadata.azure.com
caissuers.microsoft.com
cacerts.digicert.com
CRL
OCSP
UntrustedRoot
ExplicitDistrust
NotTimeValid

CAPI2ログは証明書チェーンの構築や失効確認の切り分けに利用できます。(Microsoft Learn)

Windows UpdateとCBSのログを確認する

Windows Updateのログは、管理者権限のPowerShellで生成できます。

Get-WindowsUpdateLog `
    -LogPath "$env:USERPROFILE\Desktop\WindowsUpdate.log"

Get-WindowsUpdateLogで生成されるファイルは実行時点の静的なコピーです。設定変更後に再テストした場合は、コマンドをもう一度実行して新しいログを作成します。

サービス スタックによるインストール処理は、次のCBSログにも記録されます。

C:\Windows\Logs\CBS\CBS.log
C:\Windows\Logs\CBS\CBS.persist.log

Windows Updateのダウンロード段階で止まっているのか、SSUやLCUのインストール段階で止まっているのかを分けて確認してください。(Microsoft Learn)

KB5104021対応で失敗しやすいポイント

失敗しやすい対応問題点正しい対応
Windows Update用URLだけを許可する証明書取得先は別のFQDNAIA・CRL・OCSPも許可する
HTTPS 443だけを許可するAIAやCRLはHTTP 80を利用するMicrosoft指定先へのHTTP 80を確認する
ブラウザで開けるため問題ないと判断するシステム側のWinHTTP経路が異なるnetsh winhttp show proxyを確認する
証明書をすべてRootストアへ入れる不要な信頼範囲の拡大につながる中間証明書はLocalMachineのCAストアへ入れる
1枚の中間証明書だけを固定するOCSP証明書の切り替えで再発する通信を許可するか、継続的に証明書を更新する
19041.7546をOSビルドとして探すSSUとOSビルドを混同するSSUと19044／19045のOSビルドを別々に確認する
最初からDISMやSFCを繰り返すファイアウォール遮断は修復されない先にFQDN、ポート、プロキシ、IMDS検証を確認する

KB5104021の証明書チェーン問題を解消するための確認順序

KB5104021後のAzureホスト検出失敗は、次の順序で切り分けると原因を特定しやすくなります。

  1. 対象OS、エディション、ESUまたはLTSCの条件を確認する
  2. KB5120249または対応する後続の累積更新プログラムを適用する
  3. SSU 19041.7546とOSビルドをそれぞれ確認する
  4. AIA・CRL・OCSP用FQDNへのHTTP 80を許可する
  5. 必要に応じてMicrosoftの証明書配布先へのHTTPS 443も許可する
  6. WinHTTPプロキシとプロキシ側のアクセスログを確認する
  7. Azure IMDS Verification Toolを再実行する
  8. [MISS]やUntrustedRootが残る場合だけ、証明書ストアを確認する
  9. 最後にCAPI2、WindowsUpdate.log、CBS.logで詳細を調査する

実務では、最初から全端末へ展開せず、影響を受けているAzure VMを1台選び、ファイアウォール変更前後でIMDS検証結果を比較するのが安全です。検証に成功した構成を、同じネットワーク経路を使用する端末グループへ段階的に展開してください。

Windows10
Windows Update Azure 証明書チェーン SSU KB5104021

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次