【eMudhra】中間CAの秘密鍵が誰でも計算できた事件、どれくらいクリティカル？ 開発者がやるべきこと

2026年10月20日（協定世界時、以下UTC）、インドの認証局（CA）eMudhra（イームドラ）が運用する中間CA証明書8枚について、その秘密鍵を誰でも計算できる状態だったことが公表されました。Mozillaの暗号エンジニアであるDennis Jackson氏は、この件の影響について「これ以上高くなりようがない」という趣旨の警告を出しています。

驚くべきはその中身です。本来は100桁を超える巨大な乱数であるはずの秘密鍵が、8本とも256未満の整数でした。そのうち1本は、文字どおり「4」だったと報告されています。ハッキングされて盗まれたのではなく、最初から「誰でも当てられる鍵」だったわけです。

先日取り上げたPHPの重大脆弱性「php2shell」に続き、またしても「クリティカル」と騒がれている今回の件。結局どれくらい危ないのか、自社では何をすればいいのかを、身近なたとえとphp2shellとの比較を交えて整理します。

結論：理論上は最大級、でも「ブラウザの外」が本番

最初に結論をまとめておきます。

• 理論上の深刻度は最大級：鍵があれば、Google、銀行、自社サイトを含むあらゆるドメインの「本物の証明書」を作れてしまう状態でした。
• ブラウザ利用者はほぼ守られている：ChromeとFirefoxは報告から数時間以内に遮断済みで、利用者側の操作は基本的に不要です。悪用された証拠も今のところ見つかっていません。
• 本当に危ないのはブラウザ以外：Goで作ったプログラム、Pythonのライブラリ、コンテナ、古いサーバーやIoT機器など、独自の「信頼リスト」を持つソフトは、更新するまで偽の証明書を信じ続ける可能性があります。
• 巻き添えにも注意：ChromeはeMudhraのルート証明書そのものの信頼を10月27日朝（米国太平洋時間、日本時間28日未明）に取り消します。このルートの下で正規に発行された証明書を使っているサイトは、Chromeでエラーになります。

つまり「一般ユーザーが今すぐ慌てる話」ではありませんが、開発者・インフラ担当者にとっては、放っておくと静かに穴が残り続けるタイプのインシデントです。

まずは仕組みを「たとえ」で理解する

証明書や認証局の話は、専門用語が多くてとっつきにくいですよね。ここでは「身分証明書と、それを確認する受付」にたとえて、ひとつずつ見ていきます。

たとえ1：証明書は「Webサイトの身分証」

あなたが銀行のサイトを開くとき、ブラウザは裏側で「この相手は本当に銀行？　なりすましじゃない？」を確認しています。そのときにサイトが見せてくるのがSSL/TLS証明書、いわばWebサイトの運転免許証です。

運転免許証が信用できるのは、「ちゃんとした役所が発行して、公印（ハンコ）を押している」からですよね。Webの世界でこの「役所」にあたるのが認証局（CA）です。

警備員（ブラウザ）は、免許証（証明書）に押されたハンコが「リストに載っている役所の窓口のものか」を確かめて、本物と判断します。今回問題になったのは、この「窓口のハンコ」です。

たとえ2：ハンコが「消しゴムで彫れる1文字」だった

本物の公印は、複雑な彫刻が施されていて、まず真似できません。デジタルの世界でいえば、秘密鍵は100桁以上のでたらめな数字で、世界中のコンピューターを総動員しても当てられないように作られます。

ところがeMudhraの8つの窓口のハンコは、彫られていたのが「4」や「56」といった数字1文字だけでした。候補はたった255通り。消しゴムで1つずつ彫って押し比べれば、すぐに同じハンコが作れてしまいます。実際、研究者のScott Helme氏はノートPCで8本すべての鍵を1秒もかからずに割り出したと報告しています。

もう少し正確に言うと、鍵の長さ（48バイト）のうち、最後の1バイト以外がすべてゼロだったとMozillaの調査で確認されています。暗証番号に置き換えるなら、「116桁のダイヤル錠なのに、最後の1桁しか回していなかった」ような状態です。

