eMudhra 中間 CA 証明書の秘密鍵問題｜影響範囲と確認・更新のポイント

はじめに

2026 年 10 月、インドの認証局 eMudhra（emSign ブランド）が運用する 8 つの中間 CA 証明書について、秘密鍵が極めて弱い状態で生成されていたことが公表されました。秘密鍵は公開されている証明書から第三者が計算で復元できる状態で、攻撃者が任意のドメインの証明書を作成できる可能性があります。

SNS では「ブラウザーを更新しましょう」という個人向けの注意喚起が広がっています。一方で、企業のシステム管理者にとっての論点は、ブラウザー以外で HTTPS 通信を行うサーバー、API クライアント、Java アプリケーション、コンテナが、どの証明書ストアで検証しているかという点です。本記事では、ブラウザーの対策状況とサーバー・アプリケーション側の証明書検証を分けて整理します。

本記事の内容は、2026 年 10 月 22 日 9 時（日本時間）時点で確認した公開情報に基づきます。実機での検証は行っていません。

結論として、Chrome、Firefox、Safari などの主要ブラウザーは 10 月 17 日〜20 日に対象の中間 CA をブロックし、Certificate Transparency の強制によっても保護されています。ただし、この保護はブラウザーの更新や失効情報の配信を受け取れていることが前提のため、更新を制限している端末はブラウザーも確認対象です。さらに、独自の証明書ストアや OS の CA バンドルで検証するブラウザー以外の TLS クライアントは、ブラウザーとは別に確認と更新が必要です。各ソフトウェアの検証経路を特定し、対策を含む版へ更新したうえで、実際の通信経路で証明書エラーになることを確認して対応完了と判断します。

eMudhra の中間 CA 証明書で何が起こったのか

今回の問題は、TLS の暗号アルゴリズムが破られたものではありません。2025 年 4 月の鍵生成作業で中間 CA の秘密鍵が不適切に生成され、公開鍵から秘密鍵を容易に計算できる状態のまま、その鍵に対する CA 証明書が発行・信頼されていたことが本質です。

OpenSSL などの TLS 実装の脆弱性でもない点に注意してください。2026 年 9 月に公表された OpenSSL 自体の脆弱性（DTLS の再送処理の不具合）は別の問題で、『CVE-2026-84782 OpenSSL｜DTLS の影響確認と更新判断』で解説しています。

事件の経緯

Google、Mozilla、Cloudflare の公式発表と、Mozilla の Bugzilla（Bug 2083449）に記録された各社の説明をもとに、主な経緯を整理します。Apple と Microsoft の対応日は、Mozilla の Dennis Jackson 氏が公開した検証サイトの記載です。

eMudhra の失効日時は、同社担当者が Bugzilla に記載した失効一覧と、検証サイトが公開している証明書の失効情報（CRL の記録）に基づき、10 月 18 日（UTC）としています。報道などでは eMudhra の失効を 10 月 19 日とする記載もありますが、本記事では eMudhra のステータスページを直接取得できず、その根拠を確認できていません。10 月 19 日は Sectigo がクロス署名版を失効した日で、両者を区別して扱っています。

秘密鍵生成の問題と「漏えい」との違い

対象の 8 つの中間 CA は、楕円曲線 P-384 の鍵を使用しています。P-384 の秘密鍵は本来、384 ビット規模の範囲から無作為に選ばれる整数です。Mozilla の調査では、対象の秘密鍵はいずれも 256 未満の整数で、実質的に最下位の 1 バイト以外がゼロでした。候補を順に試すだけで復元でき、Mozilla は報告者の手法を知らない状態で独自に鍵を復元しています。

参考: Mozilla Bugzilla Bug 2083449
“The 8 impacted keys all used integers less than 256.”
（影響を受けた 8 つの鍵は、いずれも 256 未満の整数を使用していた）
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

