MicrosoftがWindowsの定例外更新を公開：認証局の秘密鍵に重大な問題、7件の証明書を信頼リストから除外

Microsoftは2026年10月26日、証明書の信頼情報を自動受信できないWindows端末を対象に、定例外更新を公開した。認証局eMudhraの秘密鍵に問題が見つかったことを受け、関連する証明書をWindowsの既定の信頼リストから除外するための更新だ。インターネットに直接接続できない閉域環境など、証明書の信頼情報が自動更新されない端末での対応を目的としている。

問題のある中間認証局については、すでに10月20日にWindows側で遮断措置が取られている。今回の更新では、その上位に位置するルート証明書なども信頼リストから除外する。自動更新を利用できない環境では、中間認証局の遮断と上位証明書の信頼除外がそれぞれ反映されているかを確認するとともに、正規のサービスへの接続に影響が出ていないか検証する必要がある。

8件の秘密鍵と7件の証明書は異なる対象

今回の問題の発端は、eMudhraが運用する中間認証局の秘密鍵8件に見つかった不備だ。Microsoft Security Response Center（MSRC）の説明によると、このうち6件はTLS証明書、残る2件はコード署名用の証明書を発行する中間認証局の鍵だった。Microsoft自身のシステムが侵害されたわけではない。

Mozillaの調査では、8件の中間認証局で使用されていたP-384鍵について、秘密鍵の値が256未満だったと報告されている。本来、安全な方法で生成されるべき秘密鍵の値が極端に小さく、推測が容易になる問題だ。ただし、これは個々の鍵の生成方法に起因するものであり、P-384という暗号方式そのものが破られたわけではない。秘密鍵を推測できれば、その認証局になりすまして証明書に署名できる可能性があるため、該当する鍵に基づく証明書の信頼を取り除く必要がある。

Microsoftが公表した対応を時系列で整理すると、10月20日には問題の中間認証局を遮断し、10月26日には上位のルート証明書6件とクロス署名証明書1件を信頼リストから除外している。

ここで注意したいのは、問題となった8件の秘密鍵と、信頼リストから除外される7件の証明書は、同じ対象を別の方法で数えたものではないという点だ。中間認証局はルート認証局と利用者側の証明書をつなぐ役割を持ち、クロス署名証明書は別の認証局による署名を通じて信頼経路を構成する。上位の証明書を信頼リストから除外すると、問題の中間認証局を個別に遮断する場合とは、証明書チェーンの検証に及ぶ影響の範囲が異なる。

MSRCはさらに、問題の認証局が署名したTLS証明書を遮断するため、Microsoft EdgeとWebView2のCRLSetも別途更新したと説明している。10月26日にWindowsの信頼リストから除外された7件の証明書については、Edge側でも10月27日に信頼を取り消す予定としていた。ただし、その処理が実際に完了した時刻や、問題の鍵が悪用された事実は確認されていない。

また、Windowsの既定の信頼設定は、更新情報が各端末に届いて初めて変更される。管理者が独自に追加した信頼設定や、アプリケーションが個別に管理する証明書ストアについては、Windowsの更新とは別に確認しなければならない。

定例外更新の対象となるWindowsと適用条件

今回の定例外更新は、証明書の信頼リストを自動受信できないWindows端末を対象としている。Windows 11向けのKB5134133は、バージョン24H2、25H2、26H2向けの累積非セキュリティ更新として提供され、Microsoft Update Catalogから入手できる。

ただし、同じKB番号の更新でも、Windowsのバージョンによって適用条件は異なる。24H2と25H2では、2025年6月10日以降の更新が適用されている必要がある。また、複数のMSUパッケージやチェックポイント累積更新が関係する環境では、KBに記載された適用順序を確認しなければならない。特に閉域環境では、今回の更新パッケージだけを端末に持ち込んでも、すべての端末に適用できるとは限らない。

Microsoftが公開した主な対象製品と更新プログラムは次のとおりだ。

Windows 10については、バージョン番号だけで更新対象かどうかを判断できない。端末のエディションに加え、延長セキュリティ更新プログラム（ESU）や長期サービスチャネル（LTSC）の適用条件を、該当するKBの説明と照合する必要がある。Windows Server 2025でも、対象端末の条件と更新の適用順序を確認することが重要だ。