たとえ3：「盗まれた」のではなく「最初から玄関に貼ってあった」

ふつうの「鍵の漏えい事件」は、泥棒が合鍵を盗んでいく話です。盗まれた日時や犯人の見当がつくので、「いつから危なかったか」を考えることができます。

今回は違います。ハンコの形は、毎日みんなに見せている免許証（公開されている証明書）から逆算できました。鍵の形が玄関先に貼り出されていたようなもので、2025年4月に作られた日から、気づいた人なら誰でも複製できたことになります。発見までの約17か月間に誰かがこっそり使っていたかどうかは、完全にはわからないのが怖いところです。

たとえ4：偽の免許証で何ができるのか

このハンコがあれば、「〇〇銀行」名義でも「Google」名義でも、警備員が本物と信じてしまう免許証を好きなだけ作れます。ただし、偽の免許証を持っているだけでは悪さはできません。あなたが銀行に向かう途中の道で、本物の銀行員になりすまして待ち構える必要があります。

Webでいうと、公衆Wi-Fiを乗っ取る、DNSを書き換えるなどして通信の途中に割り込む（中間者攻撃）ことが前提になります。そこまで条件がそろうと、パスワードやカード番号を盗み見たり、通信内容を書き換えたりできてしまいます。

さらに8本のうち2本は、ソフトウェアに押す「コード署名」用のハンコでした。こちらは「このアプリは正規の開発元が作りました」という証明に使うもので、悪用されればマルウェアに正規っぽい署名を付けられるおそれがありました。

たとえ5：ブラウザは「スマホで手配書が届く警備員」、ほかのアプリは「紙の手配書の警備員」

問題が発覚したら、「この窓口のハンコが押された免許証は信用するな」という手配書を警備員に配る必要があります。ここで、警備員によって大きな差が出ます。

• ChromeやFirefox：本部からスマホに最新の手配書が自動で届く警備員です（ChromeのCRLSet、FirefoxのOneCRLという仕組み）。今回も報告から数時間で全員に届き、アップデートも再起動も不要でした。
• Goのプログラム、Pythonのcertifi、コンテナ内のCA証明書など：印刷した手配書を持っている警備員です。誰かが新しい紙を手渡す（ライブラリやパッケージを更新する）まで、古いリストのまま本物扱いを続けます。
• Goでビルド済みのプログラム：Goの修正は、信用しない鍵のリストを標準ライブラリに直接書き込む方式です。いわば手配書を体に刻み込むようなもので、新しいGoでビルドし直さない限り反映されません。

たとえ6：「国ごと信用しない」ことで、正規の免許証まで使えなくなる

窓口のハンコだけでなく、その窓口を管轄する「国」（ルート証明書emSign ECC Root CA – G3）ごと信用リストから外す対応も進んでいます。Mozillaはすでに外し、Chromeも10月27日に外します。

これは安全のためには正しい判断ですが、副作用としてその国で正規に発行された、何も悪くない免許証まで使えなくなります。eMudhraは、差し替えが必要な顧客の証明書が約3万枚にのぼると見積もっています。該当する証明書を使っているサイトは、別の認証局で取り直す必要があります。

たとえ7：Chromeが守られたのは「台帳にない免許証は受け付けない」ルールのおかげ

Chromeなどには、「発行したら必ず公開の台帳に記録すること。台帳に載っていない免許証は受け付けない」というルールがあります。これがCertificate Transparency（CT、証明書の透明性ログ）です。

Googleによると、遮断前の時点で、問題の6つのTLS用窓口から発行された証明書は台帳に1枚も載っていませんでした。つまりChromeのような「台帳必須」の警備員は、偽の免許証を見せられても最初から通さなかったことになります。逆に言えば、台帳を確認しない警備員（多くのブラウザ以外のソフト）については、悪用がなかったと断言できる材料がありません。

何が起きたのか：発覚から事業撤退まで

