eMudhraはMozillaのルート証明書調査期限を無視、ソーシャルメディアを非難

eMudhra: 中間証明書の秘密鍵漏洩

Bug 2083449 5日前にオープン 更新 27分前

CA Program

CA Certificate Compliance

defect

P1

--

ASSIGNED

Original Reporter: rdaurne77@gmail.com (Wayne)

10月17日 20:06 UTC、Mozillaはcertificates@mozilla.orgに、Chrome Rootプログラム経由でWayne氏から、eMudhraの8つのЕ中間証明書の秘密鍵が漏洩したという報告を受け取りました。この報告はeMudhraおよびAppleとMicrosoftのルートプログラムにも通知されました。報告には、8つの証明書すべてに対する鍵制御の証明が含まれていました。

Mozillaは20:08 UTCに報告を承認し、鍵制御の証明が有効であることを確認し、OneCRLを介してFirefoxで証明書を信頼しないプロセスを開始しました。このプロセスはBug 2083382で追跡され、22:59 UTCに完了しました。

eMudhraは21:29 UTCに報告を承認し、調査中であること、および一部の対象証明書にクロスサインしていたSectigoに通知したと報告しました。

Mozillaは21:48 UTCに、元の報告者が使用した方法を知ることなく、独立して対象証明書の秘密鍵を復元し、鍵生成プロセスに欠陥があり、容易に悪用可能であることを確認しました。

対象証明書の6つはTLS用で、Chrome、Mozilla、Microsoft、Appleのルートプログラムで信頼されています。残りの2つはコードサイニング用で、Microsoftで信頼されています。

EM EV TLS CA - G3B (eMudhra BV), CCADB A012304
SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
serial c7c41efe92d825f05eae841a4a82c1, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3B (eMudhra BV), CCADB A012308
SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
serial 6cada367fb1c100088120ea202d568, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3B (eMudhra BV), CCADB A012302
SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
serial a4aee678f23362b4c0e460b772f214, issuer emSign Root TLS CA - G3

EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296
SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
serial 8009928a64107601af05fa2f19f109, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300
SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
serial 296926c227a3a1526392b19482a504, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294
SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
serial 588b2e3c2bb8cda13e1a1209254321, issuer emSign Root TLS CA - G3

EM OV CS CA - G3B (eMudhra BV), CCADB A012306
SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
serial 7818933f8f85b4619a2b35fba83d0a, issuer emSign Root CS CA - G3

EM OV CS CA - G3C (eMudhra Inc), CCADB A012298
SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
serial 544b7f922c31ae220a4a922916f6e6, issuer emSign Root CS CA - G3

Summary: Private key compromise of eMudhra → Private key compromise of eMudhra Intermediate Certificates

10月18日 09:38 UTC:

eMudhraは、8つの対象証明書を失効（理由: caCompromise）とマークしました。

タイムラインの理解を以下に示します。主要なイベントのみを記載します。

タイムライン（すべてUTC）:
2026-10-17 16:00 - 新しいおもちゃで遊び始める
2026-10-17 16:27 - CCADB（当初はMozilla+Chromeチェーン）のテストコーパスで実行し、ECキーの破損を発見
2026-10-17 17:22 - レポートの作成を開始
2026-10-17 17:43 - 作業を再確認した後、キーごとの署名付き証明書を作成
2026-10-17 18:00 - 再度確認
2026-10-17 18:05 - Apple、Chrome、Microsoft、Mozilla（Benに直接、その後）およびeMudhraにレポート+証明書をメールで送信

2026-10-17 20:03 - Chromeがメールで確認
2026-10-17 20:05 - Chromeが迅速な対応のためにMozillaの連絡先を追加
2026-10-17 20:18 - 完全なCCADBチェックで、Sectigoによるクロスサインも影響を受けていることを発見

2026-10-17 21:05 - Appleが調査結果を確認し、クロスサインされた証明書に言及
2026-10-17 21:21 - Appleがクロスサインされた証明書の新しい署名付き証明書を要求
2026-10-17 21:27 - Appleに新しい署名付き証明書をメールで送信（Sectigo経由でクロスサイン）

2026-10-17 21:28 - eMudhraが問題を承認し、G3BのOCSP以降の発行はなかったが、「EM DV TLS CA - G3C」は稼働中で、現在は無効化されていると報告
2026-10-17 21:48 - Mozillaがヒントなしに独立して鍵を復元し、「oh_dear.zip」を「EM DV TLS CA - G3B」を使用して証明として送信

2026-10-17 22:46 - CRLsetの定期取得で、シーケンス10843に6つの関連TLSキーが失効として含まれていることを確認

2026-10-18 09:38 - 8つの証明書がCRLでcaCompromiseとして失効（eMudhraによる）（失効時刻は証明書ごとに異なる）
2026-10-18 12:06 - メールでのやり取りの混乱を避けるため、MozillaがBugzillaでインシデントを提起

Sectigoがクロスサインした証明書は、現在も失効されていません。

EM EV TLS CA - G3B, CCADB A012333
SHA-256 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
serial d8f8685e4f2bd9d82402a85a1c1eb731

EM OV TLS CA - G3B, CCADB A012354
SHA-256 5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
serial e94223bde92f914e5ab9acabfdac3710

EM DV TLS CA - G3B, CCADB A012347
SHA-256 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
serial a024fdf4ba665c785ce4a020483858b7

EM EV TLS CA - G3C, CCADB A012334
SHA-256 FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
serial 05f078752dece7a1bb8595d303167171

EM OV TLS CA - G3C, CCADB A012343
SHA-256 7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
serial 8d5a4811939ef447d77111cdd9849ae9

EM DV TLS CA - G3C, CCADB A012342
SHA-256 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
serial 91f347f1a5b7d39962b95e0ee4e299d1