原因について、eMudhra は Bugzilla と 10 月 21 日のプレスリリースで次のように説明しています。いずれも会社側の説明で、第三者による検証結果は執筆時点で公表されていません。

• 鍵の持ち出しを想定したラップ / アンラップの手順を追加した際、スクリプトの不備で強い鍵とは別に弱い鍵ペアが HSM 上に生成され、ラベルが似ていたためにその鍵で CSR を作成した
• HSM 機器自体の問題ではないと見ており、手順の各段階に人為的な誤りがあったとして根本原因の調査を継続している
• インフラは侵害されておらず、データ漏えいもなく、物理的・論理的なセキュリティ管理は維持されていた
• 影響はグローバル TLS 事業に限られ、インド国内の電子署名証明書（DSC）や eSign の事業は別基盤で影響を受けていない

一方、Google と Mozilla が確認しているのは、公開された証明書から秘密鍵を復元できること、その鍵でブラウザーが信頼する証明書を作成できたこと、ブロック前に対象の TLS 中間 CA に連なる証明書が CT ログに記録されていなかったことです。CA のシステムへの侵入による鍵の窃取とは異なり、公開情報だけで誰でも秘密鍵を計算できた「鍵の危殆化（compromise）」と捉えるのが正確です。ただし、複数の人物が独自に鍵を復元したと Mozilla が述べているため、実務上は秘密鍵が第三者の手にあるものとして扱う必要があります。

影響を受ける 8 つの中間 CA と用途

8 つのうち 6 つが TLS サーバー証明書用、2 つがコード署名用です。同じ鍵に対して Sectigo のルート CA（AAA Certificate Services）によるクロス署名版も存在し、検証サイトでは合計 16 枚の証明書がブロック対象として扱われています。

Mozilla によると、TLS 用の 6 つは Chrome、Mozilla、Microsoft、Apple のルートプログラムで信頼され、コード署名用の 2 つは Microsoft で信頼されていました。検証サイトが公開しているルート情報では、emSign Root TLS CA – G3 は Microsoft のルートストアに直接含まれ、Chrome、Mozilla、Apple では emSign ECC Root CA – G3 からのクロス署名を経由して信頼されます。AAA Certificate Services は Apple と Microsoft に含まれ、Chrome と Mozilla からは以前に削除されています。

運用実績について、eMudhra は Bugzilla で、G3B と G3C は欧州と米国向けに作成したもので、本番稼働したのは EM DV TLS CA – G3C の 1 つだけ、かつ 8 つのいずれからもエンドエンティティ証明書は発行していないと説明しています。コード署名用の 2 つも本番稼働していないとしています。これらも会社側の説明で、TLS 証明書については前述の CT の記録が裏付けになりますが、CT の記録対象ではないコード署名の発行状況を第三者が確認した情報は見当たりません。なお、Chrome Root Program は Bugzilla で、eMudhra の公開文書が対象の CA を名称やフィンガープリントで特定していないと指摘しています。

ルート CA と中間 CA の役割

TLS クライアントは、サーバー証明書から中間 CA、ルート CA へと署名をたどり、最終的に自分の証明書ストアにあるルート CA に到達できれば証明書を信頼します。中間 CA はルート CA の代わりに日常的な証明書発行を担う CA で、その秘密鍵を持つ者は、ルート CA が信頼されている限り「正規の CA が発行した」証明書を作成できます。

今回はルート CA の鍵ではなく、その下の中間 CA の鍵が問題でした。そのため、主要ブラウザーはまず中間 CA だけを拒否する対策を取り、その後に追加の安全策としてルート CA の信頼解除へ進んでいます。

不正な証明書によってどのような攻撃が可能になるのか

秘密鍵を持つ攻撃者は、任意のドメイン名でサーバー証明書を作成できます。ただし、証明書を作れるだけでは通信を盗聴できず、被害者の通信を攻撃者のサーバーへ誘導できる立場が別に必要です。

偽証明書による攻撃の仕組みと成立条件