経緯を時系列で整理します（括弧内は日本時間）。

• 2025年4月30日：鍵の生成　eMudhraが24個の中間CAの鍵を作る「キーセレモニー」を実施。このうち8個が弱い鍵でした。5月には認証局Sectigoが8個すべてにクロス署名しています。
• 2026年10月17日 18:05 UTC（18日 3:05）：Chromeに報告　研究者「Wayne」氏が、CAの共通データベース（CCADB）を調べる中で問題を発見。証拠として8本の鍵それぞれで「We have a problem here – Wayne」というメッセージに署名し、Apple、Google、Microsoft、Mozilla、eMudhraに送りました。Chromeは19:45 UTC（18日 4:45）までに遮断を配信。
• 10月17日 20:06 UTC（18日 5:06）：Mozillaに報告　Mozillaは2時間以内に独自に鍵を復元して問題を確認し、22:59 UTC（18日 7:59）にFirefoxへ遮断を配信しました。
• 10月18日：eMudhraが失効　eMudhraは発見から約14時間で8枚を失効させたとしています。
• 10月19日：Apple、Androidが遮断　AndroidはGoogle Play開発者サービス経由で約22:00 UTCに遮断。Cloudflareもこの日に把握し、自社サービスの修正を開始しました。
• 10月20日：公表と一斉修正　MozillaのJackson氏が公表。Microsoftが遮断し、Go、Firefox、NSS（Mozillaの暗号ライブラリ）、Ubuntu、Debianなどが修正版を公開。Mozillaはルート証明書の信頼も取り消しました。
• 10月21日：各国・各社の対応　Node.jsが修正版を公開。Red Hatが重要度「Important」の告知、インドのCERT-Inが勧告を出し、インド電子情報技術省（MeitY）が調査チームを設置。eMudhraの株価はムンバイ市場で20%下落しました。
• 10月22日：グローバルSSL/TLS事業から撤退を発表　eMudhraは、この事業の売上は全体の約1%にすぎないと説明しています。
• 10月27日朝 PDT（28日未明）：Chromeがルート証明書を削除予定　emSign ECC Root CA – G3の下の証明書はChromeで信頼されなくなります。

原因についてeMudhraは、鍵を安全に持ち運ぶための「包む・ほどく」処理（key wrap／unwrap）の過程で、本来の強い鍵とは別に弱い鍵のセットができてしまい、ラベル名が似ていたため担当者が弱いほうを選んでしまったと説明しています。複数の段階で人為的なミスがあったことも認めていますが、根本原因はまだ調査中としています。

インシデントの概要

php2shellと比べると、どっちがヤバい？

同じ週に話題になったphp2shell（PHP本体の認証不要RCE）と並べると、今回の件の「ヤバさの種類」がよく見えてきます。

ざっくり言えば、php2shellは「自分の家の鍵が壊れた」話、eMudhraは「町じゅうの身分証制度に穴が開いた」話です。

理論上のスケールでは、eMudhraのほうが上です。どの会社のどのサイトでも偽装できるという意味で、影響範囲に「自社は関係ない」という線引きがありません。一方で、攻撃するには通信経路に割り込むという追加のハードルがあり、しかも主要ブラウザは報告から数時間で守られました。PHPサーバーを公開している企業にとって、「今夜中に手を動かさないと乗っ取られる」という切迫感はphp2shellのほうが上だったと言えます。

ただし、eMudhraの件には別の厄介さがあります。php2shellは「PHPを更新すれば終わり」というゴールが明確でしたが、今回は証明書を確認するソフトの数だけ直す場所があるうえ、直していないソフトがあっても普段は何も起きないので気づけません。「すぐ燃えるphp2shell」に対して「くすぶり続けるeMudhra」というのが、両者のいちばん大きな違いです。

主な修正の状況

ブラウザ以外の主なソフトの対応状況です。修正の方式は「8本の鍵を名指しで拒否する」ものと「ルート証明書ごと外す」ものの2通りがあります。

