認証局（CA）のeMudhraは、最近発生した証明書のセキュリティインシデントを調査した結果、証明書の生成過程で秘密鍵が不適切に扱われていたことが判明したとして、中間CA証明書をさらに8件失効させました。
今回の失効により、影響を受けた中間CA証明書は合計16件となりました。このなかには、秘密鍵が極めて脆弱で、誰でもほぼ瞬時に復元できる状態だった、先に侵害が判明した8件も含まれます。
eMudhraは火曜日に公開した新たなインシデントレポートで、2つの証明書グループはいずれも、2025年4月にハードウェアセキュリティモジュール（HSM）間で秘密鍵を移行する際に使用したカスタムPythonスクリプトの影響を受けたと説明しています。
HSMは、暗号鍵を安全に生成・保管するための機器で、機密性の高い秘密鍵がハードウェアの外部に露出するのを防ぎます。
eMudhraによると、このスクリプトは、新しいハードウェアの調達が遅れたため、自社施設内で異なるHSMベンダー間の認証局鍵を移行する目的で開発したものです。
しかし、スクリプトにはバグがあり、8件のECDSA秘密鍵が1バイトにまで縮小されていました。そのため、鍵の復元は極めて容易になっていました。
同じスクリプトは8件のRSA秘密鍵も処理しました。この際、機密性の高い鍵情報は、HSM内で保護されたままではなく、スクリプトを実行したコンピュータのメモリ上で扱われていました。
RSA鍵はECDSA鍵のように脆弱化されたわけではありません。しかしeMudhraは、同社の証明書セキュリティポリシーに沿って鍵を扱ったことを示せないとしています。
インシデントレポートには、次のように記されています。「ホストプロセスのメモリから再インポートを行う手順は、CPS §6.2.6と整合しません。そのため、RSAオブジェクトはこの要件を満たさないものとして扱います」
これを受け、同社は11月7日、TLS証明書やコード署名証明書の発行に使われていたものを含め、追加のRSA中間CA証明書8件を失効させました。
影響を受けたRSA中間CAの一部は、2026年5月から実際に証明書を発行しており、最後の発行は11月3日でした。
eMudhraは、影響を受けた顧客の証明書についても、すでに交換または移行を済ませたとしています。
調査では、2025年6月に起きた過去の問題が、「Wayne」と名乗るセキュリティ研究者が欠陥を発見する1年以上前に、不具合の発覚につながり得たこともわかりました。
当時、eMudhraは、対応するCA証明書と一致しない秘密鍵で署名された証明書失効リスト（CRL）を検出していました。
同社は、一致する鍵で失効リストに署名し直して問題を解消しましたが、なぜ問題が起きたのかは調べませんでした。
新たなレポートは、これが、2026年10月まで発覚しなかった鍵生成プロセスの欠陥を示す早期の警告だったと認めています。
さらに調査では、eMudhraが生成した秘密鍵の強度を検証していなかったことも判明しました。認証に使用する鍵が、HSMで最初に作成された鍵と一致するかどうかの確認も行っていませんでした。
主要ブラウザは侵害された証明書をブロック
BleepingComputerが以前報じたとおり、このインシデントは10月17日に初めて公表されました。Wayneというセキュリティ研究者が、eMudhraの中間CA秘密鍵8件が、わずか256通りの値を試すだけで復元できることを発見したのです。
主要なブラウザやOSは、侵害された証明書を信頼していました。そのため、攻撃者が正規のWebサイトになりすました証明書を偽造し、暗号化通信を傍受できた可能性があります。
その後、Mozilla、Google、Appleをはじめとするソフトウェアベンダーは、侵害された証明書をブロックする保護策を公開しました。
Microsoftも10月26日、証明書の信頼を自動更新で受け取れないシステム向けに、影響を受けたeMudhraの証明書チェーンの信頼を解除するWindowsの定例外アップデートを公開しました。
インシデントを受け、eMudhraは、公的に信頼されるTLS証明書事業から撤退し、残る顧客を別の事業者へ移行すると発表しました。
同社は、残るG1階層での証明書発行を11月16日までに停止する予定です。
eMudhraはまた、KPMGに独立レビューを依頼しました。結果は12月4日までに出る見込みで、証明書管理と鍵生成手順の改善点を洗い出すとしています。
同社は、侵害された鍵が悪用された形跡は確認されていないとしています。
