eMudhraの中間認証局8件で秘密鍵を容易に復元可能、偽HTTPS証明書発行の危険性―世界のブラウザ・OS・開発ツールが緊急対応

セキュリティニュース

投稿日時: 更新日時:

eMudhraの中間認証局8件で秘密鍵を容易に復元可能、偽HTTPS証明書発行の危険性―世界のブラウザ・OS・開発ツールが緊急対応

インドの電子証明書事業者eMudhraが管理する中間認証局(中間CA)8件で、秘密鍵の生成処理に不備があり、公開証明書から秘密鍵を容易に復元できることが判明しました。2026年10月17日(UTC)に研究者から報告を受けたMozillaなどは、対象証明書の信頼を取り消す対応を進めています。8件のうち6件はHTTPSなどのTLS証明書発行用、2件はコード署名用で、悪用されるとWebサイトのなりすましや不正なソフトウェア署名につながるおそれがあります。

eMudhraは10月21日、2025年4月30日の鍵生成作業で本来の強い鍵とは別に弱い鍵が生成され、その弱い鍵が中間CA証明書の発行に用いられたと説明しました。ブラウザ向けの遮断は進んだ一方、独自の証明書ストアを使う業務システムやコンテナ、開発ツールでは別途更新が必要になる場合があります。

eMudhra中間CAの秘密鍵問題のサマリー

  • 影響を受けた中間CAは8件。TLS用6件とコード署名用2件に分かれる。
  • 秘密鍵は楕円曲線暗号P-384を用いていたものの、値が256未満という異常に小さい状態で生成されており、公開鍵から短時間で復元できる。
  • 研究者「Wayne」が10月17日(UTC)に8件の鍵で電子署名できる証拠を認証局・主要ブラウザ事業者へ提出。Mozillaも独立して秘密鍵の復元を確認した。
  • eMudhraは10月18日(UTC)に8件を失効。Sectigoによるクロス署名も対応対象となった。
  • FirefoxとChromeは10月17日、Appleは19日、Microsoftは20日までに対象の信頼を遮断する措置を実施した。
  • Chrome/Firefox以外のアプリ、サーバー、組み込み機器では失効情報の取得や確認が不十分な場合があり、証明書ストアや製品更新が必要となる。
  • eMudhraは問題の中間CAから利用者向け証明書を発行していないと説明。10月21日時点の公表情報では、攻撃者による偽証明書の悪用は確認されていない。
  • eMudhraはインフラへの侵入やデータ流出を否定し、インド国内のDSC・eSign事業は影響を受けていないと説明した。
項目 確認内容
認証局 eMudhra(emSignブランド)
問題の発生元 2025年4月30日の鍵生成作業(KGC)
対象 中間CA 8件(TLS用6件、コード署名用2件)
技術的な問題 P-384の秘密鍵が不適切に生成され、公開鍵から復元可能
第三者による発見・報告 2026年10月17日(UTC)
証明書失効 2026年10月18日(UTC)
想定される影響 偽のTLS証明書によるWebサイトなりすまし、通信傍受・改ざん、偽のコード署名
主な緊急対策 影響のある中間CAの遮断・失効、ルート証明書の信頼見直し、ソフトウェア更新

なぜ秘密鍵を公開証明書から復元できたのか

通常、中間CAの秘密鍵は外部へ公開されず、その公開鍵から秘密鍵を推定することは現実的に困難です。しかしインドのインシデント対応機関CERT-Inによると、今回のP-384楕円曲線秘密鍵は値が256未満であり、公開鍵からほぼ瞬時に復元できる状態でした。P-384という暗号方式そのものが破られたのではなく、鍵生成時に安全な乱数・鍵が適切に使用されなかったことが問題です。

eMudhraは、2025年4月30日にFIPS 140-2 Level 3のハードウェアセキュリティモジュール(HSM)を用いて鍵生成作業を実施したものの、鍵を包む・復元する「wrap/unwrap」処理の不備で強い鍵とは別に弱い鍵が作られ、後者が証明書署名要求に使用されたと説明しています。HSMの使用や第三者監査の実施だけでは、生成された鍵や鍵識別子の取り違えを防止できなかった形です。同社は詳細な根本原因を引き続き調査しています。

問題を発見した研究者は「Wayne」と名乗り、8件それぞれの秘密鍵を用いて同じ文面に署名し、秘密鍵を利用できることを証明しました。Mozillaの調査記録によると、10月17日20時06分(UTC)に報告を受信し、21時48分(UTC)には独自に秘密鍵を復元できたとしています。

偽のHTTPS証明書を作られると何が起きるのか

中間CAは、上位のルート認証局から信頼を委ねられ、Webサイトなどの証明書を発行できる立場にあります。攻撃者が対象の秘密鍵を復元すると、その中間CAから発行されたように見せかけた証明書を、攻撃者が管理していないドメインに対しても作成できるおそれがあります。