攻撃者は、たとえば社内システムが接続する API のドメイン名で偽の証明書を作成し、通信経路の途中で本物のサーバーになりすまします。クライアントが対象の中間 CA をまだ信頼していると、証明書エラーが出ないまま通信の内容を読み取ったり改ざんしたりできます。Red Hat は、この攻撃に次の条件がすべてそろう必要があると整理しています。

• クライアントの証明書ストアが、対象の中間 CA に連なるチェーンを信頼している
• 攻撃者が対象の秘密鍵を持っている
• 攻撃者が TLS 通信を傍受できる中間者（MITM）の位置にいる

3 つ目の条件は、同一ネットワーク上での ARP スプーフィング、DNS 応答の改ざん、BGP 経路の乗っ取り、侵害されたプロキシーや Wi-Fi などで満たされます。インターネットを経由する API 通信や、セグメントを分けていない社内ネットワークでは、この条件を排除しきれないことが多いと考えられます（編集上の見解）

コード署名用の 2 つについては、鍵を使って署名したプログラムを、ブロックを受け取っていない Windows 環境が正規の署名と判断する可能性があります。Windows の信頼リスト更新は、TLS だけでなくコード署名の検証にも関係します。

Certificate Transparency による防御と限界

Certificate Transparency（CT）は、公開 CA が発行した TLS 証明書を公開ログへ記録させる仕組みです。CT を強制するクライアントは、ログに記録された証拠（SCT）がない証明書を受け入れません。Google によると、ブロック前の時点で対象の TLS 中間 CA に連なる証明書は CT ログに 1 枚も記録されていませんでした。

参考: Google（Chrome and Android Security Teams）
“no fraudulent certificates issued by these CAs could have been used against CT-enforcing clients”
（これらの CA が発行した不正な証明書は、CT を強制するクライアントに対しては使用できなかった）
https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Google はこの対象に、既定で CT を強制する Chrome と、最新の SDK を対象とするか CT 強制を有効にした Android アプリを挙げています。検証サイトも、Firefox、Chrome、Edge、Safari は攻撃を受けえなかったと説明しています。また Google によると、CT ログ側も対象の CA に連なる証明書を拒否するよう更新されました。

一方で、OpenSSL、Java、Python、Node.js などで実装した一般的な TLS クライアントの多くは CT を検証しません。CT による保護は、これらのクライアントには及ばないと考える必要があります。

確認されている事実と未確認事項

技術的に可能な攻撃

対象の中間 CA を信頼したままのクライアントに対し、任意のドメインを装う中間者攻撃が可能です。秘密鍵の復元は容易で、複数の人物が独自に復元したことを Mozilla が確認しています。

確認されている事実

CT を強制するブラウザーに対しては悪用できなかったことを、Google と検証サイトが説明しています。Cloudflare は、自社サービス上で悪用は確認されていないと公表しています。

現時点で不明な事項

鍵が復元可能だった 2025 年 4 月以降に、CT を強制しないクライアントやコード署名で悪用があったかどうかは確認できていません。検証サイトも、攻撃者がこの欠陥を悪用したかは分からないとしています。eMudhra の原因調査も継続中です。

Chrome・Firefox・OS の対応状況

主要ブラウザーと OS ベンダーは、中間 CA のブロックを数時間〜3 日で配信しました。その後、Mozilla と Google は、失効情報を利用できないクライアントも保護するため、ルート CA の信頼解除まで踏み込んでいます。

Google・Mozilla・Apple・Microsoft の対応

Apple と Microsoft の対応は、執筆時点で両社の公式発表を本記事では確認できておらず、検証サイトの記載に基づいています。

ルート CA の信頼解除と正規サイトへの影響

中間 CA のブロックは問題の鍵だけを拒否する対策で、正規サイトへの影響はほとんどありません。これに対して、ルート CA の信頼解除はそのルートに連なるすべての証明書を拒否するため、正規の証明書を使うサイトにも接続エラーが発生します。

