Googleは10月27日、Chromeの信頼ストアからルート証明書「emSign ECC Root CA–G3」を削除する予定です。このルートにチェーンされたTLS証明書を使い続けているWebサイトは、アクセスに支障が出る恐れがあります。Googleは、eMudhraの侵害された8つの中間証明書から発行されていない正規の証明書も含め、一部の正当な証明書がChromeで機能しなくなると警告しています。
今回のルート削除は、10月17日に公表された問題を受けた措置です。eMudhraの中間認証局(CA)8件の秘密鍵が、不十分なランダム性で生成されており、公開証明書から復元できる状態でした。Chromeは報告を受けてまもなくこれらの中間証明書をブロックしましたが、親ルートの削除により、証明書の入れ替えが必要な範囲はさらに広がります。
証明書チェーンの終端がemSign ECC Root CA–G3になっている公開Webサイトは、別の信頼された階層の証明書に入れ替える必要があります。あわせて、外部への通信連携、コンテナ、VPN、独自に証明書の信頼を管理するアプリケーションも確認しなければなりません。
まずは影響を受ける証明書チェーンを特定して入れ替え、依存するサービスが引き続き動作することを確認することが最優先です。
Chromeの影響を受けるeMudhra製TLS証明書の入れ替え手順
Googleによると、emSign ECC Root CA–G3を利用しているWebサイト運営者は、Chrome Root Storeに含まれる別の階層から新しいTLS証明書を直ちに取得し、インストールする必要があります。
管理者は次の手順で対応してください。
- インベントリを作成する。TLS証明書を提示するインターネット公開のWebサイト、API、ロードバランサー、リバースプロキシなどのサービスを洗い出します。eMudhraの証明書に依存している可能性がある社内サービス、開発ツール、コンテナ、アプリケーションも含めます。
- 実際の証明書チェーンを確認する。
openssl s_client -showcerts -connect example.com:443 -servername example.comを実行します。example.comは確認対象のホスト名に置き換えてください。このコマンドはサーバーが提示する証明書を表示しますが、通常、ルート証明書は含まれません。 - トラストアンカーを確認する。発行元の中間証明書を特定し、証明書がemSign ECC Root CA–G3にチェーンされているかを判断します。OpenSSLの出力にルートが表示されないからといって、サービスが影響を受けないとは限りません。
- 代替の証明書を取得する。影響を受ける証明書を、信頼された別のパブリックCA階層で再発行します。別の中間証明書を導入しても、結果として削除対象のルートに依存するチェーンのままでは不十分です。
- すべての環境に展開する。冗長化されたサーバー、ゲートウェイ、ロードバランサーなど、TLSを終端するすべての箇所を更新します。代替証明書とあわせて、正しい中間証明書がインストールされていることも確認します。
- 依存する接続をテストする。影響を受けるエンドポイントに接続するブラウザーアクセス、API呼び出し、連携システムを検証します。これらのシステムは、証明書の信頼を異なる方法で判断している場合があります。
- 展開後も監視する。TLS検証の失敗、想定外の証明書警告、証明書チェーンの変化に注意します。
証明書の入れ替えにあわせて、サービスのTLS設定も確認する必要があります。最近のNGINXの脆弱性は、有効な証明書があるだけで接続全体が安全だと考えてはならず、TLS関連の設定や影響を受けるサーバーのバージョンを見直すべきだということを示しています。
正常な証明書でも使えなくなる理由
eMudhraをめぐる2つの措置は混同されやすいものの、同じものではありません。
10月17日の緊急ブロックの対象は、秘密鍵を復元できる8つの特定の中間CAです。このうち6つはTLS証明書用、2つはコード署名用でした。
Cisco Talosは、複数の秘密鍵の値が、期待されるランダム性に反して1桁または2桁の小さな数値だったと報告しています。このため鍵の復元が現実的となり、証明書が偽造されるリスクが生じました。
欠陥は、2025年4月30日に行われた鍵生成セレモニーで発生しました。eMudhraはその後、侵害された中間証明書を失効させ、G3ルート配下での新規証明書の発行を停止しています。
10月27日のChromeの措置はさらに踏み込み、emSign ECC Root CA–G3そのものをChrome Root Storeから削除します。
つまり、正当で有効期限内であり、侵害された8つの中間証明書とは無関係の証明書でも、信頼されるチェーンが削除対象のルートに依存していれば、Chromeで検証に失敗します。
この違いが重要なのは、証明書の有効期間がブラウザーの信頼判断を覆すことはないためです。自社の証明書が、侵害された8つの中間証明書から発行されたものではないと確認済みの運営者も、親ルートを確認する必要があります。
Chrome、Androidなど各プラットフォームの対応
Googleは10月17日、ChromeのCRLSetの仕組みを使って、侵害された8つの中間証明書をブロックしました。この保護は、ブラウザーの全面的なアップデートを必要とせずに配信されています。
これとは別に、emSign ECC Root CA–G3をChrome Root Storeから削除する作業が、太平洋時間の10月27日午前に予定されています。Chrome CanaryとBetaには、この変更が先行して適用されました。
Androidデバイスには、10月19日にGoogle Playサービスを通じて、侵害された中間証明書に対する保護が配信されました。Googleによると、デバイスを再起動すれば即座に更新を適用できます。
Mozillaも侵害された中間証明書をブロックし、影響を受けるルートを信頼ストアから削除する手続きを進めています。Appleは10月19日、影響を受けるTLS中間証明書のブロックを開始しました。
これらの措置は、証明書の信頼をめぐる問題の異なる側面に対応するものです。侵害された中間証明書をブロックすれば、その鍵を通じて発行された証明書をクライアントが信頼することを防げます。一方、ルートの削除は、より広い範囲の証明書チェーンに影響します。
そのため各組織は、サポート対象のブラウザー、OS、アプリケーションのすべてで、証明書の挙動を確認する必要があります。
ブラウザー以外にも注意:セキュリティチームが確認すべき点
ブラウザーやOSの変更は、独自の証明書ストアや検証プロセスを使うソフトウェアには、必ずしも反映されません。
NHS Englandのガイダンスは、コンテナ、開発ツール、IoTデバイス、制御技術(OT)、モバイルアプリケーション、社内PKIにまたがる依存関係の確認を求めています。
独自にTLS検証を行うVPNなどのアプリケーションでは、ベンダーによるアップデートが必要になる場合もあります。
プログラミング言語Goは、その一例です。Goのセキュリティチームは、侵害された中間証明書を含む証明書チェーンをブロックするため、Go 1.27.3と1.26.10をリリースしました。この問題はCVE-2026-111943として追跡されています。
影響を受けるバージョンのGoを使用している組織は、セキュリティアドバイザリーを確認し、必要に応じてアプリケーションを再ビルドまたは再デプロイしてください。
ほかのベンダーも関連する問題に個別の識別子を割り当てており、Oracle JavaにはCVE-2026-91403、FirefoxにはCVE-2026-113470があります。管理者は、すべてのプラットフォームで同じ修正が適用できると考えず、各ベンダーのアドバイザリーに従ってください。
証明書の信頼は、アプリケーションが信頼されたルートをどのようにインストール・管理するかによっても左右されます。たとえば、最近公開されたFiddler Classicの脆弱性は、Windowsの信頼ストアにルート証明書をインストールする動作に関わるものでした。eMudhraとは無関係ですが、アプリケーションレベルの証明書の扱いを別途見直す必要がある理由を示しています。
今回のeMudhraの問題では、CA証明書を同梱しているシステム、独自に管理する信頼ストアを持つシステム、関連するベンダーの保護が未適用のバージョンを使っているソフトウェアを、アプリケーションの管理者が優先して確認すべきです。
悪用は未確認、ただし調査は継続
現時点で入手できるベンダーの報告では、侵害された中間証明書の鍵が悪意をもって悪用された事実は確認されていません。
Googleによると、影響を受けた6つの中間証明書にチェーンされるTLS証明書は、Chromeがブロックするまでの間、Certificate Transparencyにログ記録されていませんでした。このため、これらの中間証明書による偽造証明書は、Certificate Transparencyの要件を適用しているクライアントには受け入れられなかったはずです。
Cisco Talosは、10月21日時点で、侵害された証明書に関わる悪意ある事案は観測されていないと報告しました。
eMudhraも、インフラ全体が侵害された形跡は見つかっていないとしています。
ただし、これらの調査結果は、悪用が不可能だったことを裏づけるものではありません。各ベンダーが声明を出した時点で観測できた内容を示しているにすぎません。
この問題は、HTTPS接続であること自体がWebサイトの正当性の証明にはならないことも示しています。以前のフィッシング用証明書に関する報道が明らかにしたとおり、攻撃者は認証局を侵害しなくても、自らが管理するドメインの有効なTLS証明書を取得できます。
影響を受けるWebサイトの運営者がまず行うべきは、emSign ECC Root CA–G3にチェーンされた証明書を入れ替え、新しいチェーンが信頼されることを確認することです。そのうえでセキュリティチームは、より広範な依存関係の調査を完了し、侵害された中間証明書を信頼し続ける可能性があるアプリケーションやデバイスを洗い出す必要があります。
Googleは、eMudhraの残りのCA証明書についても引き続き調査しています。管理者は、10月27日のルート削除で一連の問題が収束すると考えず、さらなる信頼変更に関するベンダーのアドバイザリーを注視してください。
関連記事:影響を受けるシステム全体でセキュリティ更新を調整するために利用できるパッチ管理ツールを確認する。