たとえば攻撃者が通信経路上で接続を妨害・転送できる環境では、偽証明書を使って正規サイトになりすまし、認証情報などの通信を傍受・改ざんする中間者攻撃(MitM)につながる可能性があります。コード署名用の鍵についても、不正なソフトウェアを信頼できる認証局の署名が付いたものと誤認させる危険があります。

ただし、偽証明書を発行できる可能性と、現実に利用者の通信が傍受された事実は別です。eMudhraは問題の8件からエンドエンティティ証明書を発行していないと説明しています。公開されているCertificate Transparency(CT)ログにも、問題の中間CAから発行された証明書は確認されていません。CTを検証しないクライアントも存在するため、これだけで過去の悪用を完全に否定することはできません。

ブラウザ4社が遮断、Mozillaは約3時間で配布完了

Mozillaは報告を受けた10月17日(UTC)に、Firefox向けの失効情報配信機構OneCRLで問題のTLS中間CAを遮断しました。同日22時59分(UTC)までに標準設定のFirefox利用者向け配布を終えたとしています。失効情報を受け取れない特殊な設定の利用者向けには、10月20日にFirefox 158.0.1およびFirefox ESR 115.43.1/153.5.1も公開しました。

GoogleはChromeのCRLSetによる遮断を10月17日、Appleは19日、Microsoftは20日までに対応したと関係者が説明しています。eMudhraは18日に対象8件を失効させました。また、MozillaはNSS 3.131.1で「emSign ECC Root CA – G3」を信頼対象から削除する対応を進めています。CERT-Inによると、Chrome Root Store側で予定されるルート証明書の削除は10月27日から順次反映される見通しです。

影響対象の中間CAは複数の信頼経路を持ち、一部にはSectigoのクロス署名も存在します。このため、中間CAだけでなく、ルート証明書やクロス署名を含めた証明書チェーンを確認する必要があります。ただし「AAA Certificate Services」などのルート証明書を組織判断なしに一律削除すると、問題のない別の証明書まで信頼されなくなり、接続障害が発生する場合があります。

Go、Java、Python、Linuxなどにも影響が拡大

今回の問題はWebブラウザだけで完結しません。API通信を行うサーバーや開発ツール、業務用エージェント、組み込み機器などでは、独自に証明書ストアを持つ場合や、失効リストを確認しない場合があります。OSやブラウザの更新だけでは当該クライアントの信頼設定が変わらないことがあります。

コミュニティが運営する注意喚起サイトでは、次のような更新が案内されています。適用前には各製品の正式なリリース情報と運用中のバージョンを確認してください。

製品・環境 公表されている対応例
Go 1.27.3、1.26.10。既存のGo製バイナリは修正版での再ビルドが必要
Mozilla NSS 3.131.1
Python certifi 2026.10.19
pip 26.2.2
uv 0.13.4
Java OpenJDK/Oracle JDKの対応リリース。独自のcacertsを持つ環境に注意
Node.js 22.23.4、24.22.1、26.12.1
Electron 44.9.1、43.8.1、42.11.16
Linux/コンテナ ディストリビューションのca-certificates更新、イメージの再構築・再配布

JavaはOSの証明書ストアとは別にJDK内のcacertsを利用することがあり、OS側のCA更新だけでは足りない場合があります。Pythonのcertifi、Rustのwebpki-roots、コンテナ内のCAバンドルなども同様に、依存関係を個別に確認する必要があります。

GoについてはGoの緊急更新とCVE-2026-111943を扱った既報で、修正版の提供と実行ファイルの再ビルドが必要になる理由を整理しています。

情報システム部門が確認したい対応事項

  1. 社内のブラウザとOSを更新し、管理対象端末に失効・信頼停止情報が配信されているか確認する。
  2. 公開Webサイトだけでなく、社内のAPIクライアント、CI/CD、バッチ処理、Java・Go・Pythonなどの実行環境、コンテナ、VPN機器、IoT機器が使用するCA証明書ストアを棚卸しする。
  3. 問題の中間CAとクロス署名証明書を含むチェーンが信頼されないことを、代表的なクライアント環境で検証する。証明書エラーを無視する設定へ変更しない。
  4. 自社サービスが「emSign ECC Root CA – G3」など、信頼見直しの対象となるルートに依存している場合は、失効・信頼停止後の接続影響を確認し、必要に応じて別の信頼できる認証局へ証明書を切り替える。
  5. 失効情報を取得しない古い機器や保守終了製品は、更新可否を調べたうえでネットワークの制限や利用停止を判断する。

本件は「eMudhraのサーバーに侵入した攻撃者が秘密鍵を盗んだ」という事案ではありません。同社はインフラ侵害と顧客データの漏えいを否定し、インド国内の電子署名関連事業も影響を受けていないと発表しています。一方で、秘密鍵を復元可能な証明書が公開の信頼基盤に組み込まれていた点は、製品やOSを横断した点検を要する問題です。

出典