【広告】Amazonで商品を探す（このリンクはAmazonアソシエイトを利用しています）

eMudhraの中間CA証明書危殆化インシデントまとめ：原因、各エコシステムの対応、TLS事業からの撤退表明

eMudhraの中間CA証明書危殆化インシデントまとめ

（※本記事は2026年10月24日時点の情報に基づきます。）

2026年10月、インドの認証局（CA）であるeMudhraの中間CA証明書において、秘密鍵が極めて脆弱な状態にある深刻なインシデントが発覚した。本記事では、一次情報（Mozilla Bugzilla Bug 2083449、Chrome Root Program、eMudhra公式発表等）に基づき、インシデントの経緯、原因、エコシステムおよびeMudhraの対応を時系列で解説する。

時系列で見るインシデントの経緯

前日譚：2025年4月30日〜2025年6月

  • 2025年4月30日：eMudhraのパブリック信頼インフラストラクチャにおける鍵生成セレモニー（Key Generation Ceremony: KGC）にて24件の中間CA証明書が作成され、その中に本インシデントの影響を受ける8件の中間CAが含まれていた。
  • 2025年5月〜6月（Bug 1970728）：うち6件のTLS中間CAにおいて、発行されたCRLの署名検証が失敗する問題が発生。eMudhra側の説明によれば、当初は本来の（強い）鍵でCRLを署名したものの、証明書の公開鍵と一致せず検証に失敗したため、不具合により生成されていた弱い方の鍵で署名し直したとされる（※この経緯は2025年6月当時の報告では省かれており、Chrome Root Program等から詳細が問われている）。この異常が見過ごされたまま（※2回の監査通過はeMudhraの主張であり、監査対象範囲に入っていたかはコミュニティからの質問に対して未回答）、約17.5か月にわたり運用が継続された。

2026年10月17日（土）

  • 18:05 UTC：Chrome Root Programが、セキュリティ研究者から「eMudhraの下位CA証明書8件に関連する秘密鍵が暗号学的に脆弱である」という報告を受信。
  • 19:45 UTC：Chrome側が調査結果の裏付けを完了し、影響を受ける6件のTLS発行用中間CAのSubject Public Key Info (SPKI) ハッシュをブロックするCRLSetを迅速に配信。ブラウザの再起動なしで即座に保護を適用。
  • 20:06 UTC（公式記録上）：Mozillaが certificates@mozilla.org 経由（Chrome Root Programからの転送等）で同様の報告を受領（※報告者のタイムラインでは18:05 UTCにMozilla担当者へ直接メールしたとも主張されている）。
  • 21:48 UTC：Mozilla側でも独自に鍵の復元・検証を完了。
  • 22:59 UTC：MozillaがOneCRLを用いて、影響を受けた証明書をFirefox上でブロックする配信を完了。

2026年10月18日（日）〜19日（月）

  • 10月18日：MozillaがBugzillaにインシデント（Bug 2083449）を起票（12:06 UTC）。
  • 10月18日 09:24〜09:38 UTC：eMudhraが該当する8件の中間CA証明書を失効（Revoke）処理（報告から約15.5時間後、eMudhraの受領確認からは約12時間後）。
  • 10月19日頃：Appleが該当証明書のブロックを実施（※技術系報道に基づく）。また、Sectigoによるクロス署名証明書の失効処理も完了。

2026年10月20日（火）

  • MozillaおよびChrome Root Programにより、dev-security-policy（MDSP）等で公式な議論・状況共有が行われた。
  • Chrome Root Programが「emSign ECC Root CA – G3」を Chrome Root Store から削除済みとし、全デバイスへの反映は10月27日（火）朝（PDT）の見込みと発表。
  • MozillaがNSS 3.131.1を配信し、影響を受けるルート証明書（emSign ECC Root CA – G3）の信頼取り消しを実施（G1 RSAルートは現時点で削除対象外）。また、OneCRLの更新を設定等で受け取れない利用者向けに、最新のブロックリストを組み込んだFirefox 158.0.1等の臨時リリースも順次配信。
  • Microsoftが該当証明書のブロックを実施（※技術系報道に基づく）。
  • eMudhra公式声明（Update 1 & 2）：調査開始を公表。ルート鍵への影響を否定し、エンドエンティティ証明書の発行履歴がないことを表明。

2026年10月21日（水）〜22日（木）

  • 10月21日（Update 3）：eMudhraがインシデントに関するステートメントを更新。鍵生成セレモニー時の鍵ラップ／アンラップ手順の不具合が原因である旨を説明。
  • 10月22日（Update 4）：eMudhraが全顧客向けにSectigo発行の証明書を代替選択肢として提供する方針を発表（既存のG1 RSAルートは引き続き有効維持）。
  • 10月22日 プレスリリース発表：eMudhra取締役会が、グローバルSSL/TLS証明書事業からの自主撤退（Exit）を正式決定。同社のプレスリリースにおいて、移行期間中はパートナー経由で費用負担なし（無償）に代替証明書へ置換する旨が説明された。

インシデントの根本原因と技術的背景

