2026年10月17日、Apple、Google、Microsoft、Mozilla、そして認証局（CA）であるeMudhraに対し、研究者から重大な脆弱性が同時に報告された。eMudhraが発行した中間CA証明書8枚の秘密鍵が、4、56、66、115、155、156、230、237という単なる1バイトの小さな整数値に設定されていたのである。
これらの証明書には楕円曲線暗号（P-384）が採用されていた。暗号仕様上、秘密鍵は本来384ビットの乱数であり、その取り得る値の空間は約3.9 × 10¹¹⁵に達し、総当たり探索は現実的に不可能とされている。しかし秘密鍵が「4」や「56」のような極小値である場合、攻撃者はベースポイント（生成元）の1倍、2倍……と最大255倍まで計算するだけで、秘密鍵を完全に特定できる。16枚の関連証明書に対応する8つの秘密鍵は、セキュリティ研究者のScott Helme氏によって一般的なノートPC上でわずか1秒未満で復元された。
形式上は完全に正当な証明書
この問題が自動監査をすり抜けた理由は、エントロピーが事実上ゼロであるにもかかわらず、構造上には一切の欠陥が存在しなかったことにある。P-384の基底点に4を掛け算して得られる公開鍵は、数学的に曲線上の完全な正規点であり、エンコードや曲線パラメータ、署名アルゴリズムの検証もすべてパスする。証明書チェーン、有効期間、拡張属性もすべて適正に構成されていた。
異常を検知するには、小さな整数を総当たりで突合するほかないが、主要なCA監査プロセスにそのような項目は存在しなかった。これが、極めて脆弱な証明書がインターネット上で17か月間ものあいだ誰にも気付かれずに稼働し続けた理由である。
8枚の中間CA証明書は2025年4月に発行され、6枚のTLS発行用CA（DV/OV/EVの各2世代）と2枚のコードサイニングCAで構成されていた。2025年5月にはSectigoのルート証明書「AAA Certificate Services」によるクロス署名が行われ、影響を受ける証明書は計16枚に拡大した。有効期限は2039年7月までとなっていた。
さらに不可解なのは、eMudhra側の公式説明である。同社は「秘密鍵は一貫してHSM（ハードウェアセキュリティモジュール）内で保管されていた」と主張している。仮にそれが事実だとすれば、HSMは単に「値が4の秘密鍵」を忠実に保護し続けていたにすぎない。ハードウェアのコンプライアンス適合と、鍵自体の品質・強度はまったく別の問題である。コミュニティの議論でも「秘密鍵がHSMに厳重に格納されていたがゆえに、誰も鍵の実体を確認することができず、乱数生成器が機能していなかった事実を見落としたのではないか」と皮肉交じりに指摘されている。
図：該当する認証局eMudhraのロゴ。8枚の中間証明書が17か月にわたり公開ネットワーク上で放置されていた。出典：Scott Helmeブログ、eMudhra公式サイト
秘密鍵「4」でStripeの証明書を発行、curlはあっさり受理
秘密鍵が実質的に公開されている以上、残る作業はなりすましと偽造だけである。
Scott Helme氏は秘密鍵4を用いてapi.stripe.com向けの証明書を作成し、ローカル環境でopenssl s_serverを起動したうえで、標準構成のクライアントから接続を試みた。結果は極めて深刻だった。LinuxおよびmacOSのcurlはSSL certificate verify okを返し、PythonのTLSハンドシェイクも正常に完了、Node.jsはauthorized: trueと判定した。WindowsのCryptoAPIも、リアルタイムの失効確認が無効化されている限り、何のエラーも出さずに証明書を受け入れた。
ここで明暗を分けたのは、トラストストア（信頼ストア）のアーキテクチャである。Webブラウザの信頼基盤は中央集権的であり、遠隔プッシュ配信による迅速な無効化が可能だ。Chromeは報告当日の10月17日夜にCRLSetへ対象証明書を追加してブロックし、Mozillaも数時間後にOneCRLで追従した。さらに10月20日にはMozillaが公式アナウンスを公開してNSSからeMudhraルートを削除、Chromeもルートストアv43で信頼を取り消した。また、ブラウザが義務付けているCertificate Transparency（CT）ログの検証により、これら脆弱な鍵を使った不正発行の痕跡がないことが確認され、一般ユーザーのWebブラウジングへの直接被害は回避された。
一方、CLIツール、バックエンドSDK、IoTデバイスはまったく異なる仕組みで動いている。それらの信頼ストアはソフトウェアにバンドルされた静的ファイルであり、デフォルトでは失効リスト（CRL/OCSP）を確認せず、CTログも一切参照しない。ブラウザ上ではすでに完全に失効したはずの証明書が、これらの環境では依然として正当な認証情報として通用し続けてしまう。
図：暗号化トラストチェーンの破綻点はアルゴリズムではなく、鍵生成プロセスそのものにあった。出典：Ars Technica
失効対応が届いたのはブラウザだけ
影響範囲を棚卸しすると、この問題が抱えるリスクの息の長さが浮き彫りになる。
curl | shによるインストールスクリプト（rustup、nvm、Homebrewなど）がHTTPS通信に依存している場合、経路上の攻撃者が配布元を偽装し、開発環境へ特権権限で悪意あるプログラムを送り込むことが可能になる。CI/CDパイプラインはさらに深刻だ。GitHub Actions、GitLab Runner、Jenkinsのコンテナにはクラウドアカウントの認証情報やデプロイシークレットが集約されているが、こうした環境のルート証明書が手動で更新されることは極めて稀である。決済API、Webhook、OAuth連携などのマイクロサービス間通信も、コンテナベースイメージに同梱されたCA証明書に依存しており、完全に攻撃射程に収まる。さらにWindowsのコードサイニング証明書が悪用された場合、失効チェックを行わない端末では悪意ある実行ファイルが正規の署名済みバイナリとして扱われてしまう。
暗号技術者のFilippo Valsorda氏は、今回の事後清掃に伴う負荷は「Heartbleedをも上回る」と指摘した。管理を放置されたLinuxサーバー、更新の止まったコンテナイメージ、古いCAバンドルを抱え込んだCLIツールが、極めて長期間にわたる負の遺産となるためだ。Ben Cartwright-Cox氏は「サンプルコードが誤って本番環境に混入したのではないか」と推測しつつ、1年半にわたって監査機構が一切検知できなかった異常さを批判した。Ian Carroll氏の表現を借りれば、「1バイトの鍵は誰にでも復元可能であり、一度流出した信頼を回収する手立ては存在しない」。
13年続く長期的な爪痕
運用サイドが現場で打てる対策は限られている。管理下にあるサーバーであれば、eMudhraのルート証明書を削除するか、中間証明書をブラックリストに登録するのが定石だ。OpenSSLを使用するシステムでは、OSの証明書ストアが最新化されているか確認する必要がある。しかし真の課題は、管理の及ばないシステムにある。家庭用ルーター、ネットワークカメラ、産業機器、車載システム、POS端末などは、トラストストアが出荷時にファームウェアへ固定されているケースが多い。メーカーが保守を終了していれば機器を買い替えるほかに対策がなく、この証明書が自然失効するのは2039年7月である。
プロダクト設計に携わる者にとって、本インシデントは重い教訓を突きつけている。ルート証明書を静的にハードコードすればネットワーク検証コストをわずかに削減できるが、引き換えに今後10年以上にわたって失効手段を失うことになる。「秘密鍵の中身を直接覗き見る者はいない」という前提に寄りかかったセキュリティモデルは、乱数生成器が正しく初期化されなかった、ある日の午後を境に脆くも崩れ去る。
参考文献：
- Scott Helme 技術ブログ
- We Have A Problem 事故レポート
- Ars Technica 詳細報道
- Mozilla 公式セキュリティブログ
- Hacker News コミュニティ議論