Mozilla は、複数の人物が鍵を独自に復元し、一部が公開していることを受け、失効情報を利用しないクライアントを保護するために emSign ECC Root CA – G3 の信頼を緊急に解除しました。Chrome も同様の方針を示し、10 月 27 日に Chrome Root Store から削除します。Mozilla は、RSA 系の emSign Root CA – G1 については現時点で信頼を解除しないとしています。

Chrome Root Program が Bugzilla に記載した CT の集計では、10 月 21 日時点で emSign ECC Root CA – G3 に連なる有効期限内のプレ証明書が約 30,800 枚あり、99.9% が Internet2 / InCommon の下位 CA から発行されたものです。eMudhra は、移行が必要な証明書は約 30,000 枚で、約 97% が ACME 経由で発行されたと説明しています。

Google は、emSign ECC Root CA – G3 に連なる証明書を使うサイト運営者に対し、Chrome Root Store に含まれる別の PKI 階層から新しい TLS 証明書を直ちに取得・設置するよう求めています。自社サイトの証明書がこのルートに連なる場合は、クライアント側の更新ではなく、サーバー証明書の差し替えが必要です。また、自社の TLS クライアントを更新した後に、取引先や海外の大学などの API でエラーが出た場合は、接続先の証明書がこのルートに連なっていないかを確認します。

Sectigo によるクロス署名版は 10 月 19 日に失効済みです。ただし、失効情報を参照しないクライアントで AAA Certificate Services（Linux の CA ストアでは Comodo AAA Services root）を信頼している場合は、このクロス署名の経路も残ります。Red Hat が暫定策として 2 つのルート CA をブロックリストに追加する手順を示しているのはこのためです。

参考: Red Hat RHSB-2026-012
“This mitigation distrusts the root CAs entirely.”
（この緩和策は、ルート CA を全面的に信頼しない状態にする）
https://access.redhat.com/security/vulnerabilities/RHSB-2026-012

Red Hat は、この暫定策で両ルートに連なる正規の証明書も信頼されなくなるため、必要な中間 CA は個別に追加するよう案内しています。AAA Certificate Services は古くから使われているルートのため、ブロックリストへの追加は影響範囲を確認してから実施することを推奨します。

サーバー・アプリケーションの影響確認方法

同じ PC やサーバーでも、ブラウザー、OS 標準の通信機能、Java、Python、Node.js、コンテナは、それぞれ別の証明書ストアと検証ロジックを使う場合があります。確認の単位は「端末」ではなく「証明書の検証経路」です。

ブラウザーと TLS クライアントで検証経路が異なる理由

Chrome や Firefox は、CRLSet や OneCRL のように中間 CA を個別に拒否できる配信の仕組みと、CT の強制を備えています。多くのサーバー向け TLS クライアントは、ルート CA の一覧（CA バンドル）だけで検証し、失効情報を既定で確認しません。そのため、ルート一覧から問題のルートが消えるか、ソフトウェア側に拒否リストが組み込まれるまでは、問題の中間 CA に連なるチェーンを受け入れます。

Cloudflare は、SDK を更新しても、その下で証明書を検証する HTTP ライブラリ、言語ランタイム、OS、独自の信頼設定が変わらなければ検証方針は変わらないと注意を促しています。

Java・curl・Python・Node.js などの確認事項

主な TLS クライアントごとに、検証の仕組みと確認事項を整理します。バージョン番号は、公式情報で確認できたものと検証サイトの一覧によるものを区別して記載しています。

Java は、OpenJDK と Oracle JDK の対応版が検証サイトの一覧に掲載されていますが、本記事では執筆時点で配布元の公式情報を確認できていません。Oracle、Red Hat、Azul、Eclipse Temurin など、利用中のベンダーの公式リリースノートで対応の有無を確認してください。Node.js は、公式の「October 2026 Security Releases」で、22.x / 24.x / 26.x 系に eMudhra の中間 CA 侵害に関する CA 証明書の更新が含まれ、対象リリースが 22.23.4、24.22.1、26.12.1 であることを確認できます。24.22.1 のリリースノートには、ルート証明書の NSS 3.131.1 への更新が記載されています。

