Chromeは10月27日、emSign ECC Root CA–G3のルート証明書をトラストストアから削除する予定です。このルート証明書にTLS証明書がチェーンしているウェブサイトが影響を受ける可能性があります。Googleは、侵害された8つのeMudhra中間証明書によって発行されたものではない正規の証明書を含め、一部の正規の証明書がChromeで機能しなくなると警告しています。
このルート証明書の削除は、8つのeMudhra中間認証局（CA）の秘密鍵が不十分な乱数で生成され、公開証明書から復元可能だったことが10月17日に明らかになったことを受けたものです。Googleは報告を受けて間もなくこれらの中間CAをブロックしましたが、親ルートの削除によって、より広範な証明書の置き換えが必要になります。
証明書チェーンがemSign ECC Root CA–G3で終端している公開ウェブサイトは、別の信頼された階層から発行された置き換え用証明書を入手する必要があります。組織は、証明書の信頼性を独自に管理する外部連携、コンテナ、VPN、アプリケーションも確認しなければなりません。
優先すべきことは、影響を受ける証明書チェーンを特定し、置き換えたうえで、依存するサービスが引き続き動作することを確認することです。
Chromeの影響を受けるeMudhra TLS証明書を置き換える方法
によると、Google、emSign ECC Root CA–G3を使用しているウェブサイト運営者は、Chrome Root Storeに含まれる別の階層から新しいTLS証明書を直ちに取得してインストールする必要があります。
管理者は次の手順に従ってください。
- インベントリーを作成する。TLS証明書を提示する、インターネットに公開されたウェブサイト、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は、侵害された中間CAを失効させ、G3ルートの下で新たな証明書を発行することを停止しました。
Chromeが10月27日に実施する対応はさらに踏み込み、emSign ECC Root CA–G3自体をChrome Root Storeから削除します。
つまり、ある証明書が正規のもので、有効期限内で、侵害された8つの中間CAとは無関係であっても、信頼されたチェーンが削除されたルートに依存していれば、Chromeで検証に失敗する可能性があります。
この違いが重要なのは、証明書の有効期間がブラウザーの信頼判断に優先するわけではないためです。以前に、自社の証明書が侵害された8つの中間CAによって発行されたものではないと確認した運用担当者も、親ルートを確認する必要があります。
Chrome、Androidなどのプラットフォームも対応
Googleは10月17日、ChromeのCRLSetメカニズムを通じて、侵害された8つの中間CAをブロックしました。この保護機能は、ブラウザー全体を更新しなくても配布されました。
Googleは別途、太平洋時間10月27日朝にemSign ECC Root CA–G3をChrome Root Storeから削除する予定を設定しました。Chrome CanaryとBetaには、この変更が先に適用されました。
Androidデバイスには10月19日、Google Play開発者サービスを通じて、侵害された中間証明書に対する保護機能が提供されました。Googleは、デバイスを再起動すればユーザーが直ちに更新を実行できると説明しました。
Mozillaも侵害された中間CAをブロックし、影響を受けるルート証明書をトラストストアから削除する手続きを進めました。Appleは10月19日、影響を受けるTLS中間CAのブロックを開始しました。
これらの対応は、証明書の信頼性に関する問題の異なる部分に対処するものです。侵害された中間CAをブロックすると、クライアントはそれらの鍵を通じて発行された証明書を信頼できなくなります。ルート証明書の削除は、より広範な証明書チェーンに影響します。
したがって組織は、サポート対象のブラウザー、OS、アプリケーション全体で証明書の動作を検証する必要があります。
ブラウザーの先に：セキュリティチームが確認すべきこと
ブラウザーやOSの変更が、独自の証明書ストアや検証プロセスを使用するソフトウェアに必ずしも反映されるとは限りません。
NHS Englandのガイダンスでは、コンテナ、開発ツール、IoTデバイス、運用技術、モバイルアプリケーション、内部PKIにまたがる依存関係を確認するよう求めています。
独自のTLS検証を行うVPNやその他のアプリケーションでは、ベンダーによる更新も必要になる可能性があります。
Goプログラミング言語はその一例です。Goのセキュリティチームは、侵害された中間CAを含む証明書チェーンをブロックするため、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証明書を組み込んだシステム、独自に管理されたトラストストア、または該当するベンダーの保護機能がまだ提供されていないソフトウェアバージョンを使用するシステムを、アプリケーション所有者が優先的に確認すべきです。
悪用は未確認、調査は継続
ベンダーから公開された報告では、侵害された中間CAの秘密鍵が悪意を持って悪用されたことは確認されていません。
Googleによると、影響を受けた6つの中間CAにチェーンするTLS証明書は、Chromeがそれらをブロックする前にCertificate Transparencyへ記録されていませんでした。そのため、Certificate Transparencyの要件を適用するクライアントが、これらの中間CAから発行された不正な証明書を受け入れることはありませんでした。
Cisco Talosは、10月21日時点で、侵害された証明書に関連する悪意あるインシデントは確認されていないと報告しました。
eMudhraも、より広範なインフラ侵害の証拠は見つかっていないと説明しています。
これらの調査結果は、悪用が不可能だったことを証明するものではありません。各ベンダーが声明を発表した時点で確認できた事実を示しているにすぎません。
このインシデントは、HTTPS接続だけではウェブサイトの正当性を証明できない理由も示しています。フィッシング証明書に関する過去の報道で示されたように、攻撃者は認証局を侵害しなくても、自分が管理するドメインの有効なTLS証明書を取得できます。
影響を受けるウェブサイト運営者が直ちに行うべきことは、emSign ECC Root CA–G3にチェーンする証明書を置き換え、新しいチェーンが信頼されていることを確認することです。その後、セキュリティチームは依存関係を広範に確認し、侵害された中間CAを引き続き信頼する可能性のあるアプリケーションやデバイスを特定する必要があります。
Googleは、eMudhraに残るCA証明書の確認を続けています。管理者は、10月27日の削除でインシデントが終わると決めつけず、今後の信頼設定の変更についてベンダーのアドバイザリーを監視する必要があります。
あわせて読みたい：影響を受けるシステム全体でセキュリティ更新を調整するために利用できるパッチ管理ツールを確認。