認証局eMudhraの中間証明書、秘密鍵が「数ミリ秒」で復元可能な脆弱性　大手各社が緊急遮断

公開 2026年10月21日 09時17分

[ITmedia]

印刷する Googleで優先するソースとして追加

　インドのデジタルトラストサービス企業eMudhraが運営する認証局（CA）の中間証明書8件について、署名に使う秘密鍵が第三者でも簡単に復元できる状態状態にあったと判明した。米Mozillaが10月20日（現地時間）に公式ブログで公表し、米Googleや米Cloudflareなども対応を明らかにした。

　悪用されれば任意のWebサイトになりすますことが可能になる。主要Webブラウザは既に該当証明書をブロックしているが、ブラウザ以外のソフトウェアではアップデートが必要になる。

　Webサイトとの通信を暗号化するHTTPSでは、「TLS」という仕組みを使い、接続先のWebサイトが本物かどうかを電子証明書（TLS証明書）で確認している。この証明書を発行するのがCAだ。WebブラウザやOSに組み込まれた「ルート証明書」を起点に、その下にある「中間証明書」が実際にWebサイト向けの証明書に署名する仕組みになっている。中間証明書の秘密鍵は、いわば証明書に押す「実印」に当たる。この鍵を第三者が手にすると、どのドメインに対しても、Webブラウザが正規と認める証明書を発行できてしまう。Mozillaは、利用者の通信に割り込める攻撃者がこうした証明書を使えば、Webサイトになりすまして通信内容を盗み見たり改ざんしたりできる恐れがあると説明している。

　Mozillaのバグ管理システム「Bugzilla」で公開された経緯によると、Wayneと名乗る研究者が10月17日（協定世界時）に米Apple、Google、米Microsoft、Mozilla、eMudhraへ報告した。報告には、8件それぞれの秘密鍵で署名したメッセージが添えられており、実際に鍵を持っていることを証明していた。8件のうち6件はWebサイト（TLS）用で、Google、Mozilla、Microsoft、Appleの各ルートプログラムで信頼されている。残る2件はMicrosoftが信頼するコード署名用だ。

　問題の原因は鍵の作り方にあった。今回の鍵は「P-384」という楕円曲線暗号の鍵で、本来は膨大な範囲から無作為に選んだ数でなければならない。ところがMozillaの調査では、8件の秘密鍵はすべて256未満の整数だった。最後の1バイト以外は実質的にゼロで、ほぼ瞬時に復元できるという。Mozillaは報告者の手法を知らないまま独自に鍵を復元できたほか、手元のAIエージェントに簡単な指示を与えただけでも1回目で復元できたとしている。セキュリティ研究者のスコット・ヘルム氏は自身のブログで、鍵の1つは「4」、ほかに「56」「115」というものもあり、ノートPCで1秒もかからず全て復元できたと報告している。

スコット・ヘルム氏のX投稿

　eMudhraは20日に公式サイトで声明を出し、影響は2025年4月の鍵生成作業で作った特定の中間証明書に限られると説明した。ルート証明書の秘密鍵やほかの中間証明書には影響しないという。対象の中間証明書は1件を除いて本番運用しておらず、その1件も含め、Webサイト向けなどの証明書は一切発行していないとしている。この点は社内分析に加え、CTの公開記録でも裏付けられたという。同社はBugzillaで原因も説明している。それによると、8件は欧州と米国のデータセンター向けに作ったもので、作業に使ったスクリプトの欠陥により、ハードウェアセキュリティモジュール（HSM）上で強度の極めて低い鍵ペアが誤生成され、名前が似ていたため誤って本番に適用してしまったという。同社は複数の工程で人為的ミスがあったと認めている。ヘルム氏は、弱い鍵が2025年4月から約17カ月間にわたり、公開されている証明書から誰でも復元できる状態だったと指摘している。

　Mozillaは報告を受けてから3時間足らずで、失効証明書リスト「OneCRL」を通じ、通常設定のFirefoxすべてで該当証明書を遮断した。Chromeは17日に8件のブロックを始め、Apple製品は19日、Microsoftは20日に続いた。eMudhraは18日に8件を失効させ、一部に相互署名していた米Sectigoも19日に失効処理を完了した。Mozillaは20日、OneCRLの更新を受け取れない設定のユーザー向けに「Firefox 158.0.1」などを公開し、証明書ライブラリ「NSS」の更新版では上位のルート証明書を削除した。

　Mozillaはさらに、複数の人物が独自に鍵を復元して一部を公表したことを受け、ルート証明書「emSign ECC Root CA - G3」の信頼を緊急に取り消すと決めた。Googleも同ルートをChrome Root Storeのバージョン43で削除するとし、事態の深刻さから、eMudhraの残るルート証明書の扱いも精査している。eMudhraは同ルート配下での発行を停止した。移行が必要な証明書は約3万件と見込み、RSA方式のルート配下に移すとしている。

　実際の悪用は現時点で報告されていない。Googleによると、ブロック前に問題のWebサイト用中間証明書につながる証明書は、発行記録を公開する「Certificate Transparency」（CT）のログに1つも登録されておらず、CTを必須とするWebブラウザでは偽の証明書が標準で信頼されることはなかった。Googleは、Chromeが信頼するほかのCAの証明書も調べたが、同様の問題は見つからなかったとしている。Cloudflareも、自社サービスで悪用は確認していないとしている。

　懸念されているのはWebブラウザ以外のソフトウェアだ。Mozillaは、多くの端末やシステムが失効情報を受け取る有効な仕組みを持っていないことに強い懸念を示している。ヘルム氏によると、curlやPython、Node.js、Go、Java、パッケージマネジャーなどの多くは、ディスク上の証明書リストを信頼し、標準では失効もCTも確認しないため、偽の証明書でも検証を通ってしまう恐れがある。プログラミング言語Goの開発チームは19日、問題の中間証明書を含む証明書チェーンを拒否する修正を標準ライブラリに加え、バージョン1.27.3と1.26.10として公開した。Goのセキュリティチームのローランド・シューメーカー氏は、特にLinuxのユーザーは信頼する証明書リストの自動更新をすぐには受け取れない可能性が高いため、公開を急いだと説明。悪用が容易なことから、攻撃者に先行させないよう、告知では問題の内容をあえて伏せたとしている。

　Cloudflareは「Cloudflare One Client（WARP）」や「1.1.1.1」アプリ、「cloudflared」の更新版を公開した。一方、顧客が自ら運用するサーバのソフトウェアや信頼設定は、顧客側での対応が必要だとしている。更新後に証明書エラーが出ても、検証を無効にして回避しないよう呼び掛けた。Mozillaは、対策済みパッケージの一覧やLinuxディストリビューション別の回避手順も公開している。