このほか、Fedora、Arch、Alpineなどのca-certificates、curlのCAバンドル、pip、uv、Electronなども対応が進んでいます。最新の一覧は、MozillaのJackson氏が公開している特設サイトで確認できます。なお、macOSに標準で入っているcurlは更新されていないCAファイルを参照するため、執筆時点でも問題のチェーンを受け入れてしまうと指摘されています。

対応指針：立場別にやること

1. 一般の利用者・社内PC

• ブラウザとOSを最新に保つ。ChromeとFirefoxは通常の設定なら自動で守られていますが、Firefoxのリモート設定（Remote Settings）をポリシーで止めている企業では、158.0.1以降への更新が必要です。
• Androidは再起動しておくと確実です。
• 手元の環境が問題のチェーンを拒否するかは、Jackson氏のテストサイトで確認できます。ただし結果は「そのブラウザ」についてのもので、ほかのアプリが安全という意味ではありません。

2. 開発者・インフラ担当者（ここが本番）

1. Goのプログラムを洗い出し、1.27.3／1.26.10以降で再ビルド・再デプロイ：開発機のGoを更新しただけでは、ビルド済みのバイナリは直りません。サードパーティ製のツール（Goで書かれたCLIやエージェントなど）も、提供元の更新版に入れ替える必要があります。
2. OSのca-certificatesを更新：Ubuntu、Debianは修正済み。RHEL系は公式パッケージの提供状況を確認し、まだなら回避策を検討します。
3. 言語ごとのCAバンドルを更新：Pythonのcertifi、Node.js本体、PHPのComposer ca-bundle、Rustのwebpki-rootsなど。間接的な依存として入っていることも多いので、依存ツリーまで確認します。
4. コンテナイメージを作り直す：ベースイメージに古いCA証明書が焼き込まれています。更新されたベースイメージで再ビルドし、再デプロイします。
5. 証明書エラーが出ても「検証オフ」で逃げない：更新後に接続エラーが出た場合、相手先が問題のルートの証明書を使っている可能性があります。Cloudflareも強調しているとおり、verify=False のように証明書検証を無効にして回避するのは厳禁です。

サーバーや開発環境の状態は、たとえば次のように確認できます。

# Debian / Ubuntu：システムの信頼ストアにemSignのルートが残っていないか
# （emSign Root CA - G1 は今回の削除対象ではないため、表示されても問題ありません）
ls /etc/ssl/certs | grep -i emsign

# RHEL / Fedora 系
trust list | grep -i -A2 emsign

# Python：certifi のバージョン（2026.10.19 以降が目安）
python3 -c "import certifi; print(certifi.__version__)"

# Node.js：26.12.1 / 24.22.1 / 22.23.4 以降が目安
node -v

# Go：ビルド済みバイナリがどのGoでビルドされたか
go version ./your-binary

3. Webサイト・APIの運営者

自社サイトがeMudhra（emSign）の証明書を使っていないかを確認します。日本の企業で使われている例は多くないと思われますが、海外子会社や取引先経由で導入されているケースもあるので、念のためチェックしておきましょう。

# サイトが返す証明書チェーンの発行者を確認（example.com を自社ドメインに置き換え）
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' s:| i:'

• emSign ECC Root CA – G3につながる証明書：最優先です。Chromeでの信頼取り消し（日本時間28日未明）より前に、Chromeのルートストアに含まれる別の認証局で取り直して差し替えてください。Firefoxではすでにエラーになっている可能性があります。
• emSign Root CA – G1（RSA系）につながる証明書：今回は削除対象ではありませんが、Chromeはこのルートの扱いも見直し中で、eMudhra自身がTLS事業から撤退します。計画的に別の認証局へ移行しましょう。
• Cloudflareなどを経由している場合：オリジンサーバーの証明書や、相互TLS（mTLS）で使うCA設定に該当するものがないかも確認します。

4. 見落としがちな場所

