2026年10月20日（米国時間）、Firefoxを開発するMozillaが、インドの認証局（＝Webサイトが本物であることを証明する電子証明書を発行する機関）eMudhraの「中間証明書」8件について、署名に使う秘密鍵を第三者でも簡単に復元できる状態だったと公表しました。悪用されると、どのWebサイトにもなりすませるおそれがある、深刻な問題です。
「Chromeもスマホも最新にしているから、うちは関係ないよね？自社のシステムで何か確認したほうがいいの？」
先に結論をお伝えします。最新のブラウザ（Chrome・Firefox・Safari・Edge）は、すでに対応済みです。注意が必要なのは、ブラウザ以外で動いているプログラム、つまり自社システムがサーバーの裏側で外部のサービスと通信する部分です。サーバーのOS・Node.js・Pythonなどの更新と、コンテナ（Docker）の作り直しが済んでいるかを、開発会社に確認しましょう。
この記事では、何が起きたのかを用語の解説つきで整理し、発注者が開発会社に確認したいことを、チェックリストと質問例つきで解説します（内容は2026年10月22日時点の情報に基づきます）。
何が起きたのか：公式発表と経緯
まず、Mozillaが公開している経緯（Mozillaの不具合管理システムBugzillaの記録）と、Mozillaの担当者が作成した解説ページから、事実関係を整理します。
📰 出典：Mozilla Bugzilla「Bug 2083449」（eMudhra中間証明書の鍵の危殆化）
📰 出典：「eMudhra Intermediate CA Compromise」（MozillaのDennis Jackson氏による解説・確認ページ、2026年10月20日）
| 日時（日本時間） | 出来事 |
|---|---|
| 10月18日 3時ごろ | 研究者が、eMudhraの中間証明書8件の秘密鍵を復元できたことを、Apple・Google・Microsoft・Mozilla・eMudhraに報告 |
| 10月18日 8時ごろ | Mozillaが、Firefoxで8件の証明書を遮断。Chromeも、ほぼ同じ時期に遮断を始めた |
| 10月18日 18時ごろ | eMudhraが8件の証明書を失効（＝無効化） |
| 10月19日 | Appleの製品で遮断。8件の一部に「相互署名」していたSectigoも、その証明書を失効 |
| 10月20日 | Microsoftの製品で遮断。複数の人が独自に鍵を復元したことを受け、MozillaとGoogleは上位のルート証明書「emSign ECC Root CA – G3」の信頼を緊急に取り消すと決定 |
| 10月21日 未明 | eMudhraが、同じルート証明書の配下での証明書の発行を停止 |
原因は、証明書の鍵の作り方の誤りでした。Mozillaによると、8件の鍵は2025年4月30日の作業でまとめて作られたもので、本来は推測できない大きな数でなければならない秘密鍵が、極端に小さな数になっていました。eMudhraは、影響はこの作業で作った特定の中間証明書に限られ、ルート証明書の鍵やほかの中間証明書には影響しないと説明しています。また、対象の中間証明書から、Webサイト向けなどの証明書は1件も発行していないとしています。
そもそも「認証局」「中間証明書」とは
ブラウザの鍵マーク（HTTPS）は、通信相手のWebサイトが本物であることを、電子証明書で確かめた印です。
| 用語 | 意味 |
|---|---|
| 認証局（CA） | Webサイトなどに電子証明書を発行する機関。eMudhraもその1つ |
| ルート証明書 | ブラウザやOSにあらかじめ組み込まれた、信頼の出発点になる証明書 |
| 中間証明書 | ルート証明書の下で、実際にWebサイト向けの証明書に署名する証明書 |
| 秘密鍵 | 証明書に署名するための鍵。いわば認証局の「実印」 |
中間証明書の秘密鍵が第三者の手に渡ると、その人は、どのドメインに対しても「本物」として通る偽の証明書を作れてしまいます。偽の証明書を使えば、通信の途中に割り込んで、中身を盗み見たり書き換えたりできるおそれがあります。
ブラウザは対応済み。心配なのは「ブラウザ以外」の通信
最新のブラウザは保護されている
Mozilla・Google・Apple・Microsoftは、すでにそれぞれの仕組みで8件の証明書を遮断しています。さらに、主要なブラウザは「Certificate Transparency（CT）」という、発行された証明書をすべて公開記録に残す仕組みを必須にしています。Mozillaの解説ページによると、問題の中間証明書から発行された証明書はこの記録に1件もなく、CTを必須にしているFirefox・Chrome・Edge・Safariが攻撃された可能性はないとしています。
Cloudflareも、自社のサービスで悪用は確認していないとしています。執筆時点で、実際に悪用されたという報告はありません。
📰 出典：Cloudflare「8 eMudhra certificates are compromised. Here’s what you need to know」
サーバーの裏側で動くプログラムは、更新が必要
一方、ブラウザ以外のプログラムは事情が違います。Mozillaの解説ページは、多くのプログラムが失効の情報を確認せず、CTも確認しないため、ソフトウェアの更新が必要だと説明しています。また、CTを確認しないプログラムに対して、この欠陥が悪用されたかどうかは分からないとしています。
発注者の目線で言い換えると、次のような「人が画面を見ていない通信」が対象になります。
| 自社システムの中の例 | 何が心配か |
|---|---|
| 決済・地図・メール配信など、外部サービスのAPIを呼び出す処理 | 偽の相手につながり、送ったデータを盗まれたり、返ってくるデータを書き換えられたりするおそれ |
| 定期実行のプログラム（データ連携・バッチ処理など） | 同上 |
| 開発・公開の自動化（CI/CD）や、部品のダウンロード | 偽の部品やプログラムを取り込んでしまうおそれ |
| スマホアプリやIoT機器が、自社のサーバーと通信する部分 | アプリや機器の作りによっては、更新が必要 |
セキュリティ研究者のスコット・ヘルム氏は、curl、Python、Node.js、Go、Java、パッケージマネージャー（部品を取り込む道具）など、ブラウザ以外の多くのプログラムが、標準の設定ではディスク上の証明書の一覧だけを信頼すると指摘しています（報道・専門家の見解）。
📰 出典：Scott Helme「Eight bits of trust: eMudhra’s CA keys cracked in milliseconds」
📰 出典：ITmedia NEWS「認証局eMudhraの中間証明書、秘密鍵が「数ミリ秒」で復元可能な脆弱性 大手各社が緊急遮断」（2026年10月21日）
主な対策済みのバージョン
Mozillaの解説ページでは、対策済みのソフトウェアの一覧が公開されています。発注者が開発会社と話すときに出てきそうなものを抜き出しました（執筆時点）。
| ソフトウェア | 対策済みのバージョン |
|---|---|
| Ubuntu・Debian・Fedora・Alpine Linux などの証明書パッケージ（ca-certificates） | 各ディストリビューションが更新版を公開済み |
| Node.js | 22.23.4／24.22.1／26.12.1 |
| Python の certifi・pip | certifi 2026.10.19／pip 26.2.2 |
| Go | 1.27.3／1.26.10 |
| PHP の Composer（ca-bundle） | 1.4.16／1.6.0 |
| curl の証明書一覧 | 2026-10-20版 |
| Java | 執筆時点では対応待ち |
Node.jsは、10月21日のセキュリティ修正版にこの対応も含めています。Node.jsの修正版については、次の記事で解説しています。
Windowsのソフトの「電子署名」にも関係する
8件のうち2件は、Webサイト用ではなく、Windowsのソフトウェアに付ける電子署名（コード署名）用の証明書でした。この鍵を悪用すると、不正なプログラムを「正規の会社が作ったソフト」に見せかけられるおそれがあります。社内で配布しているWindowsのソフトや、取引先から受け取るソフトがある場合は、Windowsの更新を最新にしておきましょう。
発注者にとって何が変わるか／変わらないか
ここからは、公表された情報をもとにした筆者の見解です。
変わらないこと：サイトの見た目や、自社サイトの証明書は基本的にそのまま
自社のWebサイトにeMudhra以外の認証局の証明書を使っているなら、今回の件でサイトの証明書を取り替える必要はありません。また、最新のブラウザで自社サイトを見る分には、利用者の側で特別な対応は必要ありません。
変わること1：サーバー側の「証明書の一覧」の更新と、コンテナの作り直しが必要
自社システムがサーバーの裏側で外部と通信しているなら、サーバーのOS、Node.jsやPythonなどの実行環境、使っている部品を更新する必要があります。Cloudflareは、更新したあとにプログラムの再読み込み・再起動・コンテナの作り直しが必要かどうかも確認するよう呼びかけています。Dockerなどのコンテナで動かしている場合は、土台のイメージを更新して作り直さないと、古い証明書の一覧のまま動き続けます。
誰がこの作業をするかは、保守契約の内容によって変わります。役割分担の考え方は、次の記事も参考にしてください。
変わること2：更新後のエラーを「確認をやめて」回避しない
更新したあと、外部との通信で証明書のエラーが出る場合があります。Cloudflareは、このエラーを証明書の確認を無効にする方法で回避しないよう呼びかけています。確認をやめてしまうと、今回守りたかった「相手が本物かどうかの確認」そのものがなくなるためです。開発会社から「エラーが出たので確認を外しました」という報告があったら、理由と元に戻す予定を確認しましょう。
「ブラウザが大丈夫でも、サーバーの裏側の通信は別です。『外部サービスとつながっている処理はどこか』を一覧にしてもらうと、確認の漏れが減ります。」
今やるべきこと・まだ様子見でいいこと
| 区分 | 内容 |
|---|---|
| 今やること | 社内のパソコン・スマホのOSとブラウザを最新にする |
| 今やること | 自社システムの中で、外部のサービスやAPIと通信している処理がどこにあるか、開発会社に確認する |
| 今やること | サーバーのOS・実行環境（Node.js・Python・Go・PHPのComposerなど）の証明書の一覧が更新済みか、開発会社に確認する |
| 今やること | コンテナで動かしている場合は、イメージを作り直して入れ替えたか確認する |
| 早めに | 更新後に証明書のエラーを、確認の無効化で回避していないか確認する |
| 対応待ち | Javaなど、まだ対策版が出ていないものは、公開されたら更新する |
| 様子見でよい | 自社サイトの証明書の取り替え（eMudhraの証明書を使っていなければ不要） |
発注者がやること チェックリスト
- ☐ 社内のパソコン・スマホのOSとブラウザを最新にした
- ☐ 自社システムで、外部のサービスやAPIと通信している処理を把握した
- ☐ サーバーのOSと実行環境（Node.js・Pythonなど）の更新が済んでいるか確認した
- ☐ コンテナで動かしている場合、イメージを作り直して入れ替えたか確認した
- ☐ 自社サイトや社内システムで、eMudhraの証明書を使っていないか確認した
- ☐ 更新後に、証明書の確認を無効にしてエラーを回避していないか確認した
- ☐ 社内で配布・利用しているWindowsのソフトについて、Windowsの更新を最新にした
開発会社への質問例
- 「eMudhraの中間証明書の件は、当社のシステムに関係しますか？外部のサービスやAPIと通信している処理はどこにありますか？」
- 「サーバーのOSやNode.js・Pythonなどの実行環境は、今回の対策済みのバージョンに更新されていますか？」
- 「コンテナで動いている部分は、イメージを作り直して入れ替える必要がありますか？いつ対応できますか？」
- 「更新後に証明書のエラーが出た場合、確認を無効にせずにどう対応しますか？」
- 「今回の対応は、保守契約の範囲で対応してもらえますか？」
まとめ
認証局eMudhraの中間証明書8件で、秘密鍵を誰でも簡単に復元できる状態だったことが分かり、主要なブラウザやOSはすでに該当の証明書を遮断しました。執筆時点で、実際に悪用されたという報告はありません。
ただし、ブラウザ以外のプログラム、つまり自社システムがサーバーの裏側で外部と通信する部分は、OSや実行環境の更新、コンテナの作り直しをしないと守られないことがあります。発注者がやるべきことは、外部と通信している処理がどこにあり、その更新が済んでいるかを開発会社に確認することです。更新後のエラーを、証明書の確認をやめる方法で回避していないかもあわせて確認しましょう。
あわせて読みたい関連記事