運用面で特に注意が必要なのが、再起動を抑えながら更新を適用するHotpatchへの影響だ。KB5134133によると、Hotpatchに登録された対象端末へ今回の更新を適用すると、2027年1月のベースライン更新をインストールするまで、新たなHotpatchを受け取れなくなる。Windows Server 2025向けのKBにもHotpatchに関する適用条件が記載されている。

このため、管理者は証明書の信頼設定を更新する必要性だけでなく、その後の更新運用への影響も考慮しなければならない。ただし、Hotpatchに関する制約は、すべてのWindows端末で更新プログラムの受信が停止することを意味するものではない。

閉域環境では2種類の証明書リストを確認する必要がある

Windowsの証明書信頼管理では、信頼する証明書と信頼しない証明書が別々のリストで管理される。今回の問題では、10月20日に行われた中間認証局の遮断と、10月26日に行われた上位証明書の信頼除外が、それぞれ異なるリストに関係している。したがって、片方のリストが更新されたことを確認しても、もう一方の変更まで端末に反映されたとは判断できない。

Microsoftの管理者向け文書では、インターネットに直接接続できない環境で、信頼済み証明書と信頼されない証明書のリストを配布する方法が説明されている。具体的には、外部から取得した証明書情報を内部のファイルサーバーへ配置し、グループポリシー（GPO）を使って端末に参照させる構成だ。組織の管理者は、証明書リストを自動受信できる端末とできない端末を区別し、後者について配布先の設定と実際の反映状況を確認する必要がある。

同文書では、証明書リストを検証するためのコマンドも紹介されている。信頼済み証明書のリストと、信頼されない証明書のリストでは、確認に使用するコマンドが異なる。

# 信頼済み証明書リストの検証
certutil -verifyCTL AuthRoot

# 信頼されない証明書リストの検証
certutil -verifyCTL Disallowed

前者は信頼済み証明書のリスト、後者は信頼されない証明書のリストを検証するためのコマンドだ。ただし、これらを実行するだけで、今回の変更が適切に配布されたことまで証明できるわけではない。管理者は最終同期時刻や対象証明書の状態も確認し、必要な変更が実際に反映されているかを確かめる必要がある。

また、Windowsの証明書リストが更新されても、端末上のすべてのアプリケーションが同じ信頼設定を使用するとは限らない。リストの配布が成功したことと、各アプリケーションが証明書を正しく検証できることは別の問題であり、実際の接続試験が必要となる。

証明書の信頼除外に伴う接続障害にも注意

問題のある証明書を信頼リストから除外する際には、正規のサービスへの接続を維持できるかも確認しなければならない。接続先のサーバーが提示する証明書チェーンに、今回除外されたルート証明書やクロス署名証明書が含まれている場合、別の有効な信頼経路が存在しなければ、正規のサービスであっても証明書の検証に失敗する可能性がある。一方、代替となる証明書チェーンを利用できる場合や、アプリケーションが異なる方法で証明書を検証する場合には、結果が変わることもある。そのため、今回の信頼除外による影響を、すべての環境で共通する接続障害として扱うことはできない。

組織の管理者はまず、自社が提供・利用するサービスの証明書チェーンを確認し、問題となったルート証明書やクロス署名証明書への依存がないかを調べる必要がある。該当する場合は、必要な証明書の移行を進めたうえで、実際に利用する端末やアプリケーションから接続を検証する。ブラウザーで正常にページを表示できたとしても、同じ接続先を利用する別の業務アプリケーションまで正常に動作するとは限らない。

Cloudflareの技術解説でも、アプリケーションによってはOSとは異なる証明書検証の仕組みや、独自の信頼ストアを使用する場合があると指摘している。Windowsの証明書リストを更新しても、こうしたアプリケーションの信頼設定が自動的に変更されるとは限らない。逆に、独自の信頼ストアに問題のある証明書が残っていれば、Microsoftが既定の信頼設定を変更した後も、Windowsとは異なる検証結果になる可能性がある。

今回の定例外更新で管理者が確認すべきなのは、更新プログラムが正常にインストールされたかどうかだけではない。信頼済み証明書と信頼されない証明書の両リストが端末に反映されたか、接続先の証明書チェーンに問題がないか、アプリケーションがどの信頼設定を使用しているかを、それぞれ確認する必要がある。これらを検証することで、問題のある秘密鍵への対策が適切に機能しているかを判断するとともに、正規サービスへの接続を維持できているかを確かめられる。