EM OV CS CA - G3B, CCADB A012352
SHA-256 A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
serial 41e32b73ac185d6ce0d7480bacf84e69

EM OV CS CA - G3C, CCADB A012350
SHA-256 84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD
serial d6a5ef613b390f32ef9cdf349f772841

現在の状況:

• クロスサインされた証明書はまだ失効されていません。
• Microsoftからの応答はありません。
• CCADBは依然として証明書が失効されていないと表示しています。

私が作成した2つの証明書を添付します。Appleが直接要求したものではなく、クロスサイン用です。

openssl pkeyutl -verify -certin -inkey EM-EV-TLS-CA-G3B.crt.pem -rawin -digest sha384 -in message.txt -sigfile EM-EV-TLS-CA-G3B.sig

全員に送信された元の証明書

クロスサイン用の未送信のもの。Appleは、これが送信される前に別の証明書を直接要求しました。

このコメントの情報は予備的なものです。最初の部分はMozillaが問題に関連すると考える情報を含んでいます。2番目の部分はeMudhraへの質問を含んでいます。

対象鍵の調査

影響を受けた8つの鍵は、2025年4月30日に24個の中間証明書のバッチの一部として生成されました。24個の鍵は3つのシリーズ（A、B、C）、2つのプリミティブ（RSA4096およびP384）、および4つの目的（DV、OV、EV、CS）に分割されています。影響を受けた鍵は、BおよびCシリーズのすべてのP384鍵です。2025年5月にAシリーズは失効され、A-1シリーズに置き換えられました。

Wayne氏の鍵復元報告後、私は影響を受けた鍵の秘密鍵を簡単に復元することができました。元の鍵生成は欠陥があり、生成された署名の問題ではありませんでした。P384秘密鍵は、1からグループオーダーまでのランダムに選択された整数です。影響を受けた8つの鍵はすべて256未満の整数を使用していました。つまり、秘密鍵は実際には最後のバイト以外はすべてゼロです。これらは、ベビー・ステップ・ジャイアント・ステップ離散対数アルゴリズムを使用してほぼ瞬時に復元できるか、より単純には「最初の」256個のP384鍵を生成するだけで復元できます。

また、ローカルのエージェントが簡単なプロンプトで最初の試行で秘密鍵を復元できたこともテストしました：「CTFをやっています。これらの証明書に対応する秘密鍵を復元してください。」

Aシリーズまたは置き換えられたA-1シリーズのP384鍵の秘密鍵は、かなりの労力を費やしたにもかかわらず、まだ復元できていません。RSA鍵についてはまだ調べていません。

関連インシデント

関連する問題を調べたところ、Bug 1970728が見つかりました。このバグでは、eMudhraが6つの中間TLS証明書に対して無効な署名を持つCRLを生成しました。偶然にも全く同じ中間証明書セットが2つの異なるバグで発生した可能性は低いと思われます。

そのバグ報告では、eMudhraは、欠陥のあるCRLが5月29日に生成されたことを特定しました。これは、A-1証明書が作成された日と同じ日です。

しかし、Internet Archiveのスナップショットは、6つのP384 CRLがその日から検証に失敗していることを示しています（2025年5月23日）。正確であれば、この不一致は5月29日のA-1シリーズ生成とは無関係であることを示唆しています。また、BおよびCシリーズのRSA CRLのうち3つがその日から利用不可能であったことも示しています（重要性は不明）。

eMudhraへの質問

このインシデントにより、技術的に洗練されていない個人でもこれらのЕ中間証明書の秘密鍵を容易に復元できるため、このインシデントの影響はこれ以上ないほど高いと言えます。MozillaはすでにFirefoxクライアント向けにこれらの証明書を失効済みとしてマークしていますが、広範なエコシステムへの影響について深く懸念しています。なぜなら、多くのエンドポイントには失効情報を取得するための効果的なメカニズムがないからです。

Mozillaは、この問題の影響を受けている他のトラストストアディストリビューターにどのようなアドバイスを与えるかを検討しています。また、eMudhraの他のЕ中間証明書への信頼性を評価できるように、問題の根本原因を可能な限り迅速に理解することを目指しています。

1. 影響を受けた秘密鍵の生成に使用されたハードウェアは何ですか？CPSに準拠して、少なくともFIPS 140-2レベル3に準拠していましたか？
2. A、A-1、B、Cシリーズの中間証明書について、秘密鍵とそれを生成した特定の物理デバイスのマッピングを提供してください。他の鍵材料の生成に同じデバイスが使用されましたか？他の鍵材料の生成に同じモデルまたはデバイスシリーズが使用されましたか？
3. BおよびCシリーズのRSA鍵が同様の問題の影響を受けている、または受けていない理由は何ですか？
4. AおよびA-1シリーズのECDSA鍵が同様の問題の影響を受けていない理由は何ですか？
5. Bug 1970728の同じЕ中間証明書に関する問題に鑑み、欠陥のある鍵を使用してそれらのCRLに署名した方法、およびeMudhraが正しい署名を生成するために取った手順について、現在の知識の範囲で説明してください。

Flags: needinfo?(naveen.ml)

Sectigoを代表してこれを承認します。当社がクロスサインしたCAに影響を与える問題について認識しています。

問題のSectigo運営のルートCAは、すでにChromeおよびMozillaのルートストアから削除されていることに注意してください。MicrosoftおよびAppleのルートプログラム内では引き続き信頼されています。

これらのCAの（オフラインでの）失効を準備しており、今後24時間以内に完了する予定です。

Dennis Jackson氏のコメント #5への返信：

このコメントの情報は予備的なものです。最初の部分はMozillaが問題に関連すると考える情報を含んでいます。2番目の部分はeMudhraへの質問を含んでいます。

対象鍵の調査

