eMudhraのCA鍵が漏えい、Go・Firefox・NSSが修正版を公開

インドの認証局eMudhraが発行した中間証明書8件について、その秘密鍵が流出していました。MozillaとGoogleが2026年10月20日に確認しました。これらの鍵を持つ人は誰でも、自分が所有していないサイト向けに、ブラウザーが信頼するHTTPS証明書を発行できます。ブラウザーは数時間以内にこれらの証明書をブロックしましたが、ブラウザー以外の多くのアプリは、更新されるまで危険にさらされたままです。

eMudhraの鍵に何が起きたのか

認証局（CA）は、Webサイトの証明書に署名することで、そのサイトを保証します。大手のCAは、ルートと各Webサイトの間にある「中間」証明書を使って署名します。中間証明書の秘密鍵が漏れると、攻撃者はどのドメインについても、正当に見える証明書を作れてしまいます。

ある研究者が10月17日（土）に、この8つの鍵をブラウザーメーカーに報告しました。研究者は、それぞれの鍵でメッセージに署名して、そのことを証明しました。メッセージは「We have a problem here - Wayne.」（ここに問題があります - Wayne）です。The Hacker Newsによると、中間証明書のうち6件はWebサイト用（TLS）の証明書を発行し、2件はソフトウェアのコードに署名するものです。

セキュリティ研究者のScott Helme氏によると、鍵は弱いものでもありました。どの鍵もごく小さな数で、同氏は関連する証明書16件すべての秘密鍵を1秒もかからずに復元しました。中間証明書は2025年4月のものなので、約17か月間、誰でも同じことができる状態でした。Helme氏はeMudhraの説明を引用しています。スクリプトのバグで2つ目の弱い鍵ペアが作られ、名前が似ていたためにスタッフが誤ったほうを選んだというものです。

The Hacker Newsは、鍵がどのようにeMudhraの外に出たのか、ほかに誰が持っているのかは不明だとしています。Helme氏の分析は、これまでに誰かが鍵を復元していたかどうかを知る方法はないと付け加えています。

eMudhraは10月22日、世界のSSL/TLS証明書事業そのものから撤退すると発表しました。詳しくはeMudhra、弱い鍵の問題を受けて世界のSSL/TLS証明書事業から撤退をご覧ください。

各社の対応の速さ

日時（UTC）	対応
10月17日 18:05	Chromeのルートプログラムが報告を受け取る
10月17日 19:45	Chromeが、失効リストのCRLSetで6件のTLS中間証明書をブロック
10月17日 20:06	Mozillaが報告を受け取る
10月17日 22:59	FirefoxのOneCRLによるブロックが、標準設定のユーザーに届く
10月19日	Appleが証明書をブロック
10月20日	Microsoftがブロック。Go、Firefox、NSSのリリースが公開

Mozillaによると、Firefoxではこのブロックのための更新や再起動は不要でした。Mozillaは、独自の設定でOneCRLの更新が止まっているユーザー向けに、Firefox 158.0.1、ESR 115.43.1、ESR 153.5.1も公開しました。Mozillaのセキュリティライブラリ、NSSの3.131.1は、中間証明書に署名したルート「emSign ECC Root CA - G3」を削除します。Chromeも、Chrome Root Storeのバージョン43で同じルートを外す予定です。

Chromeは、コード署名用の中間証明書2件はブロックしませんでした。Chromeによるサイトの検証が、これらを通ることはないためです。Chromeはまた、ストア内のほかのすべてのCAを確認し、「この障害パターンのほかの事例は見つからなかった」と述べました。The Hacker Newsによると、Chromeがブロックする前に、6件のTLS中間証明書につながる、ログに記録されたWebサイト証明書はありませんでした。

ブラウザー以外のアプリにまだリスクがある理由

ブラウザーはブロックリストを自動的に受け取ります。ほかの多くのソフトウェアは、失効をまったく確認しません。誰かが新しいリストを配布するまで、同梱されたCAのリストを信頼し続けます。

Helme氏は、api.stripe.comの偽造証明書でこれを試しました。初期設定のままでは、LinuxとmacOSで、curl、Python、Nodeがこの証明書を受け入れました。Windowsでは、失効の確認を有効にしない限り、システムの暗号ライブラリが受け入れました。

Cyber Kendraの説明によると、同じ理由でGoにはコードの変更が必要でした。Goの証明書チェッカーはブラウザーのブロックリストを読まないため、Goのプログラムは再ビルドされるまでこれらの鍵を信頼します。各報道で挙げられている修正版は次のとおりです。

ソフトウェア	修正版
Go	1.27.3と1.26.10（CVE-2026-111943）。1.25以前はサポート終了
Firefox	158.0.1、ESR 115.43.1、ESR 153.5.1
NSS	3.131.1
Python certifi	2026.10.19
Rust webpki-roots	1.0.10
Electron	44.9.1、43.8.1、42.11.16

開発者にとっての意味

ブラウザーは対応済みです。サーバー、ビルドツール、コンテナーは、更新するまでおそらく対応できていません。

• Goのサービスを再ビルドしてください。 Goのバイナリは、証明書の検証を内部に持っています。Go 1.27.3または1.26.10で再ビルドして、デプロイし直してください。マシンのCAリストを更新するだけでは役に立ちません。
• 同梱のCAリストを更新してください。 Pythonプロジェクトではcertifiを、Rustではwebpki-rootsを、デスクトップアプリではElectronを更新してください。コンテナーイメージも再ビルドして、新しいシステムのバンドルを取り込んでください。10月21日のPythonリリースは新規インストール向けにこの修正を同梱しています。詳しくはPython 3.15.1、3.14.9、3.13.17がpip 26.2.2を同梱をご覧ください。
• 自社の証明書チェーンを調べてください。 ベンダーや社内のサービスがeMudhraの証明書を使っている場合は、ルートが消える前に把握してください。証明書を証明書デコーダーに貼り付けて、発行者（issuer）の欄を読んでください。
• できるところでは失効の確認を有効にしてください。 Helme氏のWindowsでのテストでは、失効の確認を有効にしたときだけ、偽造証明書が検出されました。この設定は、おまけではなく、TLS設定の一部として扱ってください。