eMudhraの問題で、何を確認するのか
証明書は、接続先やソフトウェアの発行元を確かめるために使われます。証明書を受け入れる際に参照する保管場所や一覧が「証明書ストア」「信頼リスト」です。端末のOSと、利用するアプリが同じ一覧を使うとは限りません。
Microsoftの説明は、eMudhraの中間認証局の秘密鍵8個に関する問題を扱っています。第三者が鍵を復元できるおそれがあり、Webサイトのなりすましや、信頼できる発行元を装ったソフトウェアにつながる可能性があるとしています。Microsoft自身のシステムが侵害されたという発表ではありません。
ここでは、次の対応を混同しないことが大切です。
| 公式資料が説明する対応 | 業務担当者が保守先に確かめること |
|---|---|
| 10月20日のWindowsの拒否リストと、Edge・WebView2の別の更新による遮断 | 該当する端末・アプリへ保護が届いているか |
| 10月26日のWindows、27日のEdgeの信頼リストから、関連する7証明書を削除 | 利用環境に変更が反映され、影響する接続先を把握しているか |
| アプリ独自のストアへの対応と、影響する証明書の差し替え | OS側の作業とは別に、誰が対象を調べ、対応するか |
秘密鍵の8個と、信頼リストから削除する証明書の7個は、同じ対象を数えた数字ではありません。また、認証局による証明書の失効と、Microsoftの信頼リストからの削除も別の対応です。詳細な対象はTrusted Root Programの告知を保守先と照らしてください。
「更新済み」を端末・アプリ・証明書に分けて聞く
Microsoftの10月30日の案内は、Javaのキーストア、Pythonの証明書バンドル、コンテナーイメージなど、独自の証明書ストアはOS更新では変わらないと説明しています。これらを使っているだけで影響ありとはせず、実際に何を信頼しているかを開発元・保守先に確認します。
まずは既存の機器台帳・保守契約から、次の確認表を作ります。分からない欄は「対象外」ではなく「未確認」にします。
| 確認する範囲 | 保守先への質問 | 残す根拠 |
|---|---|---|
| Windows端末 | 証明書の自動更新と今回の信頼リストの変更は届いていますか。更新を止めた端末・社外へ接続しない端末はありますか | 対象端末、確認日、適用を確認した担当者と記録 |
| Edge・WebView2を使うアプリ | ブラウザーの版だけでなく、今回の保護や信頼リストの変更の到達を確認しましたか | 対象アプリ、確認方法、結果 |
| アプリ独自の設定 | OSとは別の証明書ストアや、手動で信頼を追加した証明書はありますか。開発元の対応案内はありますか | ストアの管理者、対象判断の根拠、必要な更新 |
| 自社が利用・提供する証明書 | 削除対象につながる証明書はありますか。差し替えや別の信頼経路への切り替えは必要ですか | 提供元の回答、変更予定、変更後の確認結果 |
Windowsの自動更新が届かない環境については、Microsoft Learnの管理資料に信頼リスト（CTL）を配布する方法があります。業務担当者が設定を変更する手順ではなく、管理者に配布経路と到達を確かめてもらうための資料として使ってください。
証明書を自社で発行・管理していないサービスは、提供元へ影響と対応範囲を聞きます。「Windows対応済み」という回答でアプリの欄まで完了にしないことが、この一覧の目的です。Brotliの記事は組み込まれたプログラムの更新を扱いますが、今回は証明書の信頼先と差し替えの確認です。
警告が出たら、回避せず保守先へ渡す
接続やソフトウェアの実行時に証明書の警告が出た場合は、警告を無視して先へ進めたり、証明書を「信頼する」に追加したりして解決扱いにしません。Microsoftも、影響する証明書の信頼を戻す前に、リスクとアプリ側の確認の仕組みを評価するよう求めています。
窓口には、発生日時、端末・アプリの名前、止まった操作、警告の文面を渡し、「今回の問題との関係」「安全に使える代替手順」「次の回答予定」を聞きます。画面を共有するときは、顧客情報・社内URL・認証情報が写っていないか確かめ、詳細な資料は保守先と合意した共有方法を使います。証明書の秘密鍵は添付しません。
警告の原因が今回のeMudhra問題とは限りません。逆に、警告が出ないことだけで影響なしとも判断できません。原因と対象の判定は保守先へ渡し、社内の責任者は、保守先が確認した代替手順や利用制限を踏まえて業務の継続方法を決めます。
想定シナリオ：PCの更新は済んだが、受発注アプリは回答待ち
Windows PCと保守会社が管理する受発注アプリを使う会社を例にします。
総務が「PCの更新は済んだ」と連絡を受けました。一方、受発注アプリに独自の証明書ストアがあるかは分かっていません。この時点で、一覧の表示は次のように分けます。
| 対象 | 状態 | 次にすること |
|---|---|---|
| PCの証明書更新 | 適用確認済み | 管理者の確認記録を参照できるようにする |
| 受発注アプリの信頼設定 | 保守先の回答待ち | 独自ストアの有無と対象判断の根拠を聞く |
| 接続先の証明書 | 差し替え要否の確認待ち | サービス提供元の回答を保守先に確認してもらう |
回答待ちの行には担当者と回答期限を付けます。対象外という回答が来たらその根拠を、更新や差し替えが必要なら作業予定と業務停止の有無を残します。作業が終わった後に、保守先の案内に沿って接続と主要な操作を確認し、結果を別の欄へ記録します。
費用は、保守契約内の対象確認、アプリの改修・更新、証明書の再発行・設定変更、時間外作業を分けて見積もってもらいます。期間は一律に決めず、回答待ち、作業日程、停止できる時間、変更後の確認を分けます。既存の表で追えるなら新しいシステムは不要です。
完了にする条件と、人が残す判断
担当者は、対象ごとに次の点をそろえてから責任者へ報告します。
- 対象・対象外の判断に、公式案内と利用環境を確認した根拠がある。
- 必要な更新・差し替えが、予定ではなく適用後の記録で確認できる。
- 主要な業務の動作を確認し、警告の回避や安易な信頼の復元で済ませていない。
- 残る未確認事項には、担当者・回答期限・利用上の扱いが決まっている。
未確認が残る行を完了にせず、確認済みの範囲と並べて報告します。この手順は保守分担の整理であり、この記事で実環境の証明書や更新の到達を検証したものではありません。
AIを使う場合も、公開された案内から質問の下書きを作るところまでにします。証明書の信頼可否や設定変更、業務を続けてよいかの判断は任せません。管理者や引き継ぎの整理は業務ツールの保守の記事、支援内容はサービス・料金で確認できます。相談するときは相談窓口へ、止まると困る業務と管理担当の分かる範囲をお伝えください。