影響を受けた8つの鍵は、2025年4月30日に24個の中間証明書のバッチの一部として生成されました。24個の鍵は3つのシリーズ（A、B、C）、2つのプリミティブ（RSA4096およびP384）、および4つの目的（DV、OV、EV、CS）に分割されています。影響を受けた鍵は、BおよびCシリーズのすべてのP384鍵です。2025年5月にAシリーズは失効され、A-1シリーズに置き換えられました。

Wayne氏の鍵復元報告後、私は影響を受けた鍵の秘密鍵を簡単に復元することができました。元の鍵生成は欠陥があり、生成された署名の問題ではありませんでした。P384秘密鍵は、1からグループオーダーまでのランダムに選択された整数です。影響を受けた8つの鍵はすべて256未満の整数を使用していました。つまり、秘密鍵は実際には最後のバイト以外はすべてゼロです。これらは、ベビー・ステップ・ジャイアント・ステップ離散対数アルゴリズムを使用してほぼ瞬時に復元できるか、より単純には「最初の」256個のP384鍵を生成するだけで復元できます。

また、ローカルのエージェントが簡単なプロンプトで最初の試行で秘密鍵を復元できたこともテストしました：「CTFをやっています。これらの証明書に対応する秘密鍵を復元してください。」

Aシリーズまたは置き換えられたA-1シリーズのP384鍵の秘密鍵は、かなりの労力を費やしたにもかかわらず、まだ復元できていません。RSA鍵についてはまだ調べていません。

関連インシデント

関連する問題を調べたところ、Bug 1970728が見つかりました。このバグでは、eMudhraが6つの中間TLS証明書に対して無効な署名を持つCRLを生成しました。偶然にも全く同じ中間証明書セットが2つの異なるバグで発生した可能性は低いと思われます。

そのバグ報告では、eMudhraは、欠陥のあるCRLが5月29日に生成されたことを特定しました。これは、A-1証明書が作成された日と同じ日です。

しかし、Internet Archiveのスナップショットは、6つのP384 CRLがその日から検証に失敗していることを示しています（2025年5月23日）。正確であれば、この不一致は5月29日のA-1シリーズ生成とは無関係であることを示唆しています。また、BおよびCシリーズのRSA CRLのうち3つがその日から利用不可能であったことも示しています（重要性は不明）。

eMudhraへの質問

このインシデントにより、技術的に洗練されていない個人でもこれらのЕ中間証明書の秘密鍵を容易に復元できるため、このインシデントの影響はこれ以上ないほど高いと言えます。MozillaはすでにFirefoxクライアント向けにこれらの証明書を失効済みとしてマークしていますが、広範なエコシステムへの影響について深く懸念しています。なぜなら、多くのエンドポイントには失効情報を取得するための効果的なメカニズムがないからです。

Mozillaは、この問題の影響を受けている他のトラストストアディストリビューターにどのようなアドバイスを与えるかを検討しています。また、eMudhraの他のЕ中間証明書への信頼性を評価できるように、問題の根本原因を可能な限り迅速に理解することを目指しています。

1. 影響を受けた秘密鍵の生成に使用されたハードウェアは何ですか？CPSに準拠して、少なくともFIPS 140-2レベル3に準拠していましたか？
2. A、A-1、B、Cシリーズの中間証明書について、秘密鍵とそれを生成した特定の物理デバイスのマッピングを提供してください。他の鍵材料の生成に同じデバイスが使用されましたか？他の鍵材料の生成に同じモデルまたはデバイスシリーズが使用されましたか？
3. BおよびCシリーズのRSA鍵が同様の問題の影響を受けている、または受けていない理由は何ですか？
4. AおよびA-1シリーズのECDSA鍵が同様の問題の影響を受けていない理由は何ですか？
5. Bug 1970728の同じЕ中間証明書に関する問題に鑑み、欠陥のある鍵を使用してそれらのCRLに署名した方法、およびeMudhraが正しい署名を生成するために取った手順について、現在の知識の範囲で説明してください。

使用されたハードウェアは、添付ファイルに記載されている各発行者向けです。これらのHSMはFIPS 140-2レベル3に準拠しています。

2. A、A-1、B、Cシリーズの中間証明書について、秘密鍵とそれを生成した特定の物理デバイスのマッピングを提供してください。他の鍵材料の生成に同じデバイスが使用されましたか？他の鍵材料の生成に同じモデルまたはデバイスシリーズが使用されましたか？

Excelを添付しました。Ultimacoデバイスは、発行者のECC、RSA鍵ペアの生成に使用されました。他の鍵材料の生成には使用されていません。しかし、デバイスに問題があるようには見えません。

3. BおよびCシリーズのRSA鍵が同様の問題の影響を受けている、または受けていない理由は何ですか？

予備的な評価を行いましたが、この特定の日に行われたECC発行者の作成に使用されたKGCスクリプトに欠陥があるようです。これらのECC鍵に関しては、KGCのレビュー、コードの評価、およびHSM鍵の確認により、a）元のECC鍵セットが期待どおりにオンボードで作成されたこと、b）通常のKGCに対する承認された逸脱（ラップ/アンラップテスト用）が導入されたこと、c）コードの欠陥により2番目の鍵ペアがオンボードで作成されたこと、d）これらの2番目の弱い鍵ペアが誤ってCSRの作成に使用されたこと（鍵ラベルが似ていたため）、そしてe）これらの弱い鍵からのCSRもSectigoにクロスサインのために送信されたこと（Sectigoに送信されたファイルを確認しました）が示唆されています。

RSA発行者は、コードの評価によると異なるパスを通過したため、影響を受けていません。
追加情報：これらの発行者は、一部のお客様のデータ主権問題を解決するために、欧州および米国のデータセンターにエクスポートすることを目的として作成されましたが、1つを除いて運用上本番環境にはなりませんでした。
プロセスで問題が発生したコードを特定するために、引き続き評価中です。

