出典は北京時間 2026 年 10 月 22 日に確認されました。 対象者: 個人ユーザー、Web サイト運営者、開発者、システム管理者。
深刻な弱点により、 eMudhra / emSign 中級 CA 秘密鍵は回復可能です。これは、Web サイト、API、およびソフトウェアの認証に公開証明書システムを使用するクライアントに影響します。パブリックの信頼は主要なオペレーティング システムにまたがりますが、侵害されたキーのセットと潜在的なクライアントへの影響は範囲が異なります。 1 5
本文では角かっこを使用して対応するソースに番号を付け、すべての外部参照リンクを付録にリストします。リストされているバージョンは、検証日の時点でこのインシデントの修正が含まれていることが確認されているバージョン ベースラインです。デプロイ時には、同じサポートされるブランチ内の更新された安定バージョンが優先されます。
TL;DR
中級8人 CA 秘密鍵が侵害されたことが確認されています。現在の報告では、ルート秘密鍵または HTTPS cryptography in general have been broken.アップデートはパブリックトラストエコシステムの大部分に及びます。 residual risk depends on the actual application. 1 5
- 個人ユーザー: ブラウザ、オペレーティング システム、セキュリティ コンポーネントを更新します。の上 Android 、も更新します Google Play サービス。使用 Firefox Android 158.0.2 またはそれ以降。 1 2
- サーバー: ディストリビューションを更新する
ca-certificates/ NSS パッケージを作成し、アプリケーションにバンドルされているトラスト ストアを確認します。ホストのみを更新するだけでは不十分です。 7 8 10 - 開発環境: は、必要に応じて、Node 24 を 24.22.1 またはそのブランチの新しいリリースに更新します。 Python 環境では、少なくとも pip 26.2.2、certifi 2026.10.19、および uv 0.13.4 に更新します。修正された Go バイナリを入手するか、それらを再構築します。ベンダーの勧告に従って Java を更新します。 12–15
- 更新をアクティブ化します: 影響を受けるサービスを再起動し、コンテナーを再構築して再デプロイします。 Cloudflare Tunnel の場合は、cloudflared を 2026.10.2 以降に更新します。 7
- ウェブサイトの証明書: 取り消された中間またはブロックされた中間が含まれている場合は、影響を受けるチェーンを置き換えます。 CA 、または信頼されていないルートに依存します。証明書の再発行は、クライアントの信頼ストアの更新に代わるものではありません。 1 5 8
- Verification: 各アプリケーションの実際の TLS パスをテストします。証明書の拒否をタイムアウトや DNS エラーと区別します。証明書の検証を有効にしておきます。
-kを使用したり、エラーを抑制するために検証をスキップしたりしないでください。 7
1 事件の事実と原因
確認された事実
Mozilla そして Google 8箇所で不具合を確認しました eMudhra 中級 CA 秘密鍵。研究者は秘密鍵管理の証拠を提出しました。 Mozilla 独自にキーを回復し、問題を再現しました。 6 つの中間 CA がサービスを提供 TLS そして 2 つはコード署名を提供します。 2 5
欠陥は生成されたキーにあります。これらの中間 CA は P-384 曲線を使用しますが、秘密キーは 256 未満の整数です。これは、意図した広い範囲からランダムにキーを安全に選択することには程遠いです。これらの弱いキーを回復しても、適切に生成された P-384 キーが壊れる可能性があることは証明されません。 2
ここでの「証明書が解読された」とは、正確には「対応する秘密鍵を回復できる」と理解する必要があります。証明書とその中の公開鍵は本質的に公開されています。本当に秘密にしておく必要があるのは、有効な署名を生成できる秘密キーです。
キー生成プロセスの問題はまだ調査中
eMudhra の最初の説明では、問題の原因を 2025 年 4 月の鍵生成式までたどっています。この説明には、鍵のカプセル化とカプセル化解除のステップが含まれています。つまり、元の強い鍵に加えて、別の弱い鍵のセットが出現し、その後、弱い鍵が証明書の申請と発行に使用されます。同社は依然として、正確な根本原因は最終的に特定されていないと述べた。 6
したがって、これらのキーは非常に弱く、侵害されていると判断できます。この障害は、HSM の特定のハードウェア乱数ソースに欠陥があることが証明されたとしてさらに説明することはできません。また、RSA、ECC、または TLS の一般的な暗号技術のブレークスルーとして説明することもできません。
ルート証明書の不信感とは何を意味しますか?
ブラウザまたはオペレーティング システムは、影響を受ける中間 CA の証明書または公開キーを直接ブロックすることも、それらにつながるルート信頼を削除することもできます。後者の措置では、同じルートにある一部の正当な証明書も拒否されます。
Google は、CRLSet から更新を受け取らない Chrome ルート ストアのユーザーを保護するために、emSign ECC Root CA - G3 の削除をスケジュールしました。ルートストアの削除は、北京時間の 10 月 27 日から 28 日までの対応期間中に行われる予定です。 Google の元の時刻は、米国太平洋夏時間の 10 月 27 日の朝です。この計画は、以前に展開された緊急公開キー ブロックとは別のものです。 1
ルートを信頼しないことは対応策です。それ自体は、ルート秘密キーが侵害されたことを証明するものではありません。
2 潜在的な影響が公共信託エコシステムに及ぶ理由
侵害されたキーと影響を受けるトラスト パス
| 判定対象 | この事件の範囲 |
|---|---|
| 問題のあるキーが特定されました | eMudhra の 8 個の中間 CA 秘密キー |
| 対応が必要となる可能性があるプラットフォーム | パブリック ルート ストア、ブラウザ、オペレーティング システム、言語ランタイム、ソフトウェア パッケージ、コンテナ エコシステム |
| ID TLS になりすました可能性があります | クライアントが訪問した Web サイトまたはサービスが、関連する偽造証明書チェーンをまだ受け入れている |
| すべてのデバイスが侵害されたということですか? | いいえ。信頼条件、攻撃者のネットワークの場所、およびその他の検証戦略が悪用可能性を決定します |
| 法的な証明書はすべて無効ということですか? | いいえ。関連する無効化は、クライアントがどのルートまたは証明書チェーンを信頼していないかによって異なります。 |
Red Hat は、クライアントが関連チェーンを引き続き受け入れ、攻撃者が侵害された秘密キーを所有し、ネットワーク内の接続を傍受できる状況に悪用を明示的に制限します。リスク カバレッジを、発生した攻撃の数と混同しないでください。 10
他の CA を使用している Web サイトもなりすまされる可能性があります
Web サイトが実際に Let’s Encrypt 証明書を使用し、訪問者のクライアントが複数のパブリック CA を同時に信頼すると仮定します。攻撃者は、侵害された中間 CA を使用して、同じドメイン名に対して別の証明書を作成しようとする可能性があります。通常、クライアントは、ドメイン名が Let’s Encrypt のみを使用できることを事前に要求しません。偽のチェーンがまだ受け入れられている場合、Web サイトが実際に使用している CA だけでは、そのような攻撃を排除するのに十分ではありません。 8
このメカニズムは次のことを説明しています。元々は正常だった別の CA 証明書を置き換えても、侵害された CA に対するクライアントの信頼は自動的に修復されません。本当に遮断する必要があるのは、クライアントが偽の ID を受け入れる経路です。
3 つの効果は個別に処理する必要があります
ID なりすましのリスク: 関連するチェーンをブロックしていないクライアントは、攻撃者によって偽造された ID を受け入れる可能性があり、機密リクエストが偽のサービスに送信される可能性があります。
正当なサービス可用性のリスク: ルート信頼を削除すると、正当な Web サイトで証明書エラーが発生する可能性があり、別の承認されたチェーンへの移行が必要になる可能性があります。
デプロイメント カバレッジ リスク: アプリケーションにバンドルされたトラスト ストア、仮想環境、古いコンテナー イメージ、またはコンパイルされたプログラムが古い検証動作を保持している間に、オペレーティング システムが修正される可能性があります。
これら 3 つのスコープは同一ではありません。 Cloudflare の応答は、リモート ID 検証、共有トラスト ストア、基本イメージ、および個々のアプリケーションをカバーしており、後者の 2 つのタスクを別々に処理する必要がある理由を示しています。 7
3 影響を受ける CA および証明書プロバイダー
プロバイダーと影響の種類
| プロバイダーまたはシステム | この事件における役割 | 区別する必要がある境界線 |
|---|---|---|
| eMudhra／emSign | 中間の CA 秘密キーが直接侵害されます。 | すべての eMudhra ルートとすべての証明書をクラックされたものとして書き込むことはできません |
| Sectigo 関連の相互署名チェーン | 影響を受ける公開キーの同じバッチに対して A 相互証明書が発行され、別の信頼パスが形成されました。 | 対応する相互証明書または公開キーをブロックする必要があります。 Sectigo ルート秘密キーが侵害されたことは証明されていません。 |
| Internet2/InCommon に関連する証明書レベル | 一部の正規の証明書は、移行を伴う削除対象の emSign ECC ルートに依存しています。 | これはルート不信の付随的な影響であり、8 つの弱いキー CA の真ん中として数えることはできません。 |
| Let’s Encrypt、DigiCert、Google Trust Services、GlobalSignなど | このレポートでは秘密鍵が侵害された当事者としてリストされていません | 正規の証明書は一律に無効になるわけではありません。脆弱なクライアントは、サービスを提供する Web サイトになりすました偽の証明書を引き続き受け入れる可能性があります |
| CDN、クラウド プラットフォーム、証明書ディーラー | オリジンおよび API に接続するときに、関連する証明書を提供するか、パブリック トラストストアを使用する可能性があります。 | 実際の証明書チェーンとバリデーターを確認するには、プラットフォームや製品名だけを調べるのではありません。 |
Mozilla の通知には侵害されたキーが文書化されており、 Sectigo クロスサイン。 Google の公開事件に関するディスカッションでは、合法的な人の移住について言及しています Internet2 / InCommon 階層。 2 5 Cloudflare の修正はサービスとクライアントの信頼に対処します。それらは妥協を示すものではありません Cloudflare さん自身の CA 秘密鍵。 7
TLS 証明書チェーンと相互署名
次の関係は、今回は TLS 関連のパスのみを説明します。これにはコード署名パスは含まれていません。また、これらのパスがすべてのプラットフォームで依然として信頼されることを意味するものでもありません。 17
emSign ECC Root CA - G3→emSign Root TLS CA - G3→ 影響を受ける TLS 中間 CA 公開鍵 → 対象ドメインの証明書が偽造されるAAA Certificate Services→ 影響を受ける TLS 中間 CA 公開鍵 → 対象ドメインの証明書が偽造される
emSign Root TLS CA - G3 は、影響を受ける TLS 中間体の直接発行者の 1 つであり、それ自体が一部のストアではトラスト アンカーになる可能性があります。 emSign ECC Root CA - G3 は、別の相互署名レイヤーを提供します。 Sectigo の AAA Certificate Services は、同じ中間 CA 公開キーへの追加パスを作成します。 17
したがって、修復には 2 つの異なる粒度があります。
- 正確な中間 CA または公開キー: をブロックします。これにより、バリデーターがそのメカニズムをサポートしている同じルートの下に他の正当な階層を保存できます。
- ルート信頼の削除: これにより、中間の CA ブロック機能なしでクライアントを保護できますが、互換性に影響を与える可能性があります。クライアントが受け入れる他のすべてのパスもカバーされる必要があります。 5
「すべての Sectigo/eMudhra ルートを削除する」を無差別な一般的な手順として実行すべきではありません。また、類似した名前の証明書を削除するだけですべてのパスが閉じられることを意味するべきではありません。
4 オペレーティング システムとブラウザの対象範囲
メインプラットフォーム
| プラットフォーム | 既知の性質 | 利用時に確認すべき範囲 |
|---|---|---|
| Windows および Windows Server | Microsoft 証明書信頼リストの自動更新により配布がブロックされる | デバイスがアップデートを受信したかどうか。スタンドアロン CA bundle は、必ずしも Windows の検証パスを使用するわけではありません |
| macOS、iOS、iPadOSなど Appleプラットフォーム | インシデントコーディネーターは、Apple が関連する封鎖を展開したことを確認しました | すべての古いバージョンとサードパーティ製アプリが同じ補償を受けることが保証されているわけではありません |
| Android | Google は、Google Play サービスを通じて同等のブロックを配布します | Google Play サービスのない ROM は、メーカーの発表に従って検証する必要があります。追加の検証には組み込みの検証ツールを使用します |
| Ubuntu | 複数の現行バージョンと旧バージョンのブランチを含む、システム証明書バンドルの修正が提供されました | ESM の古いバージョンは、条件、コンテナ内部証明書パッケージ、アプリケーション組み込みライブラリをサポートしています |
| Debian および Devuan | Debian 記録済み ca-certificates 修正 | 実際に使用されているブランチとインストールされているパッケージを確認する必要があります。別のブランチのバージョン番号をコピーすることはできません。 |
| RHEL および派生製品 | 公式リストは RHEL 6、7、8、9、10 で、影響を受ける可能性のある関連製品と画像が含まれています。 | このチェックの時点では、発表には修正と正誤表の完全なリストがまだ記載されていません。 「アップデートが見つかりません」は影響を受けないと考えられません |
| Fedora、Arch、Gentoo、Alpineなど | イベント管理者が対応する修理記録をまとめました | リリース、バージョン ブランチ、イメージごとに個別に確認 |
| FreeBSD | サポートされているすべてのバージョンを正式にリストし、システム トラスト ストアの修復を提供します | 更新後、アナウンスに従って関連するデーモン プロセスを再起動します。独立したアプリケーションのトラスト ストアを個別に確認してください。 |
Windows、Apple およびリリースの概要については、4 を参照してください。 Android については、1 を参照してください。 Ubuntu、Debian、RHEL、および FreeBSD の場合、発行者レコードはそれぞれ 8 ～ 11 に表示されます。
サポートされなくなったシステム、オフライン デバイス、NAS、ルーター、その他の組み込み環境は、関連するチェーンをまだ信頼しているかどうか、取り消しやソフトウェアの更新を受信するチャネルがあるかどうかを確認する必要があります。プラットフォーム名自体は、実際の検証動作を確認する代わりにはなりません。
ブラウザの保護はオペレーティング システムの保護とは異なります
Chrome 用途 CRLSet 緊急ブロックを配布する。 Firefox などのメカニズムを使用します OneCRL . Firefox リモート設定を適切に受信しない構成に追加の保護を提供するためのブロック情報もリリースされました。 1 3
Firefox Android の一部の構成は起動時に更新されたリストを正しく適用していませんでしたが、Mozilla は 158.0.2. によって修正されると述べています。そのため、初期の 158.0.1 のステータスを、保護されたすべての Android Firefox 構成を含むように拡張することはできません。 2
AppleおよびWindowsのシステム検証については対策が講じられていますが、同一マシン上のすべてのコマンドラインプログラムがシステム検証を受けることを意味するものではありません。イベント管理者は、一部の macOS 組み込みツールが独立した証明書ファイルを使用していることを特に思い出させました。チェックする際には、実際の TLS バックエンドと CA ソースを記録する必要があります。 4
証明書の透明性のための保護境界
Google ブロックを実装する前に、6 つの TLS 中級 CA を発行しませんでした TLS に入った証明書 CT ログ。したがって、 Chrome 強制するクライアント CT 追加の保護があります。この事実は、他のクライアントが実行しない可能性を排除するものではありません。 CT 文書化されていない証明書を受け入れました。 1 5
「信頼されたルートにリンクできることが判明した」、「潜在的な悪用条件が存在する」、「攻撃が発生した」は 3 つの異なる判断であり、相互に置き換えるべきではありません。
5 開発環境とランタイム修復ベースライン
以下は確認済みの修正のベースラインであり、これらのリリースを長期的に固定するための要件ではありません。ディストリビューションはパッチを戻すことで古いバージョン番号を修正する場合があり、そのセキュリティ勧告も確認する必要があります。
| コンポーネント | 確認済みバージョンまたはアップデート方法 | 導入に関する考慮事項 |
|---|---|---|
| Node.js 24 | 24.22.1 または同じブランチの安定バージョンを更新します | ルート リポジトリの更新とブロックされた公開キーチェーンの拒否が含まれます。サービスによって実際に使用されている Node パスを確認し、再起動します |
| Python certifi | 2026.10.19 以降のバージョン | それぞれの実際の実行環境を確認してください。グローバル Python の下で 1 つのパッケージのみを更新することはできません |
| pip | 26.2.2 以降のバージョン | 旧仮想環境で別途pipを更新し、新環境作成後にバージョンを確認する |
| uv | 0.13.4 以降のバージョン | 実際にインストールされたツールのコピーを更新します |
| Go | 1.27.3 または 1.26.10、対応するブランチの更新バージョンも利用可能です | ツールチェーンを更新した後に関連プログラムを再構築して展開するか、ベンダーの修復バイナリを入手します。 |
| Oracle JDK | 対応するサポートされているバージョンラインの Critical パッチ | さまざまな JDK パブリッシャーが独自の発表に従っています。すべての Java リリースに適用される単一のバージョン番号はありません。 |
| Cloudflare Tunnel | cloudflared 2026.10.2 以降のバージョン | 実行中のサービスを更新します。コンテナのデプロイにはイメージを置き換えて再デプロイする必要があります |
| Cloudflare One／WARP | プラットフォームに対応する固定クライアント バージョン、または更新された安定バージョン | クライアント側とサーバー側の対策を個別に確認します。特定のプラットフォームのバージョンについては、付録 7 を参照してください。 |
Node、Python、Go、Oracle、および Cloudflare のオリジナルの命令は、それぞれ 13、12、14、15 で入手できます。 7。
Python 独立した証明書データベースの問題
Python 関係者は、古い pip はシステムの信頼と組み込みの certifi を組み合わせて使用することになると指摘しました。システム証明書ストアを変更するか、CA ファイルを pip に追加するだけでは、その組み込みの古い信頼を確実に除外することはできません。したがって、PIP_CERT、REQUESTS_CA_BUNDLE、または --cert は、古い pip の汎用修理代替品として使用できません。 12
更新後に既存の仮想環境を確認してください。また、古いブートストラップ コンポーネントが脆弱なツールを再導入しないように、新しく作成された環境に実際にインストールされている pip バージョンを確認します。初期アップグレードの場合は、他のパッケージを更新する前に、Python のアドバイザリにあるダウンロード ソースと SHA-256 の検証手順に従ってください。 12
Go およびその他のコンパイルされたプログラム
Go の修正により、crypto/x509 の検証ロジックが変更されました。 14 デプロイメント メカニズムの観点から見ると、開発マシン上のコンパイラを更新しても、既にデプロイされているバイナリは書き換えられません。新しいコード層のブロックを取得するには、アプリケーションを再構築して置き換えるか、ベンダーが提供する更新バージョンを使用する必要があります。古いプログラムでもシステム ルート アップデートの恩恵を受けることができるかどうかは、そのプログラムが使用する実際の検証パスによって異なります。
コンテナとパッケージ化されたアプリケーション
システム証明書パッケージ、アプリケーションの依存関係、コンテナ内のランタイムは通常、イメージのコンテンツによって決まります。ホストの更新は画像コンテンツの更新と同じではありません。基本イメージと依存関係を更新する必要があり、実際に実行中のインスタンスを再構築、デプロイ、チェックする必要があります。独自のランタイムが付属するパッケージ化されたアプリケーションとデスクトップ プログラムも、ベンダーのリリース チャネルに従って更新する必要があります。 7 10
6 修理の実施手順
まずは検査対象を決める
保護する必要があるサービスに関する次の情報を記録し、対応する修復パスを選択することをお勧めします。これは展開チェックリストであり、すべてのコンポーネントがすべてのシステムに存在する必要はありません。
| プロジェクト | 記録する必要があるもの |
|---|---|
| 用途と用途 | ブラウザ、決済APIクライアント、メール送信サービス、ダウンロードツール、リバースプロキシ等 |
| 動作位置 | ホスト、コンテナ、仮想マシン、デスクトップ アプリケーション、またはモバイル デバイス |
| 実装の検証 | オペレーティング システム バリデータ、OpenSSL、Node、Python ライブラリ、Java またはアプリケーションのカスタム実装 |
| 信頼できる情報源 | システム CA パッケージ、certifi、JDK トラスト ストア、組み込み CA bundle またはエンタープライズ構成 |
| 修理状況 | インストールされているバージョン、パッチのソース、再起動するか再デプロイするか |
| 合格結果 | 影響を受けるチェーンが拒否されるかどうか、通常のビジネス接続が成功するかどうか、およびチェック時間 |
Cloudflare の開発者ガイドには、SDK が検証を他のコンポーネントに委任する可能性があると具体的に記載されています。最上位の SDK を更新するだけでは、必ずしも実際の信頼ポリシーが変更されるわけではありません。 7
オペレーティング システムとブラウザ
Windows: 証明書信頼リストの自動更新を有効にして検証します。確立された管理ポリシーを通じてアップデートを配布します。オフラインのデバイスまたは自動更新が無効になっているデバイスには、適切な管理プロセスを通じてブロックを適用する必要があります。 Windows システム検証を使用しないプログラムを個別に確認してください。 4
Apple プラットフォーム: システム、セキュリティ コンポーネント、アプリケーションの完全なアップデート。 macOS の開発ツールについては、TLS バックエンド、証明書ファイル、およびインストール ソースも確認してください。 Safari がテストチェーンを拒否したからといって、マシン全体が修復されたとは判断できません。 4
Android: それを備えたデバイス上の Google Play サービスを更新します。 Google には、デバイスを再起動すると即時更新がトリガーされる可能性があると記載されています。これらのサービスのないデバイスの場合は、ベンダーまたは ROM アドバイザリに従ってください。 Google の適用範囲ステートメントは、すべての Android デバイスに自動的に適用されるわけではありません。 1
Ubuntu / Debian : サポートされているリポジトリから証明書パッケージを更新し、インストールされているディストリビューションのアドバイザリを確認します。たとえば、 APT -ベースのシステムは以下を使用できます:
sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates関連するアップデート Ubuntu 22.04 , 24.04 , 26.04 、 そして 26.10 標準サポートです。以前のバージョンでは確認する必要があります ESM サポートと倉庫のステータス。コマンドが正常に終了した後も、セキュリティ情報でフィックスパックのバージョンを比較する必要があります。 8 9
RHEL および関連製品: 製品チャネルごとに証明書パッケージとセキュリティ エラッタを確認してください。バージョンチェックは以下を使用して実行できます。
rpm -q ca-certificatesサポートされている DNF/YUM 更新メカニズムを使用して、ベンダー パッチを取得します。チャネルがまだ修正を提供していない場合は、「更新可能なパッケージがない」ことを安全であるとは考えないでください。ルート信頼を一時的に削除する必要がある場合は、製造元が明確にリストした対策を採用し、正規のビジネス証明書の互換性を評価してください。 10
FreeBSD: 公式アドバイザリーの指示に従って関連するシステム ブランチを更新し、影響を受ける OpenSSL 信頼構成を使用してデーモンを再起動するか、システムを再起動します。 11
アプリケーションと画像
対応するランタイムと証明書の依存関係の更新が完了したら、ターミナルが新しいバージョンに切り替わり、デーモンが依然として古いインストール ディレクトリを使用していることを避けるために、サービスが実際に実行されている実行可能ファイルのパスを確認してください。マルチ環境 Python、独自のランタイムが付属するサービス コンテナーおよびアプリケーションの場合は、個別に確認する必要があります。
再構築する必要があるコンポーネントの場合は、ビルド バージョン、依存関係バージョン、および展開イメージ ID を保存します。受け入れオブジェクトは実際に実行中のインスタンスであり、ビルド マシンまたはイメージ レジストリ内の新しいタグをチェックするだけでは済みません。 7 12 14
Web サイト証明書の移行
Web サイトのチェーンに取り消されたまたはブロックされた中間ファイルが含まれている場合 CA 、または最終的に信頼できないルートに依存する場合は、クライアントが依然として受け入れる別のチェーンを取得します。完全なサーバー証明書チェーンをインストールし、ロード バランサー、リバース プロキシ、 CDN エンドポイントと直接アクセス可能なオリジン。 1 5
移行が必要かどうかは、実際のチェーンに基づきます。証明書販売ブランドのみでフィルタリングすると、再販または相互署名関係が見逃される可能性があります。定期的な有効期限の更新を待っているだけでは、ルート ストアが更新される前に移行が完了するとは限りません。
影響を受けるルートに依存しない、CA によって発行された他の通常の Web サイト証明書については、このインシデントのために再署名する必要はありません。同時に、Web サイト サーバー自体は、外部サービスを呼び出すときにクライアント側の修復チェックを実行する必要があります。
7 修正が実際に有効になっていることを確認する
バージョンチェックと動作チェックは別々に実行されます
バージョン チェックは、パッチまたは修正されたコンポーネントが展開されていることを確認するために使用されます。動作チェックは、アプリケーションが予期された検証パスを実際に使用していることを確認するために使用されます。 2 つのチェックは異なる問題を解決しますが、どちらも「更新コマンドが正常に実行されました」に置き換えることはできません。
イベント管理者はテスト サイトと証明書チェーンの資料を提供し、入り口は付録に集中しています。 4 。通常の証明書検証構成を維持しながら、ターゲット アプリケーションの実際の動作環境で検証する必要があります。 4 7
| チェック結果 | 導き出される結論 |
|---|---|
| 影響を受けるチェーンは信頼できないため、明示的に拒否します | テスト中の検証パスがチェーンを拒否したことを示します |
| 影響を受けるチェーンを通常どおり受け入れます | このパスの修復を継続するか、構成をチェックする必要があることを示します。 |
| DNS エラー、接続タイムアウト、プロキシの拒否、またはサービス到達不能 | これに基づいて証明書のリスクが排除されたと結論付けることはできません。 |
| ブラウザは拒否しますが、アプリの呼び出しはチェックされません | 確認できるのはブラウザのみで、バックグラウンドプログラムは確認できません。 |
| A チェーンが拒否されました | クライアントが別の相互署名パスを受け入れるかどうかを検討する必要がある |
テストでは、信頼を削除しすぎてビジネス障害が発生した場合に、すべてのリクエストの失敗を修復の成功と誤認することを避けるために、通常のビジネス接続も対象にする必要があります。
推奨される完了条件
- 影響を受けるコンポーネントのアップデート ソースとバージョンが文書化されています。
- 対応する実行中のインスタンスが再起動、再構築、または再デプロイされました。
- 実際のアプリケーションは影響を受けるチェーンを拒否し、通常のビジネスのための TLS 検証は引き続き機能します。
- 接続を復元するために証明書の検証を一時的にオフにする構成はありません。
- Web サイト証明書の移行が関係する場合は、すべての外部入口が切り替えられ、検証されています。
上記の完了条件は、この処分の運用および保守の受け入れに関する提案です。それは、機器に他の安全上の問題がないことを証明することには相当しません。
8 過去の HTTPS トラフィックとリスク境界
用途が異なる3種類のキー
| キー | 主な目的 |
|---|---|
| CA 秘密鍵 | 証明書内の ID と公開キーのバインディングに署名します。 |
| ウェブサイトの秘密鍵 | 証明書認証済み TLS ハンドシェイクでサーバー ID を証明する |
| セッションキー | 接続上で実際に送信されるデータを保護する |
CA 秘密キーの取得は、Web サイトの秘密キーまたはすべてのセッション キーの取得と同等ではありません。 A 一時キー交換を使用した前方秘匿性を備えた通常の接続では、長期署名キーが後で侵害されるため、履歴セッションが自動的に公開されることはありません。 TLS 1.3 の関連セキュリティ属性については、RFC 8446 を参照してください。 16
今回の主なリスクは認証フェーズ中に発生します。クライアントが偽のサーバーの証明書を受け入れると、暗号化されたままの攻撃者との接続が確立される可能性があります。 TLS 1.3 には信頼できる認証も必要です。単にプロトコルのバージョンをアップグレードするだけでは、CA をブロックすることはできません。
現時点でできる判断とできない判断
確認済み： 特定の中間体 CA 秘密鍵が侵害される。影響を受けるパブリックトラストパスは広範囲に及んでいます。主要なプラットフォームといくつかのソフトウェアエコシステムが行動を起こしています。 1 4 5
このインシデントによって確立されていない: は、すべてのユーザーが中間者攻撃を経験していること、他の CA 秘密鍵が侵害されたこと、過去のすべての HTTPS トラフィックが復号化可能であること、または 1 つのブラウザーを更新するとデバイス上のすべてのアプリケーションが保護されること。
特定のサービスに関する最終的な判断は、アドレス バーに HTTPS が表示されるかどうかだけでなく、その証明書チェーン、検証ポリシー、実際に実行されているコンポーネント、更新ステータスに基づいて行う必要があります。
付録 A 影響を受ける中間 CA 名
次の名前は資産チェックに役立ちます。名前は、証明書のフィンガープリントや公開キー識別子を置き換えるものではありません。自動照合では、相互署名証明書を含む、インシデント管理者またはベンダーによって公開された正確な識別子を使用する必要があります。 5
| 中 CA | 目的 | 関連団体 |
|---|---|---|
| EM EV TLS CA - G3B | TLS | eMudhra BV |
| EM OV TLS CA - G3B | TLS | eMudhra BV |
| EM DV TLS CA - G3B | TLS | eMudhra BV |
| EM EV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV TLS CA - G3C | TLS | eMudhra Inc |
| EM DV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV CS CA - G3B | コードサイニング | eMudhra BV |
| EM OV CS CA - G3C | コードサイニング | eMudhra Inc |
TLS コード署名とまったく同じ検証および取り消しメカニズムではありません。この記事の焦点は、 HTTPS/TLS ;コード署名環境は採用する必要があります Microsoft , JDK または関連ソフトウェア ベンダーはこの検証を目的としており、ブラウザーのテスト結果はコード署名の受け入れとみなされるべきではありません。 5 15
付録 B 参考リンク
以下の情報源は、2026 年 10 月 22 日に確認されました。ローリング アナウンスは引き続き更新される可能性があり、本文内のステータスとバージョンは、このドキュメントの日付に基づいて理解される必要があります。
事件の事実とプラットフォームの対応
[ 1 ] Google Chrome そして Android 公式発表 秘密キーの欠陥、SPKI ブロック、Google Play サービス配布、CT 保護、および Chrome ルート リポジトリ削除計画について説明します。 Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
[ 2 ] Mozilla Bugzilla 2083449 イベント記録 オリジナルのレポート、独立した検証、生成プロセスの調査、Firefox Android に対するその後の修正、および法的な証明書の移行に関する議論が含まれています。コメント 5、11、29、30 に注目してください。 eMudhra Private key compromise of Intermediate Certificates
[ 3 ] Mozilla Firefox セキュリティに関する通知 OneCRL の緊急配布とその後の Firefox/NSS の廃棄についての説明。 Protecting Firefox users following the compromise of eMudhra intermediate certificates
[4] イベント コーディネーター Dennis Jackson メンテナンス概要および検出ポータル プラットフォームとソフトウェアの修復ステータス、テストの入り口、パブリック証明書チェーンの資料、Windows/macOS などの環境に関する補足説明を提供します。テスト結果は、テストされた実際の検証パスのみを表します。 eMudhra Intermediate CA Compromise
[ 5 ] Mozilla ディストリビューションおよびトラストストアのメンテナへの通知 6 つの TLS と 2 つのコード署名中間体 CA、Sectigo の相互署名、失効、およびルート信頼処理境界について説明し、正確な証明書と公開キーの識別をリストします。 oss-security eMudhra Intermediates Compromise
[ 6 ] eMudhra 公式イベント声明 鍵生成プロセスに関するメーカーの事前説明を提供します。正確な根本原因は、調査が完了するまでまだわかりません。 eMudhra Statement on Recent Certificate Security Incident
[ 7 ] Cloudflare 公式のインシデントと修理手順 WARP、Cloudflare Tunnel、オリジンサイトの検証、ランタイムの依存関係、イメージの更新、検証方法について説明します。 8 eMudhra certificates are compromised Here is what you need to know
オペレーティング システムとディストリビューション
[ 8 ] Ubuntu 公式修理発表 ca-certificates 修正パッケージ、サポート チャネル、および各バージョンの対象となる更新手順をリストします。 eMudhra CA compromise fixes available
[ 9 ] Debian 公式のトラブルと修理記録 メンテナの修正記録と対応するリリース パッケージは標準として採用されるべきであり、問題の議論における初期の一時的な提案は最終的な解決策とみなされるべきではありません。 Debian bug 1151413 eMudhra Intermediate CA key compromise
[ 10 ] Red Hat 公式安全情報 RHSB 2026 012 RHEL 6 から 10 まで、関連する製品とコンテナーの影響、および修正リリースと暫定廃棄エントリをリストします。 Certificate compromise eMudhra
[ 11 ] FreeBSD 公式セキュリティ情報 影響を受けるシステム ブランチ、修復バージョン、サービスの再起動要件を提供します。 FreeBSD SA 26 73 caroot
ランタイムとプロトコル
[ 12 ] Python 公式イベントの説明 pip、certifi、uv などの修復ベースラインを提供し、古い pip の独立したトラスト ストアの問題を説明し、SHA-256 検証による初期アップグレード方法を提供します。 Information for Python users regarding eMudhra emSign CA certificate security incident
[ 13 ] Node.js 24.22.1 正式リリース NSS ルート ストアの更新が含まれており、ブロックされた公開キー証明書チェーンを含む変更は拒否されます。 Node.js 24.22.1 security release
[ 14 ] Go 公式セキュリティリリース 説明 Go 1.27.3/1.26.10. の crypto/x509 証明書チェーン フィルタリング更新 Go 1.27.3 and Go 1.26.10 are released
[ 15 ] Oracle JDK 公式の廃棄指示 JDK の重要なパッチと、すぐにアップグレードできない場合の関連する構成措置を説明します。 Distrusting eMudhra Intermediate Certificates in Oracle JDK
[ 16 ] TLS 1.3 プロトコル規格 RFC 8446 ID 認証、一時キー交換、および前方秘密保持の手順については、付録 E.1 を参照してください。 The Transport Layer Security Protocol Version 1.3
[17] イベント関連のルート証明書と発行関係データ 直接発行者と相互署名関係を理解するために使用されます。ルート ストアの包含ステータスは、クライアントの最新の失効ステータスまたはブロック ステータスを置き換えることはできません。 Root certificate relationships JSON