• 長期間更新していないアプライアンス製品、IoT機器、組み込み機器
• 独自のCAバンドルを同梱している業務アプリやモバイルアプリ
• CI/CDのランナー、社内の開発ツール、バッチサーバー
• サポートが切れた古いOSや言語ランタイム

こうした場所は、更新が自動で届かない「紙の手配書の警備員」の代表格です。すぐに直せないものは、信頼できないネットワークから切り離す、外部通信先を限定するといった形でリスクを下げておきましょう。

この事件が突きつけた3つの教訓

1つ目は、「暗号が強くても、運用が弱ければ意味がない」ということです。P-384という暗号方式自体は今も安全です。壊れたのは、鍵を作る手順とその確認体制でした。ハードウェアセキュリティモジュール（HSM）や監査をそろえていても、最後に「どの鍵を使うか」を人が取り違えれば台無しになります。

2つ目は、「信頼リストの更新の速さには大きな差がある」ことです。ブラウザはスイッチひとつで全利用者を守れましたが、それ以外のソフトは一つひとつ更新が必要でした。Cloudflareは、信頼ストアは「固定の名簿」ではなく、失効情報などを素早く反映できる仕組みであるべきだと指摘しています。

3つ目は、Certificate Transparencyのような「公開の台帳」が、実際に被害を防いだことです。誰が何を発行したかを全員で監視できる仕組みがあったからこそ、Chromeは「偽の証明書は通らなかった」と言い切れました。地味な仕組みですが、今回の最大の功労者のひとつと言えるでしょう。

まとめ

eMudhraの件は、「認証局のハンコが消しゴムで彫れる1文字だった」という、にわかには信じがたいインシデントです。理論上はインターネット上のどのサイトにもなりすませる状態で、深刻度としては最大級。ただし主要ブラウザは数時間で守られ、悪用の証拠も見つかっていないため、一般の利用者が慌てる必要はありません。

php2shellが「今夜パッチを当てないと燃える」タイプだったのに対し、今回は「ブラウザの外に、気づかれないまま穴が残る」タイプです。開発・インフラ担当者は、Goの再ビルド、OSと言語ごとのCAバンドル更新、コンテナの作り直しを進めてください。そしてサイト運営者は、emSignの証明書を使っていないかを、Chromeのルート削除（日本時間28日未明）より前に必ず確認しておきましょう。

本記事は、Mozilla、Google、Cloudflareの公式発表、eMudhraの声明、各セキュリティメディアの報道（2026年10月26日・日本時間時点の情報）をもとに整理したものです。原因についてはeMudhraが調査中としており、各ソフトウェアの修正状況（特にRed Hat Enterprise Linuxのパッケージ提供）やChromeのルート削除の時期は今後更新される可能性があります。実際の対応にあたっては、各ベンダーの最新情報をご確認ください。たとえ話は理解を助けるための簡略化であり、技術的な細部は参考情報の一次資料をご参照ください。

参考情報

• eMudhra Intermediate CA Compromise（Dennis Jackson氏による特設サイト・テストページ）
• Bug 2083449 – eMudhra: Private key compromise of Intermediate Certificates（Mozilla Bugzilla）
• Protecting Firefox users following the compromise of eMudhra intermediate certificates（Mozilla Security Blog）
• Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates（Google）
• 8 eMudhra certificates are compromised. Here’s what you need to know（Cloudflare Blog）
• Eight bits of trust: eMudhra’s CA keys cracked in milliseconds（Scott Helme）
• Certificate Security Incident（eMudhra）
• eMudhra to exit global SSL/TLS certificate business（eMudhra）
• Go 1.27.3 and Go 1.26.10 security release（golang-announce）
• RHSB-2026-012（Red Hat Security Bulletin）
• USN-8944-1: ca-certificates update（Ubuntu）
• CIAD-2026-0050（CERT-In）
• Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software（The Hacker News）
• eMudhra security blunder left trusted CA signing keys exposed to anyone（Help Net Security）
• How to Identify Compromised eMudhra Certificates（Qualys）
• CVE-2026-111943: eMudhra CA Key Compromise（SOC Prime）