このほか、Go（1.27.3、1.26.10）、Electron、Rust の webpki-roots、pip、uv なども、検証サイトの一覧に対応版が掲載されています。最新版であることと、今回の対策を含む版であることは同じではありません。各ソフトウェアのリリースノートで、eMudhra 関連の変更が含まれることを確認します。

Python で、どの certifi が使われているかは次のコマンドで確認できます。仮想環境ごとに実行してください。

python3 -c "import certifi; print(certifi.__version__, certifi.where())"

RHEL 系では rpm -q ca-certificates、Debian / Ubuntu 系では dpkg -l ca-certificates でパッケージの版数を確認し、配布元のセキュリティ情報に記載された修正版と比較します。

コンテナと独自の証明書ストア

コンテナは、イメージに含まれる ca-certificates や言語ランタイムで証明書を検証します。ホストの ca-certificates を更新しても、稼働中のコンテナには反映されません。Cloudflare は、依存関係を更新したうえでイメージを再ビルドし、再読み込み、再起動、再デプロイのどれが必要かを確認するよう推奨しています。Red Hat も、UBI などのベースイメージが更新されたら、利用者側のコンテナを再ビルドするよう案内しています。

アプリケーションが独自の CA バンドルを同梱している場合や、相互 TLS（mTLS）でクライアント証明書を検証するために公開 CA を信頼ストアへ登録している場合も、個別の見直しが必要です。依存関係が間接的に CA バンドルを持ち込んでいることもあるため、Cloudflare は依存関係ツリーまで確認するよう勧めています。

検証サイトの使い方と結果の読み方

Mozilla の Dennis Jackson 氏が公開した検証サイト（https://emudhra.we-have-a-problem.com/）では、ブラウザーでの確認と、curl などコマンドラインでの確認方法が公開されています。研究者が公開したコミュニティの情報で、ベンダーの公式情報ではない点に注意してください。コマンドラインでは、次の 2 つのホストへの接続を試します。1 行目は eMudhra のルート経由、2 行目は Sectigo のクロス署名経由のチェーンを確認するものです。

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Windows PowerShell 5.1 では、curl が Invoke-WebRequest のエイリアスとして定義されているため、curl 本体を使うには curl.exe と明示します（Microsoft Learn「Windows での curl」）。PowerShell 7 以降にはこのエイリアスはありません。

curl.exe https://dv-g3b-emudhra.we-have-a-problem.com/
curl.exe https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

検証サイトは、証明書エラーになればクライアントは問題の中間 CA を信頼していないと説明しています。結果は次の 3 つに分けて判断します。curl の終了コードは、Linux や macOS では直後に echo $? で確認できます。

終了コードの定義は curl の公式ドキュメント（libcurl error codes）で確認できます。接続できなかったことだけで、証明書が正しく拒否されたとは限りません。プロキシーやファイアウォールで外部への通信が止まっている環境では、エラーメッセージが証明書の検証に関するものかを必ず確認してください。また、2 行目のホストで拒否されても、それが「AAA Certificate Services を信頼していない」ためか「対象の中間 CA を拒否した」ためかは、結果だけでは区別できません。

参考: Cloudflare Blog
“A successful browser test does not prove that a background service is protected.”
（ブラウザーでの確認に成功しても、バックグラウンドで動くサービスが保護されていることの証明にはならない）
https://blog.cloudflare.com/emudhra-certificate-compromise/

Cloudflare は同じ記事で、アプリケーションが curl と異なる検証機能を使う場合は curl での確認も保護の証明にならないと述べ、アプリケーションの実際の TLS 経路で確認するよう求めています。たとえば Linux 上の curl が拒否しても、同じサーバー上の Java アプリケーションは JDK の cacerts で検証しているため、結果が異なる可能性があります。