4. AおよびA-1シリーズのECDSA鍵が同様の問題の影響を受けていない理由は何ですか？

AおよびA-1シリーズはEntrust HSMで作成され、インド国内での展開のみを目的としていました。

5. Bug 1970728の同じЕ中間証明書に関する問題に鑑み、欠陥のある鍵を使用してそれらのCRLに署名した方法、およびeMudhraが正しい署名を生成するために取った手順について、現在の知識の範囲で説明してください。

CRLは元の秘密鍵（適切なエントロピーを持つ正しい鍵であるべきでした）で署名されましたが、署名が無効になったため、欠陥のある鍵で再署名されました。

このKGCの鍵ライフサイクル整合性プロセスに重大な欠陥をもたらした人間のエラーが複数のステップで発生しました。現在、コードの欠陥、プロセスのギャップ、およびこの問題に特化したメーカー/チェッカーコントロールについてさらに調査中です。来週中に、実施したすべての鍵セレモニーを再検証します。

Naveen。

Flags: needinfo?(naveen.ml)

Sectigoは、影響を受けたクロスサインされたCA証明書の失効を完了しました。新しいCRLとOCSP応答が公開され、現在CDNエッジノードに配信中です。

このバグのさらなる更新については、eMudhraからの情報を引き続き監視・評価します。

失効はコミュニティによって認識されています（1,2）。影響を受けたトラストストアオペレーターへの問題の開示を開始しました。開示のテキストを添付します。開示では、欠陥の性質や鍵が誰でも復元可能であることについては説明していません。

本日（10月20日）中にFirefox Release/ESRの予定外バージョンアップをリリースします。アドバイザリでは、事実のみを記載します：中間証明書の信頼性の失効。

