- インドの認証局（証明書を発行する会社）eMudhraの中間証明書8枚の秘密鍵が、第三者に求められる状態だったことが分かりました。鍵の作り方に誤りがありました［Mozilla Bugzilla、eMudhra］。
- ChromeとFirefoxは日本時間10月18日の早朝までに、この8枚を遮断しました［Google、Mozilla］。最新のブラウザを使っていれば、ほぼ心配はありません。
- 注意が必要なのは、ブラウザ以外です。社内サーバーから外部APIを呼ぶ処理、Javaのアプリ、コンテナ、古いOSや組み込み機器は、信頼する証明書の一覧（CA証明書）を更新するまで、偽の証明書を見抜けないおそれがあります。
- 自社サイトの証明書がeMudhra以外の会社のものなら、サイト自体の作り直しは要りません。同じ週に話題になったPHPの脆弱性php2shellとは別の問題です。
お使いのブラウザを今すぐチェック：eMudhra中間証明書チェック（日本語版）で、問題の証明書を信用していないかを確かめられます。
何が起きたのか
eMudhra（イーマドラ）は、インドの認証局です。認証局は、Webサイトの「身分証」にあたるSSL/TLS証明書を発行する会社です。
2026年10月17日（協定世界時、UTC）、ある研究者が「eMudhraの中間証明書8枚の秘密鍵を手に入れた」と、Google・Mozilla・Apple・Microsoftの各ルートプログラム（ブラウザやOSが信頼する認証局を管理する窓口）とeMudhraに報告しました。報告には、その鍵で実際に署名したデータが添えられていました［Mozilla Bugzilla 2083449］。
Mozillaは報告を受けて、別の手段で同じ鍵を求められることを確かめています。Mozillaは「鍵の生成の手順に欠陥があり、悪用はたやすい」と書いています［Mozilla Bugzilla 2083449］。Googleも「鍵が十分なランダムさなしで作られていた」と説明しています［Google Security Blog］。
eMudhraによると、8枚は2025年4月30日の鍵生成の作業で作られました。作業の途中の手順で弱い鍵が別に作られ、誤ってその鍵で証明書を作ってしまったと説明しています。原因の詳細は調査中です［eMudhra、Mozilla Bugzilla 2083449］。
8枚の内訳は、Webサイト用（TLS）が6枚、ソフトウェアの署名用（コード署名）が2枚です。コード署名用の2枚は、Microsoftの環境で信頼されていました［Mozilla Bugzilla 2083449］。どの8枚も、英国Sectigoの古いルート証明書（AAA Certificate Services）からの「相互署名（別の発行元からのお墨付き）」も受けていました［Mozilla Bugzilla 2083449］。
中間証明書とは（たとえ話）
サイトの証明書は、次の3段の仕組みで成り立っています。
- ルート証明書：大元の発行元です。ブラウザやOSに、最初から「信頼する一覧」として入っています。
- 中間証明書：ルートからお墨付きをもらった「発行の窓口」です。実際にサイトの証明書を発行するのはこの窓口です。
- サーバー証明書：各サイトが受け取る身分証です。
秘密鍵は、窓口が身分証に押す「印鑑」にあたります。今回はこの印鑑が漏れたため、印鑑を持つ人はどのサイトの名前でも、本物と同じ印が押された身分証を作れる状態になりました。
偽の身分証を使うには、攻撃者が利用者とサイトの間の通信に割り込む必要があります。公衆Wi-Fiや乗っ取られたネットワーク機器などがその例です。割り込まれた側の端末が偽の証明書を信じてしまうと、パスワードやAPIのやり取りを盗み見られたり、書き換えられたりするおそれがあります。
時系列
時刻は出典の表記（UTC）に、日本時間（JST）を添えています。日本時間はUTCに9時間を足した時刻です。
| 日時 | 出来事 | 出典 |
|---|---|---|
| 2025年4月30日 | eMudhraの鍵生成の作業で、問題の8枚が作られる | eMudhra、Mozilla Bugzilla |
| 2026年10月17日 18:05 UTC （18日 3:05 JST） | 研究者がGoogleなどの各ルートプログラムとeMudhraに報告 | Google、Mozilla Bugzilla |
| 17日 19:45 UTC （18日 4:45 JST） | ChromeがCRLSet（Chromeが配る失効リスト）を更新し、TLS用6枚を遮断。ブラウザの更新や再起動は不要 | |
| 17日 22:59 UTC （18日 7:59 JST） | FirefoxがOneCRL（Firefoxが配る中間証明書の遮断リスト）で8枚を遮断 | Mozilla Bugzilla |
| 18日 9:24〜9:38 UTC （18日 18:24〜18:38 JST） | eMudhraが8枚を失効（理由は「認証局の鍵の危殆化」） | Mozilla Bugzilla（eMudhraの投稿） |
| 19日（UTC） | SectigoがAAA Certificate Servicesからの相互署名の8枚を失効 | Mozilla Bugzilla（Sectigoの投稿） |
| 19日 22:00 UTCごろ （20日 7:00 JST ごろ） | AndroidにもGoogle Playサービス経由で同じ遮断が配られる | |
| 20日 | Mozillaが、8枚の大元のルート証明書「emSign ECC Root CA - G3」の信頼を緊急で取り消すと発表。Firefox 158.0.1、ESR 153.5.1、ESR 115.43.1、NSS 3.131.1を公開。eMudhraはこのルートの下での発行を止めた | Mozilla Bugzilla、Mozilla Security Advisory |
| 20日 | Ubuntu、Go、curlの証明書バンドルなどが更新を公開 | 各公式 |
| 21日 | OpenJDK（Java）が勧告を公開。Red Hatが告知（RHSB-2026-012）を公開 | OpenJDK、Red Hat |
| 21日 19:55 JST | 確認方法を紹介したXの投稿が、国内で広く共有される | X |
| 27日（米国太平洋時間の朝） | Chromeのルート証明書の一覧から「emSign ECC Root CA - G3」が外れる予定 |
eMudhraの声明では、失効した日を「10月19日」としています。一方、Bugzillaに載ったeMudhraの表では、失効の時刻はUTCの18日です。この記事では、Bugzillaの時刻を使っています。
Appleは10月19日から、Microsoftは10月20日から8枚を遮断していると、報告者側の公開サイト（emudhra.we-have-a-problem.com）が書いています。AppleとMicrosoftの公式発表は、確認した時点では見つかっていません。
影響を受けるもの・受けないもの
最新のブラウザ：ほぼ心配はない
Googleは「遮断の前に、この6枚の下で発行された証明書は、証明書の公開記録（Certificate Transparency、CT）に1枚も載っていなかった」と書いています。ChromeはCTに載っていない証明書を受け付けません。そのため、CTを確かめるクライアントに対して、偽の証明書は使えなかったとしています［Google Security Blog］。報告者側の公開サイトも、Firefox・Chrome・Edge・Safariについて同じ見方をしています。
eMudhraは「8枚のうち本番で動いていたのは1枚だけで、その1枚もサーバー証明書を発行していない」と説明しています［eMudhra］。「弱い鍵が公表前に誰かに見つけられ、悪用された証拠は把握していない」とも書いています。
注意が必要なもの：ブラウザ以外
ブラウザ以外の多くのプログラムは、失効の情報（OneCRLやCRLSet）を受け取りません。CTも確かめません。報告者側の公開サイトは「CTを確かめないクライアントが、この欠陥を使って攻撃されたかどうかは分からない」と書いています。
次のようなものは、自分が持っている証明書の一覧を更新するまで、偽の証明書を信じてしまうおそれがあります。
- Linuxサーバーのca-certificates（OSが持つ証明書の一覧）を更新していない
- サーバーからcurl、PHP、Python、Node.js、Goなどで外部のAPIを呼んでいる
- Javaのアプリが、自前で同梱したJava実行環境を使っている
- Dockerなどのコンテナイメージを作り直していない
- 古いOS、複合機・ネットワーク機器・IoT機器などの組み込み機器
Windowsのコード署名では、2枚のコード署名用の中間証明書が関わります。Microsoftは自動更新で遮断を配っている、と報告者側の公開サイトが書いています。オフラインのPCや、自動更新を止めているPCは更新されていないおそれがあります。
ソフトウェア別の対応状況
2026年10月22日 朝の時点で、公式ページを開いて確かめたものです。「公開サイト」とある行は、報告者側の公開サイトの記載だけで、各社の公式発表は確認できていません。
| クライアント | 対応状況 | 出典 |
|---|---|---|
| Chrome | 10月17日にCRLSetでTLS用6枚を遮断（更新・再起動は不要）。10月27日（米国太平洋時間）にルート証明書を一覧から外す予定 | Google Security Blog |
| Android | Google Playサービス経由で遮断（10月19日 22:00 UTCごろ）。端末の再起動で早く反映できる | Google Security Blog |
| Firefox | 10月17日にOneCRLで遮断。10月20日にFirefox 158.0.1、ESR 153.5.1、ESR 115.43.1を公開。Android版は158.0.2で反映の不具合を修正 | Mozilla Security Advisory、Bugzilla |
| Apple（iPhone・Mac） | 10月19日から遮断。ただし、macOSに最初から入っているcurl・git・python3などは、更新されていない別の証明書ファイルを使う | 公開サイト |
| Microsoft（Windows） | 10月20日から、証明書の一覧の自動更新で遮断 | 公開サイト |
| Ubuntu | 22.04・24.04・26.04・26.10は修正済み（ca-certificates 20260816ubuntu0.xx.xx.1）。20.04以前は確認時点で未修正の表示 | Launchpad Bug 2171507 |
| Red Hat Enterprise Linux 6〜10 | 重要度「Important」。修正パッケージは準備中。当面の回避策として、関係するルート証明書を一覧から外す方法を案内 | Red Hat RHSB-2026-012 |
| Debian | ca-certificatesの修正版を公開（20250419~deb12u2 ほか） | 公開サイト |
| Alpine Linux | ca-certificates 20261020-r0 | Alpine Linux パッケージ一覧 |
| Java（OpenJDK） | 10月21日の勧告でCVE-2026-91403として修正。OSのパッケージのJavaはOSの証明書を使うため、OSの更新で足りる。単体で入れたJavaは本体の更新が必要 | OpenJDK Vulnerability Advisory |
| Go | Go 1.27.3・1.26.10で修正（CVE-2026-111943）。Goで作ったプログラムは作り直しが必要 | golang-announce |
| curl（CAバンドル cacert.pem） | 2026-10-20版で更新 | curl.se |
| Node.js | 24.22.1などで、同梱の証明書をNSS 3.131.1に更新 | Node.js リリースノート |
| Python（certifi） | certifi 2026.10.19を公開 | GitHub certifi |
| PHP（Composer ca-bundle） | 1.4.16・1.6.0 | 公開サイト |
このほか、Rust、Electron、Denoなどの対応も報告者側の公開サイトにまとまっています。
確認方法
ブラウザで確かめる
報告者側の公開サイト emudhra.we-have-a-problem.com を開き、「Run check」のボタンを押します。問題の中間証明書を使ったテスト用サーバーに、ブラウザがつながるかを調べる仕組みです。すべての接続が失敗すれば、そのブラウザは問題の証明書を信頼していません。
サーバーやコマンドで確かめる
同じサイトに、テスト用のアドレスが2つ載っています。調べたいサーバーで、curlを使ってそのアドレスに接続します。
curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/証明書のエラーが出れば、問題の証明書を信頼していない（対応済み）という意味です。エラーが出ずにページの中身が返ってきたら、そのサーバーの証明書の一覧は古いままです。当センターでWindows 11に入っているcurlを使って試したところ、どちらも「CRYPT_E_REVOKED」（失効済み）のエラーになりました。
この方法で分かるのは、curlが使っている証明書の一覧についてだけです。Javaやコンテナの中など、別の一覧を使うプログラムは、それぞれの環境で確かめる必要があります。公開サイトには、証明書チェーンをまとめたファイル（chains.zip）と、OpenSSLで確かめる手順もあります。
確認方法は、10月21日の夜にXの投稿で国内に広まりました。投稿は、ブラウザでの確認とcurlでの確認を順に紹介しています。
会社でやること
- PC・スマートフォンのOSとブラウザを最新にする。多くの場合、自動更新で対応は済んでいます。
- サーバーのca-certificatesを更新する。Ubuntu・Debianは
apt、RHEL系はdnfで更新します。RHELは修正パッケージが出るまで、Red Hatの回避策を検討します。PHPの更新手順はVPS・自社サーバーのPHPを修正版に更新する手順にまとめています。ca-certificatesも同じ流れで更新できます。 - Javaを確かめる。単体で入れたJava（アプリに同梱されたものを含む）は、10月21日の勧告で直った版に上げます。すぐに上げられない場合、OpenJDKは遮断リストのファイル（blocked.certs）の差し替えや、失効の確認を有効にする設定を案内しています。
- 独自の証明書の一覧を持つものを洗い出す。Pythonのcertifi、Node.js、Goで作ったプログラム、Composerのca-bundle、コンテナイメージ、業務アプリが該当します。それぞれ、更新や作り直しが必要です。
- 機器のメーカーやベンダーに問い合わせる。複合機、ネットワーク機器、IoT機器、保守契約のある業務システムは、メーカーの更新を待つことになります。
- Windowsで自動更新を止めているPCを確かめる。オフラインのPCや、更新を止めている端末が対象です。
自社サイトの証明書は大丈夫か
今回の問題は、Webサイト側のプログラムの欠陥ではありません。自社サイトの証明書がeMudhra以外の会社から発行されているなら、サイト側でやることはありません。
証明書の発行元は、ブラウザのアドレスバーの鍵マークから証明書の情報を開くと確かめられます。発行元（Issuer）に「eMudhra」「emSign」が含まれる場合は、注意が必要です。
問題の8枚の下では、サーバー証明書は発行されていません［eMudhra］。ただし、大元の「emSign ECC Root CA - G3」はFirefoxで信頼が取り消され、Chromeでも10月27日（米国太平洋時間）に一覧から外れる予定です。このルートにつながる証明書は、問題の8枚の下でなくても、Chromeで使えなくなります。Googleは、このルートにつながる証明書を使うサイトの運営者に「すぐに別の発行元の証明書に替えるよう」求めています［Google Security Blog］。
Chromeの調べでは、10月21日の時点でCTの記録から数えると、このルートにつながる有効期限内の証明書は約30,800枚ありました。そのほとんど（99.9%）は、米国の学術機関向けの発行元（InCommon）経由です［Mozilla Bugzilla 2083449、Chrome Root Program の投稿］。eMudhraも「影響は米国の一つの顧客のグループに限られる」と説明しています［eMudhra］。日本の会社のサイトが当てはまることは多くないとみられますが、発行元は一度確かめておくと安心です。
php2shellとの違い
同じ週に、PHP本体の脆弱性「php2shell」の修正版も公開されました。どちらも「AIを使って見つかった」と言われ、混同する声も見られました。中身はまったく別です。
| eMudhraの秘密鍵漏えい | php2shell | |
|---|---|---|
| 問題の場所 | 認証局の証明書（鍵の作り方の誤り） | PHP本体のプログラム |
| 危ないのは | 証明書の一覧を更新していない接続元（クライアント） | PHPを動かしているWebサーバー |
| やること | OS・ca-certificates・Javaなどの更新 | PHPを修正版に更新 |
php2shellの対策はphp2shellの解説記事にまとめています。
よくある質問
Q. 自社のWebサイトが攻撃されるのですか？
A. 今回の問題でねらわれるのは、サイトにつなぐ側の通信です。サイトのサーバーに直接入り込まれる問題ではありません。ただし、サイトのサーバーから外部のAPIや決済サービスに接続している場合は、そのサーバーが「つなぐ側」になります。ca-certificatesを更新してください。
Q. 偽の証明書が実際に使われた被害はありますか？
A. 確認した時点で、被害の公表は見つかっていません。eMudhraは悪用の証拠を把握していないとしています。報告者側の公開サイトは、CTを確かめないクライアントが攻撃されたかどうかは分からない、と書いています。一方でMozillaは10月20日、複数の人が独自に秘密鍵を求めていて、一部は公開していると書いています［Mozilla Bugzilla 2083449］。更新を後回しにしないでください。
Q. スマートフォンは大丈夫ですか？
A. AndroidはGoogle Playサービス経由で遮断が配られています。Googleは、再起動すればすぐに反映できるとしています。iPhoneは10月19日から遮断されていると、報告者側の公開サイトが書いています。どちらもOSとアプリを最新にしておけば十分です。
Q. テスト用サイトにアクセスして危なくないですか？
A. 確認用に用意されたサーバーへ接続するだけです。報告者側の公開サイトによると、記録するのは、ブラウザやプログラムの種類（ユーザーエージェント）ごとの接続の回数などの集計です。社内の決まりで外部サイトへの接続に制限がある場合は、それに従ってください。
Q. eMudhraの証明書を使っています。どうすればいいですか？
A. 証明書の発行元が「emSign ECC Root CA - G3」につながるか確かめてください。つながる場合は、Chromeで一覧から外れる10月27日（米国太平洋時間）より前に、別の発行元の証明書に替える必要があります。eMudhraは対象の顧客に直接連絡し、代わりの証明書を出していると説明しています。
サーバーのca-certificatesやJavaの更新、外部APIを呼んでいる処理の洗い出しを、自社だけで進めるのが難しい場合もあると思います。
OSやca-certificatesの更新、Java・PHPなどの実行環境の確認、更新後にテスト用サイトへ接続できないことの確認までお受けします。php2shellの対策とまとめてのご相談もできます。無料相談はこちら
参考にした情報
- 一次情報（ルートプログラム・ブラウザ）
- Mozilla Bugzilla 2083449：eMudhra: Private key compromise of Intermediate Certificates
- Google：Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
- Mozilla dev-security-policy：eMudhraに関するスレッド
- Mozilla：MFSA 2026-111（Firefox 158.0.1）
- 認証局
- eMudhra：Statement on Recent Certificate Security Incident
- eMudhra：Statement on distrust of select Global TLS Intermediate and one Root CA
- OS・ソフトウェア
- Ubuntu：ca-certificates update tracking bug（Bug 2171507）
- Red Hat：RHSB-2026-012 Certificate compromise - eMudhra
- Alpine Linux：ca-certificates パッケージ
- OpenJDK Vulnerability Advisory: 2026/10/21
- golang-announce：Go 1.27.3 and Go 1.26.10
- curl：CA certificates extracted from Mozilla
- Node.js v24.22.1 リリースノート
- python-certifi 2026.10.19
- 報告者側の公開サイト・SNS
- eMudhra Intermediate CA Compromise（emudhra.we-have-a-problem.com）
- X：確認方法を紹介した投稿（10月21日）