確認時や更新後に証明書エラーが出ても、curl の -k / --insecure やアプリケーションの検証無効化で回避しないでください。Cloudflare も、検証を無効化すると今回の更新で回復させる認証の保護が失われると注意しています。

システム管理者が確認すべき対応と更新後の判断

対応は、HTTPS 通信を行うシステムを洗い出し、それぞれの検証経路に合った更新を適用し、実際の経路で拒否されることを確かめる流れで進めます。優先度は、インターネット上の外部 API と通信するサーバーや、通信経路を第三者と共有するシステムから付けることを推奨します。

openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null | grep -i "emsign"

openssl s_client -connect www.example.com:443 -servername www.example.com -verify_return_error </dev/null

更新後に対応完了と判断する基準

「OS を更新した」「最新版を入れた」だけでは完了と判断できません。次の条件を検証経路ごとに満たしたことを記録し、完了と判断することを推奨します。

• 各検証経路のソフトウェアや CA バンドルが、配布元が今回の対策を明記した版以降になっている
• 更新後にプロセスの再起動、またはコンテナの再ビルドと再デプロイを済ませている
• アプリケーションと同じ検証経路で、検証サイトのホストへの接続が証明書の検証エラーになる
• 通常の接続先には引き続き接続でき、証明書エラーを検証無効化で回避した箇所がない
• 検証パスの確認で、自社サイトの証明書が emSign ECC Root CA – G3 に依存していない

修正版が未提供の製品への暫定的な対応

アプライアンスや組み込み機器、更新が遅れているディストリビューションでは、修正版の提供を待つ間の暫定策を検討します。最初にベンダーへ対応予定を確認し、ベンダーが示す手順を優先してください。

Linux では、Red Hat と検証サイトが、ディストリビューションごとに emSign ECC Root CA – G3 と Comodo AAA Services root を信頼しない設定にする手順を公開しています。前述のとおり正規の証明書にも影響するため、影響範囲を確認できる環境に限って適用し、修正版の ca-certificates を適用した後に設定を見直します。検証サイトは、Debian や Ubuntu 向けの手順を一般利用者には推奨しないと明記しています。

Windows では、信頼リストの自動更新が届かない端末向けに、対象の証明書を「信頼されていない証明書」ストアへ登録するスクリプトが検証サイトで公開されています。検証サイト自身が企業の管理端末には推奨しないとしているため、企業環境では Microsoft の公式情報を確認したうえで、グループポリシーなど組織の管理手段で配布することを推奨します。

アプリケーション独自の CA バンドルを持つ製品で修正版がない場合は、通信先を固定できるかどうか、通信経路を社内の管理された経路に限定できるかどうかを確認し、更新までのリスクを判断します。

まとめ

eMudhra の問題は、暗号アルゴリズムではなく中間 CA の秘密鍵生成の不備により、第三者が鍵を復元できた事案です。主要ブラウザーは更新と失効情報の配信を受け取れる環境であれば中間 CA のブロックと CT の強制で保護されますが、ブラウザー以外の TLS クライアントは検証経路ごとに更新と確認が必要です。

• 8 つの中間 CA の秘密鍵は、公開情報から容易に復元できた
• 悪用には中間者の位置で通信を傍受する条件も必要です。
• 主要ブラウザーの保護は、更新と失効情報の受信が前提です。
• Java、Python、Node.js、コンテナは検証経路ごとの更新が必要です。
• 接続失敗ではなく証明書の検証エラーになることで対策を確認します。
• 自社サイトの確認は、送信された証明書一覧ではなく検証パスで判断します。
• emSign ECC Root CA – G3 の証明書は 10 月 27 日までに差し替えが必要です。

以上、最後までお読みいただきありがとうございました。