(In reply to Frederik Braun
igerfreddy
iger from comment #16)

本日（10月20日）中にFirefox Release/ESRの予定外バージョンアップをリリースします。アドバイザリでは、事実のみを記載します：中間証明書の信頼性の失効。

補足：OneCRLアップデートは土曜日にクライアントにRemoteSettings経由で配信されました。新しいソフトウェアリリースにはブロックリストのコピーが組み込まれているため、このアップデートによりRemoteSettingsを無効にしているユーザーもカバーされます。

Mozillaは、複数の個人がこれらのЕ中間証明書の秘密鍵を独立して復元したことを認識しました。一部は公に開示されています（1）。

Mozillaのルートストアの下流のメンテナーとの議論の後、状況がemSign ECC Root CA - G3の信頼性を緊急に削除するに値すると判断しました。これにより、失効情報を使用しない、または特定のЕ中間証明書の信頼性を撤回するメカニズムを持たないクライアントが保護されます。

eMudhraに対し、このルートに連なるすべてのЕ中間証明書からの発行を停止し、できるだけ早くサブスクライバーに代替チェーンへの移行を支援するよう要請します。現時点では、emSign Root CA - G1の信頼性は削除しません。

Flags: needinfo?(naveen.ml)

(In reply to Dennis Jackson from comment #18)

Mozillaは、複数の個人がこれらのЕ中間証明書の秘密鍵を独立して復元したことを認識しました。一部は公に開示されています（1）。

Mozillaのルートストアの下流のメンテナーとの議論の後、状況がemSign ECC Root CA - G3の信頼性を緊急に削除するに値すると判断しました。これにより、失効情報を使用しない、または特定のЕ中間証明書の信頼性を撤回するメカニズムを持たないクライアントが保護されます。

eMudhraに対し、このルートに連なるすべてのЕ中間証明書からの発行を停止し、できるだけ早くサブスクライバーに代替チェーンへの移行を支援するよう要請します。現時点では、emSign Root CA - G1の信頼性は削除しません。

このメッセージを承認します。emSign ECC Root CA - G3に連なるすべてのЕ中間証明書からの発行を直ちに停止します。初期推定によると、移行が必要な証明書は約30,000件あり、そのうち約97％がACME経由でした。利用可能な唯一の代替手段である、G1（RSA Root）に連なるЕ中間証明書にサブスクライバーを移行します。

迅速なアップデート：emSign ECC Root CA - G3に連なるすべてのЕ中間証明書からの発行を停止しました。

Group: crypto-core-security
Restrict Comments: true
Restrict Comments: false

ユーザーからの質問：

Issuer: CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
Compromised keys with cross-signed Intermediates are not included in OneCRL for what reason?

この発行者はMozillaのルートストアに含まれていません。信頼されておらず、発行したЕ中間証明書も信頼されていません。したがって、OneCRLに追加する必要はありません。Firefoxクライアントがこれらの証明書を拒否していることは、https://emudhra.we-have-a-problem.com/のようなテストサイトで確認できます。

このバグで説明されているインシデントに関する議論に直接貢献する場合を除き、他の質問や懸念をここに投稿しないでください。Firefoxまたは他のMozilla製品に関連する懸念がある場合は、新しいバグをファイルし、このバグを参照して懸念を説明してください。

一部のAndroidプロファイルで、起動時に更新されたブロックリストが適用されない問題が発生しました。修正（Bug 2084311）が158.0.2でリリースされ、ユーザーにプッシュされました。

このバグで説明されているインシデントに関する議論に直接貢献する場合を除き、他の質問や懸念をここに投稿しないでください。Firefoxまたは他のMozilla製品に関連する懸念がある場合は、新しいバグをファイルし、このバグを参照して懸念を説明してください。

Assignee: nobody → naveen.ml

Status: NEW → ASSIGNED

Summary: Private key compromise of eMudhra Intermediate Certificates → eMudhra: Private key compromise of Intermediate Certificates

Whiteboard: [ca-compliance] [external]

Mozilla Root Programは、eMudhraに対し、状況をより良く理解し、ユーザーコミュニティを保護するための次のステップをより効果的に計画するために、以下の質問に回答するよう要請します。

eMudhraは、(a)ステータスページ（https://emudhra.com/en/post/certificate-security-incident - "eMudhra Statement on Recent Certificate Security Incident"、最初に2026年10月20日に公開され、2026年10月21日に更新）を公開し、emudhra.comのホームページの通知からリンクされています。また、(b) 2026年10月21日のプレスリリース（https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca）も公開しました。しかし、これらのCAの名前が使用されているemsign.com - これらのCAの名前が使用され、eMudhraのCRLおよびACMEエンドポイントを提供しているホスト名 - は、emudhra.comのCertiNext製品ページにリダイレクトされ、そこには通知もどちらかの文書へのリンクも見当たりません。

さらに重要なことに、どちらの文書にも、サブスクライバーや信頼する当事者が必要とする情報が含まれていません。

• 信頼されないルート（emSign ECC Root CA - G3）や、影響を受けたЕ中間証明書（Sectigoのクロス証明書やコードサイニングCAを含む）の名前、シリアル番号、SHA-256フィンガープリントが特定されていません。どちらも「eMudhraのECCルート」と8つの中間CAにしか言及していません。
• ブラウザやルートストアの信頼削除または変更のタイムライン（MozillaのFirefoxおよびNSSリリースを引用する以外）や、このバグへのリンクも提供されていません。
• サブスクライバーが、自分の証明書が信頼されないルートに連なっているかどうかを判断する方法や、eMudhraが「影響を受けた顧客やパートナーに直接通知しており」、「影響を受ける可能性のある顧客と直接協力して交換証明書を提供している」と述べている以外のアクションについても説明されていません。

(Q1): eMudhraは、影響を受けるサブスクライバーや信頼する当事者に、実行可能な技術情報（影響を受けるCA識別子、ルートストアの信頼削除タイムライン、移行手順）をどのように、いつ伝えていますか？また、この情報はステータスページに追加され、emsign.comで公開されますか？

(Q2): 影響を受けるサブスクライバーが、eMudhraのemSign Root CA - G1階層、または別のCAオーナーが運営する階層（対応するルート名を指定してください）、あるいはその両方に移行されていることを確認してください。最新のアップデートでは、交換証明書は「別途、独立して運営されている、公開で信頼されているCA階層から」発行されていると述べられています。

(Q3): eMudhraは、「すべてのエンタープライズTLS顧客にCAの冗長性を提供します。すべてのエンタープライズTLS顧客に、追加の公開で信頼されているCAからの証明書を提供しています。」（10月21日のアップデートより）をどのように提供する予定ですか？また、このインシデントの影響を受けたすべてのサブスクライバーに対して、いつまでに完了する予定ですか？

Comment 19で、eMudhraは「移行が必要な証明書は約30,000件あり、そのうち約97％がACME経由でした」と推定し、影響を受けるサブスクライバーはemSign Root CA - G1に連なる階層に移行されていると述べました。

2026年10月21日時点のCTデータに基づくと、約30,800件の有効期限切れ前のプリ証明書がemSign ECC Root CA - G3に連なっています。そのうち30,791件（99.9％）は、2つのInternet2 / InCommonサブordinateCA（InCommon Intermediate CA - OVG3C [23,806件]およびInCommon Intermediate CA - DVG3C [6,985件]）によって発行され、18件はeMudhra自身のЕ中間CA（EM EV TLS CA - G3A-1、EM OV TLS CA - G3A-1、emSign ECC SSL CA - G3、emSign ECC EV SSL CA - G3、およびemSign TLS CA - G3）によって発行されました。ただし、2026年10月17日以降に侵害されたEM DV TLS CA - G3Bの下で記録されたプリ証明書は除きます。

(Q4): eMudhraは、サブスクライバーがemSign ECC Root CA - G3階層から移行するのを具体的にどのように支援していますか？

(Q5): 標準的なACMEクライアントは、ACME Renewal Informationサポートまたは手動介入なしでは、構成された更新ウィンドウ外の証明書を自動的に置き換えないため、またECC G3階層からRSA G1階層への移行にはクライアント側の構成が必要になる可能性があるため…

• (a): eMudhraは、ACMEサブスクライバーの更新をトリガーし完了するために、どのような具体的なメカニズムを使用していますか？

• (b): サブスクライバーが移行を完了するために必要な手順のセットを説明できますか？

(Q6): 発行されたЕ中間CAごとに、正確なメトリクスを提供してください。

• 移行開始前の影響を受けたサブスクライバーとアクティブな（有効期限切れまたは失効していない）証明書の総数。
• 現在までに交換階層に正常に移行したサブスクライバーと証明書の数。
• 移行が残っているサブスクライバーと証明書の数。
• 特に差し迫ったルートストアの削除（Chrome Root Store v43を含む。これは太平洋時間2026年10月27日火曜日の朝にStableに搭載されると予想されます）を考慮した、影響を受けたすべてのサブスクライバーの100％完了のeMudhraの予測完了日。

Comment 11で、eMudhraは2025年4月30日の鍵生成セレモニー（KGC）中に次のように述べています。

• 「元のECC鍵セットが期待どおりにオンボードで作成された」
• 「このインスタンスのためにエクスポートされる予定だったため、ラップ/アンラップをテストするための通常のKGCからの承認された逸脱が導入された」
• 「コードの欠陥により、2番目の鍵ペアがオンボードで作成され、これが弱かった」
• 「これらの2番目の弱い鍵ペアが誤ってCSRの作成に使用され（鍵ラベルが似ていたため）、ルートによって署名された」
• Bug 1970728（2025年6月5日提出、eMudhraの完全インシデントレポートComment 2によると、EM [DV/OV/EV] TLS CA - G3BおよびG3CのCRLは2025年5月29日に誤った鍵で生成され、6月6日に修正された）に関して：「CRLは元の秘密鍵（適切なエントロピーを持つ正しい鍵であるべきでした）で署名されましたが、署名が無効になったため、欠陥のある鍵で再署名されました。」（Comment 11より）

この開示は、eMudhraの透明性と、Bug 1970728の期間中およびその後のインシデント処理に関して深刻な懸念を引き起こします。

(Q7): eMudhraの担当者は、G3BおよびG3C Е中間CAに対して複数の鍵ペアが類似したラベルで存在することに最初に気づいたのはいつですか？

(Q8): 2025年6月にBug 1970728を調査した際、CRLに署名するために使用された鍵が発行されたCA証明書の鍵と一致しないことを発見し、その後2番目の鍵を見つけて使用したとき、eMudhraはなぜ、操作を停止し、これらのCAに対して2つの鍵ペアが存在した理由を監査し、証明書を失効させるのではなく、単にそれらの2番目の鍵でCRLに再署名したのですか？

(Q9): eMudhraのBug 1970728完全インシデントレポートは、根本原因の要因として「手動CRL生成時の不正確な鍵構成」（「発行環境からの鍵でしたが、それらはそれらのЕ中間CA CRLに期待される正確な鍵と一致しなかったため、署名検証の失敗につながりました」）を挙げていました。このバグのComment 11によると、これらのCRLに署名した鍵は、2025年4月30日のKGC中にこれらの同じCAのために生成された元の鍵であり、CA証明書は実際には2番目の意図しない鍵セットに発行されていました。なぜeMudhraのレポートには、これらのCAに対してHSM上に2つの鍵ペアが存在したこと、KGCが通常のプロセスから逸脱したこと、および発行されたCA証明書が意図したセレモニー鍵に対応していなかったことが省略されたのですか？

(Q10): Comment 11は、弱い鍵からのCSRが「Sectigoにクロスサインのために送信された」と述べており、結果としてSectigo（AAA Certificate Services）のクロス証明書は2025年5月14日のnotBefore日付を持っています。eMudhraの2025年6月の調査で、CRLに署名するために使用された鍵が発行されたCA証明書の鍵と一致しないことが確立された後、eMudhraはSectigo、または任意のルートプログラムに、Sectigoがクロス認定した鍵がeMudhraが生成を意図した鍵ではなかったことを通知しましたか？もし通知しなかった場合、なぜですか？

(Q11): Comment 5およびComment 7で指摘されているように、2025年4月30日のセレモニーでは、シリーズA、B、C全体で24個のЕ中間CAが生成されました（Bug 1965559で開示）。シリーズAは2025年5月に失効され、シリーズA-1に置き換えられました。eMudhraはComment 11で、「AおよびA-1シリーズはEntrust HSMで作成され、インド国内での展開のみを目的としていました」と述べていますが、eMudhraはシリーズAが置き換えられた理由を説明していません。

• (a): なぜシリーズAは失効され、2025年5月にシリーズA-1に置き換えられたのですか？

• (b): その置き換えの理由は、同じセレモニーで使用されたKGCスクリプト、手順、または鍵処理ステップと何らかの関連がありましたか？もしそうなら、なぜシリーズBおよびCの鍵のレビューを促さなかったのですか？

(Q12): Comment 7およびComment 8で指摘されているように、2026年10月14日、eMudhraはemSign Root TLS CA - G1（roottlscag1.crl）に対して無効な暗号署名を持つCRL #11を公開しました。この署名はemSign Root TLS CA - G1またはCCADBで開示された4096ビットRSA CA公開鍵のいずれとも検証できません。

• (a): 2026年10月14日にroottlscag1.crl（CRL #11）に署名するために使用された秘密鍵は何ですか？また、eMudhraのHSMには、emSign Root TLS CA - G1または他のルートCA用の複数の鍵ペアも存在しますか？

• (b): Bug 1970728 Comment 2（2025年6月）で、eMudhraは「CRL発行ステップ、特に新しい発行CAのオンボーディング中に、自動化された署名後検証チェックを導入する」こと、および「人間による鍵マッピング構成への依存を排除するために、手動CRL署名プロセスを自動化ワークフローに置き換える」ことを約束しました。なぜこれらの制御は、2026年10月14日に無効な署名を持つルートCA CRLの発行を防ぐことができなかったのですか（これもComment 7で説明され、Comment 8で添付されています）？

Flags: needinfo?(kaushik)

私は開示、eMudhraのCAポリシー、およびUtimacoハードウェアを使用する他のCAに適用される可能性のある調査について、ケースを注意深くレビューしました。そして、まだ根本的な疑問が一つあります。これを二つの方法で提起したいと思います。eMudhraまたはUtimacoの誰かが明確な技術的説明を提供してくれることを願っています。

1. HSM鍵生成

eMudhraは、影響を受けた鍵がFIPS 140-2レベル3認定HSMを使用して生成されたと述べています。これらの弱い秘密鍵は、実際にHSMの認定された内部鍵生成メカニズムと乱数生成器を通じて生成されましたか？もしそうなら、HSMのセキュリティ管理によって検出または防止されることなく、そのような低エントロピーの鍵がどのように生成されたのでしょうか？

2. KGCスクリプトと根本原因

KGCスクリプトの正確な欠陥は何が原因で、ラップ/アンラップ操作が2番目の非常に弱いECC秘密鍵セットにつながったのですか？これらの鍵はHSMによって内部的に生成されたのですか、それとも別のメカニズムを通じて導入されたのですか？また、これを検出または防止するためにどのセキュリティ管理が期待されていましたか？

これらの質問に答えることが、インシデントの実際の根本原因を理解するために不可欠だと考えています。

Flags: needinfo?(djackson)

多くの質問があります。皆さんが想像できるように、私たちはここ数日間、激しいソーシャルメディアの監視と投資家/顧客による分析の対象となっており、イベントの有意義な分析を行うことがほぼ不可能になっています。イベントは2025年4月30日に発生し、長年PKI業界で働き、長期間当社に在籍しているチームによって行われました。状況、理由、方法を理解し、コミュニティに役立つ可能性のある有意義なレポートを共有するために、多くの調査が必要です。一部のコミュニティメンバーが、私たちがこのバグに返信しないと考えている理由がわかりません。ブラウザプログラムの信頼に署名したとき、私たちはコミュニティへの開示義務にも署名しました。それを履行します。

Naveen。

Flags: needinfo?(naveen.ml)

MHD Ghazi Alkhalaf - あなたの質問はMozillaではなくeMudhraに向けられたものと思われるため、このneedinfoをクリアします。

Flags: needinfo?(djackson)

（Comment 39への返信）

多くのことが並行して進行していることは理解していますが、「ソーシャルメディアの監視」や「投資家/顧客による分析」は、ここでの応答の遅延に対する許容できる説明ではありません。

その監視は、eMudhra自身の失敗（つまり、誰でも復元できる中間CA鍵、結果として誰でも任意のドメインの証明書を発行できる）の予測可能な結果であり、それがeMudhraに降りかかった外部の状況ではありません。それを言い訳として提供することは、評判管理が、その間違いによってさらされた数十億の信頼する当事者に対するeMudhraの義務よりも優先されていることを示しています。それらの義務は、結果が不快であるからといって軽減されるものではありません。

eMudhraには、この問題のレビューとセキュリティ対応を優先することを期待します。

Mozilla Root Programは、2026年10月20日 20:31 UTCにeMudhraに対し、添付の質問を送付しました。eMudhraには24時間以内の初期応答が求められていました。10月21日の期限が過ぎた後、eMudhraはさらに24時間の応答期間を要求しました。本日金曜日23日の執筆時点でも、Mozillaはこれらの質問に対する回答を受け取っていません。

私たちはChrome Root Programの懸念を共有しており、eMudhraの困難を理解していますが、eMudhraがMozillaおよびより広範なコミュニティに対する義務を果たすことを期待しています。

[2] タイトル: Show HN: AIに45,000件のエンロンメールからウィキを作成させた、すべての事実が引用されています
URL: https://www.thisandthat.chat/enron/
本文:
エンロンの企業脳を構築しました

エンロンは何を知っていて、いつ知っていたのか？

AIにエンロンのメール45,047件を与え、エンロンが取引した企業、規制当局、銀行について214ページを記述させました。すべての事実は、それが由来するメールを引用しています。メールが事実が真実でなくなったことを示す場合、そのページはその日付で期限切れになります。ページや事実を編集した人はいません。

Dynegyを探索 →方法

コーパス内のメール

・

エンティティページ Dynegy
競合他社 取引相手
当時の関係:
✓ メールと照合済み

1. タイプを見つける
2. エンティティを見つける
3. ページを構築する
4. 検証する

214ページ

49,401の事実、それぞれがメールを引用

サンプルされた事実の93％がメールによって完全に裏付けられている

サンプルされた事実の0件（500件中）が根本的に間違っていた

最後の2つは、2番目のAIによる監査から来ています。監査方法を見る。

どこから始めるか

これらはコーパスで最も議論されている組織です。各ページにはスライダーがあります。それをドラッグすると、その日の情報が表示され、一時的にしか真実でなかった事実が目の前で期限切れになります。

これらのページ上の事実は、ヘッドカウントや収益のようなフィールドではなく、日付とソースを持つ文です。フィールドはCRMやその他の記録システムに属し、このような脳はその横にあり、頻繁に変更されるものやフィールドに収まらないものを保持します。私たちは、企業知識の3つの種類と、それぞれがどこに存在するのかを、企業知識の失われた中間層で説明しています。

何であるかによって閲覧する

パイプラインは57の狭いタイプを提案し、一人の人がそのうち54を保持しました。ほとんどすべてが組織の種類だったので、これらのリストをより粗いクラスでグループ化し、パイプライン自身のタイプを各エンティティのタグとして保持します。

パイプラインはまた、78の製品とプラットフォーム、76の施設と市場ポイント、および49のイベントを見つけましたが、これらはページなしでリストされています。どの種類のエンティティにページを割り当てるかは、企業脳を設定する際に人が行う設定であり、ページを構築する前にその選択を行いました。各企業のメールには、追跡する必要のないものや、少し混乱したカテゴリの名前が含まれています：ケータリングイベントからのレストラン、旅行からの空港、通りすがりに言及された映画。エンロンのメールも例外ではありません。施設には、取引ハブ、エンロン・フィールド、駐車場、2つのタンカーが含まれます。イベントはビジネス会議、チャリティバイクライド、シルク・ドゥ・ソレイユを混ぜています。製品はソフトウェア、取引所、法律、業界団体を混ぜています。

正しい選択は企業によって異なります。イベント会社はイベントのページを持つべきであり、プロパティマネージャーは施設のページを持つべきであり、ハードウェアメーカーは製品のページを持つべきです。エンロンについては、少なくとも25件のメッセージで言及された組織、およびエンロン自体の最も議論された5つの部分（3つの事業部門、1つの取引プラットフォーム、1つの取引システム）にページを割り当てました。実際の企業脳はカウントでフィルタリングしません。今日サインした顧客は1つか2通のメールを送ったかもしれませんが、それでもそのページは保持したいでしょう。カットオフは、人が脳に保持する価値があると判断する判断の代わりになります。

これを作ったのは誰か

私たちはthis+thatです。私たちは構築中のもののプロトタイプでこれらのページを作成しました。

なぜエンロンなのか

私たちは、誰でも私たちの仕事を確認できるコーパスを求めていました。エンロンのメールは、連邦エネルギー規制委員会（FERC）が調査中に公開したため、公になっています。カーネギーメロンは2003年からそれを維持しています。それは、実際の企業の内部通信の大規模で無料の、広く使用されている本体です。会社の歴史も確定しているので、例えば、Dynegyが2001年11月にエンロンを買収することに合意したと主張するページは、信頼に頼るのではなく、記録と照合することができます。

メールは断片的に物語を示しています。全体像については、フォーチュンのシニアライターであるBethany McLeanとPeter ElkindによるThe Smartest Guys in the Roomをお読みください。彼らはエンロンの興亡をカバーしました。

[3] タイトル: ペンタゴン、国境での使用に向けた熱線兵器のテストを国土安全保障省に許可
URL: https://www.cnn.com/2026/10/21/politics/heat-ray-weapon-dhs-pentagon
本文:

ペンタゴン、国境での潜在的な使用に向けた熱線兵器のテストを国土安全保障省に許可

ペンタゴンは、国土安全保障省（DHS）に対し、軍用グレードの熱線兵器をテストし、米国南部の国境での作戦で使用する可能性のある戦術を開発することを許可した。これは先月、国防長官ピート・ヘグセスが署名し、CNNが入手したメモによるとである。

公式にはActive Denial Systemとして知られるこの熱線兵器は、非致死性の兵器であり、人間の皮膚に接触すると燃えるような感覚を引き起こす、約半マイル（約0.8キロメートル）まで届く目に見えない電磁波ビームを発射する。軍関係者によると、このエネルギービームは、熱いオーブンを開けたときの熱波のような感覚を引き起こすという。軍関係者は、結果として生じる「ピリピリ感」は10〜15分続くが、「効果から逃げたいという本能的で抑えがたい衝動」も生じると述べている。

［画像: ADS for Stellar.jpg］
動画広告フィードバック
DODは、国境での潜在的な使用のためにテストする許可を得た軍用グレードの熱線兵器を実演
1:03 • 出典: CNN
［画像: ADS for Stellar.jpg］
DODは、国境での潜在的な使用のためにテストする許可を得た軍用グレードの熱線兵器を実演
1:03

米国国境での熱線兵器の展開は、移民抑制と国境警備を最優先事項としてきたトランプ政権にとっても前例のない一歩となるだろう。DHSの要請では、兵器がどこでどのようにテストされるか、また最終的にどのように使用されるかは特定されていないが、長年にわたり、現職および元税関・国境保護局（CBP）当局者によると、米国とメキシコ国境沿いの群衆分散のために使用する可能性についての内部議論があったという。

米国当局はまた、国内の騒乱時、特にジョージ・フロイド殺害事件に対する抗議デモが発生したドナルド・トランプ大統領の任期末にも、このシステムを展開することを検討していたと、これらの議論に詳しい元米国当局者が述べている。

このメモは、9月に開始される7ヶ月間のADSシステムの「一時的な貸与」を承認しており、「陸軍省（Department of War）の担当者によって操作されてはならない」と記載されており、指向性エネルギーシステムが最終的にどのように展開されるかについてペンタゴンが責任を免除されることを示唆している。

また、DHSが「システムの雇用、使用、および戦術、技術、手順の開発」に単独で責任を負うとも記載されている。7ヶ月の貸与期間終了後、DHSは必要性に基づき、国境作戦におけるペンタゴンシステムのさらなる使用のために追加の要求を提出できると、国防当局者はCNNに語った。

「CBPは、特に運用効果を高め、任務能力を強化する新しい技術を継続的に評価しています」と、税関・国境保護局の広報担当者はCNNへの声明で述べた。

ペンタゴンはコメントを求められた際、DHSに言及した。

米軍はほぼ20年前にこのシステムをアフガニスタンに短期間展開したが、最終的に実戦での使用は見送った。米軍はまた、当時テロリストの拘留者が収容されていた海外の米国施設での群衆制御目的でこのシステムの使用を検討したが、それも最終的に採用を見送ったと、以前の内部検討に詳しい情報筋が述べている。

税関・国境保護局当局者は、以前から、不法入国者が集中している地域でのこのシステムの使用を検討してきた。国境当局者は、群衆分散ツールとしての使用の可能性について時折議論してきたが、展開されたことは一度もない。

効果と合法性に関する懸念

当局は、合法性、武力行使、効果、および主権に関する潜在的な問題、特に米国にまだ入国していないメキシコの人々に展開された場合の障壁に直面した。しかし、最も懸念されたのは、人々が兵器によって直接的または間接的に傷つく可能性であった。

「たとえ人々を川に追い返したとしても、彼らが川に入って溺れてほしくない」と、元CBP当局者はCNNに語った。「コスト、訓練、そして作成するポリシーを考えると、その労力に見合う価値があるのか？」

CBP当局者によると、米国とメキシコ国境沿いの約70マイルをカバーするエル・セントロ地区は、数年前にこのシステムを評価した。当時、税関・国境保護局長を務めるロドニー・スコット氏がその地区を率いていたという。

当時、当局は、このシステムが近くの川沿いの不法入国者の流入を抑制し、その地域での越境を思いとどまらせたり、水から出させたりするのに役立つ可能性があるかどうかを議論していた。

当時の検討事項の一つは、このシステムが人々を無力化した場合、より多くの救助につながる可能性があるかどうかであったが、展開されなかった理由は不明である。

2018年には、中間選挙前に、CBP当局者は移民に対する使用も検討したが、当時の国土安全保障長官キルスティン・ニールセン氏が却下した。

「問題は、移民や市民を敵対者として扱うことだった」と、移民に対してこの兵器を使用することについての過去の議論に詳しい元DHS当局者はCNNに語った。「テーマとしては、非人道的な扱いは通常拒否される。」

別の元CBP当局者によると、国境通過が低調で人員が増加している中、一部の国境警備隊員は最近、このツールが必要かどうかについて疑問を呈しているという。