今回のインシデントの核心は、秘密鍵の盗難ではなく、「生成されたECDSA（P-384）秘密鍵が極めて小さく、暗号学的に脆弱であった」点にある。

  • 脆弱な鍵の実態（P-384 ECC）： 対象となった8件の中間CA証明書はいずれもP-384曲線を用いたECC鍵であり、その秘密鍵（スカラー値）は 4, 56, 66, 115, 155, 156, 230, 237 という、いずれも256未満（1バイト以内）のきわめて小さな整数であった。そのため、Baby-step Giant-step法や先頭256個の鍵候補の生成により、計算コストをかけることなく即座に復元が可能な状態となっていた。
  • 影響を受けた8件の中間CAの内訳： 2025年4月30日のKGCで作成された24件の中間CAのうち8件が影響を受けた。この8件のうち、6件はTLS用（WebPKI）の中間CAであり、残り2件はMicrosoftの信頼ストア等に関連するコードサイニング用中間CA（emSign Root CS CA - G3 配下）であった。
  • Certificate Transparency（CT）による保護と失効確認の課題： Chromeの公式ブログによると、ブロック前にこれら6件の中間CAに連なるTLS証明書はCTログに記録されていなかったため、CTを強制するクライアント環境では偽造証明書は信頼されなかった。一方で技術系の解説（Aikidoのブログ等）によると、サーバー、CI、Dockerイメージ、curlやgitなど、失効情報（Revocation）を自ら検証しないクライアント環境では失効の効果が及ばないため、該当ソフトウェアの更新が必要となる。
  • 発生原因に関するeMudhraの説明と未確定事項： eMudhra側の説明によれば、鍵生成自体はFIPS 140-2 Level 3仕様（※コミュニティからはCMVP検証済みか等で質疑が継続中）のHSM上で行われたものの、通常手順から逸脱した鍵のラップ／アンラップ（key wrap/unwrap）テストの際にコード不具合が発生し、本来の強い鍵ペアとは別に脆弱な「第2の鍵ペア」がオンボードで生成されたとされる。ラベルが酷似していたために誤ってその弱い鍵ペアでCSRが作成され、ルートに署名されたと説明している。ただし、正確な根本原因調査は2026年10月下旬時点でも完了しておらず、公式には未確定とされている。
  • 長期的な潜伏： 2025年4月の作成以降、約17.5か月にわたり潜在し続けた。

eMudhraの公式発表とグローバルSSL/TLS事業からの撤退決定

2026年10月22日、eMudhra Limitedは取締役会決議に基づき、グローバルSSL/TLS証明書事業からの自主撤退（Exit）を正式発表した。

撤退の理由と背景

  • 収益比率とROI低下：グローバルSSL/TLS事業は同社全体収益の約1%にとどまる小規模事業であり、データ主権やコンプライアンス対応コストが増大する一方で、無料TLS証明書の普及によりROIが大幅に低下していた。
  • 過剰な注目と精査：SNS等を中心にインシデントに関する拡散と過剰な精査が行われたことを受け、事業規模とのバランスを考慮した結果、撤退が会社および株主にとって最適であると判断された。
  • コア事業への影響について：eMudhraの主張によれば、パブリックSSL/TLS以外の事業（エンタープライズPKIソリューション emCA・CertiNext、電子署名 emSigner、ID・認証ソリューション SecurePass、インド国内等の電子署名証明書 DSC など）は分離された別インフラで運用されており、一切影響を受けず正常稼働を継続するとしている。ただし、これらは同社の主張に基づくものである。Chrome Root ProgramはeMudhraの残りのCA証明書を信頼ストアに残すかどうかについて継続評価中である点、またMozillaはG1 RSAルートを現時点では維持しているもののeMudhraに対する質問への回答待ちである点に留意が必要である。

顧客および信頼ストアへの対応

  • 代替証明書の提供：Update 4に基づきSectigo発行の証明書が代替選択肢として提示され、プレスリリースにおいて移行期間中はパートナー経由で費用負担なし（無償）で置換されることが示された。また、移行期間中の顧客サポートのため既存のG1 RSAルートは維持される。
  • インフラの継続運用：発行済み証明書がすべて失効または置換されるまで、失効情報（CRL）およびOCSP等の検証サービスは維持される。

各ブラウザベンダーおよびエコシステムの対応まとめ

  • Chrome Root Program：
    • 発覚直後の10月17日 19:45 UTCにSPKIベースのCRLSetを適用し、即座にブロック。
    • 10月20日に「emSign ECC Root CA – G3」のChrome Root Storeからの削除を発表（10月27日朝PDTに全デバイス反映予定）。残りのCA証明書の扱いについても継続評価中。
  • Mozilla (Firefox)：
    • 10月17日 22:59 UTCにOneCRLを配信。
    • NSS 3.131.1で影響を受けるECCルート（emSign ECC Root CA – G3）を削除（G1 RSAルートは現時点で信頼を維持しつつ、質問への回答を要請中）。設定等でOneCRLを受信できない利用者向けにはFirefox 158.0.1等で対応。
  • Apple / Microsoft：
    • それぞれ10月19日、10月20日にOS/ブラウザレベルでのブロック措置を実施（※技術系報道に基づく）。
  • 再発防止策に関する議論：
    • コミュニティ内では、証明書署名要求時にセキュアなハードウェア内での鍵生成を証明する draft-ietf-lamps-csr-attestation（Internet-Draft）をはじめとする鍵アテスト（Key Attestation）技術の活用や、KGC手順のさらなる厳格化・自動検証の必要性が議論されている。
タイトルとURLをコピーしました