eMudhra のセキュリティインシデント、信頼された証明書の署名に使われる秘密鍵の脆弱性が露呈

研究者らは、公開されている証明書データから秘密鍵を抽出できることを発見しました。これにより、eMudhra の認証局（CA）が発行した8件の中間証明書が危殆化しました。

このインシデントは2026年10月20日に公表され、ブラウザー各社やトラストストアが緊急ブロックに踏み切りました。認証局の暗号鍵生成プロセスに不備があったことも明らかになっています。

影響を受けた証明書は、主要ブラウザーのルートプログラムが信頼する6件のTLS中間証明書と、Microsoft が信頼する2件のコード署名用中間証明書です。

これらは欧州と米国の事業で使われる eMudhra の G3B および G3C シリーズに属します。さらに、同じ侵害された公開鍵を含む Sectigo のクロス署名証明書も、失効させる必要がありました。

eMudhra のセキュリティインシデント

Mozilla の調査担当者である Dennis Jackson 氏が報告したところによると、影響を受けた8つの P-384 秘密鍵はいずれも256未満の整数値でした。そのためエンコードされた値は、最後の1バイトを除いてほぼゼロでした。

この鍵は強力な暗号保護を提供するどころか、候補の範囲が極めて狭いため、単純な総当たりや離散対数アルゴリズムでほぼ瞬時に復元できました。

鍵が生成されたのは、2025年4月30日に行われたセレモニーです。研究者の Wayne 氏は、侵害された各鍵で「We have a problem here – Wayne」というメッセージに署名して鍵を掌握していることを示し、10月17日にルートプログラム各社へ通知しました。

Mozilla は同日夜、Wayne 氏の手法を知らないまま独自に鍵を復元しました。これにより、この脆弱性に再現性があることが確認されました。

Vulnerabilityassessment service

eMudhra の予備調査によると、鍵生成スクリプトが変更され、エクスポート用の鍵に対するラップ／アンラップのテストが追加されていました。

ハードウェアセキュリティモジュール（HSM）内では、当初は強力な鍵が作成されていました。しかし、欠陥のあるコードが脆弱な代替鍵を生成していました。両者のラベルが似ていたため、担当者は証明書署名要求（CSR）を作成する際に、この脆弱な鍵を選んでしまいました。

同社は、これまでに確認されていた証明書失効リスト（CRL）の無効な署名も、この不一致が原因だったと説明しています。当初、これらのリストは元の鍵で署名されていました。ところが、脆弱な公開鍵を持つ証明書に対しては検証に失敗しました。

その後、リストは侵害された鍵で署名されました。eMudhra は複数の人為的ミスがあったことを認め、調査は継続中だとしています。

Firefox と Chrome は10月17日に、侵害された中間証明書をブロックしました。Apple が10月19日、Microsoft が10月20日に続きました。eMudhra は10月18日に8件の証明書を失効させ、Sectigo もその後、影響を受けたクロス署名を失効させました。ただし、失効確認が有効に機能していないクライアントは、ソフトウェアやトラストストアを更新するまで、脅威にさらされる可能性があります。

今回の開示では、証明書の透明性（CT）のログに、CTを強制するブラウザーへの悪用を示す記録は報告されていません。一方で、ブラウザー以外のクライアントに対する攻撃については、いまだ不明です。

Mozilla はその後、emSign ECC Root CA – G3 を緊急で信頼対象から外すよう要請しました。eMudhra はこのルートでの証明書発行を停止しました。移行が必要な証明書は約3万件に上り、その97%は ACME 経由で発行されたものだと見積もっています。

ユーザーは、ブラウザー、OS、開発用ランタイム、証明書バンドルの更新を優先してください。推奨される修正バージョンは、NSS 3.131.1、Python certifi 2026.10.19、pip 26.2.2 です。

管理者は、組み込まれたトラストストアを個別に評価する必要があります。ブラウザーの保護だけでは、コマンドラインツールや独自の CA バンドルを持つアプリケーションは自動的には守られないためです。

MTTRを21分短縮し、被害が出る前にサイバー脅威を阻止します。ANYRUNのサンドボックスをSOCに統合しましょう。