実録編#13丨PHP祭りより深刻な「証明書祭り」——eMudhra秘密鍵問題とHTTPS信頼基盤の危機
PHP祭りの裏側で、インターネットの信頼基盤そのものを揺るがす事件が起きていました。 本エピソードでは、2026年10月に発覚したeMudhraの中間認証局（中間CA）秘密鍵問題を取り上げ、PHPの重大な脆弱性との違い、HTTPSの信頼構造、デジタル証明書の偽造リスク、そして第三者監査の限界について解説します。 取り上げる主なテーマ - PHP祭りとは何か - CVE-2026-109618・CVE-2026-109619 - eMudhra中間CA秘密鍵問題 - HTTPSとデジタル証明書 - ルートCAと中間CAの信頼構造 - 公開鍵・秘密鍵の仕組み - P-384楕円曲線暗号 - 秘密鍵の値が「4」だった問題 - 暗号鍵生成時の乱数品質 - TLS証明書とコード署名証明書 - 偽造証明書によるWebサイトのなりすまし - DNS・中間者攻撃 - 証明書透明性（CTログ） - ChromeのCRLSet - FirefoxのOneCRL - Sectigoによる交差署名 - API通信と証明書ストア - Python・Docker・Cloudflareへの影響 - HSMとFIPS 140-2認証 - 第三者監査と実装検証の限界 - 信頼の撤回とサイバーガバナンス PHPの重大な脆弱性は、攻撃者が未修正のサーバーで不正なコードを実行し、データを盗んだり、システムを乗っ取ったりする危険を生みます。 しかしeMudhraの問題は、異なる階層のリスクを突きつけました。 それは、インターネット上で「相手が本物である」と証明する仕組み自体が、偽造に利用できる状態になっていたことです。 今回問題となったのは、8件の中間CA証明書に対応する秘密鍵でした。 本来、極めて大きな乱数から生成されるべきP-384の秘密鍵が、すべて256未満という異常に小さな値になっていました。 そのうちの1つは、なんと「4」。 強力な暗号アルゴリズムを採用していても、鍵の生成過程に重大な欠陥があれば、安全性は失われます。 さらに恐ろしいのは、攻撃者が認証局のサーバーへ侵入する必要すらなかったことです。 公開証明書の情報から、秘密鍵を短時間で再現できる状態だったのです。 これにより、影響を受けた認証局を引き続き信頼するシステムでは、第三者が偽造した証明書を正規のものとして受け入れてしまう危険が生じました。 HTTPSは通信を暗号化します。 しかし、暗号化された通信の相手が本当に正しい相手なのかを確認できなければ、利用者は安全だと信じながら偽のサーバーへ情報を渡してしまう可能性があります。 今回、Google ChromeとMozilla Firefoxは緊急対応を実施しました。 証明書透明性、失効情報の配信、信頼ストアの更新など、複数の防御策が重要な役割を果たしています。 一方で、企業には別の課題があります。 ブラウザが保護されても、独自の証明書ストアを利用するAPI、業務アプリケーション、Dockerコンテナなどが同じ状態とは限りません。 OSをアップデートしただけで、すべての通信が安全になるわけではないのです。 そして、今回の事件が突きつけたもう1つの教訓があります。 認証されたハードウェアを使っていることと、そのハードウェアを通じて作られた成果物が安全であることは、同じではありません。 eMudhraは、FIPS 140-2 Level 3に適合するHSMを利用し、独立監査も受けていたと説明しています。 それでも、弱い秘密鍵の問題は見逃されました。 監査済みだから安全。 暗号化されているから安全。 有名な認証局だから安全。 こうした判断だけでは、十分ではありません。 重要なのは、何を信頼するかだけでなく、信頼の根拠が破綻したときに、その信頼をどれだけ迅速に撤回できるかです。 PHPの脆弱性とeMudhraの秘密鍵問題。 一方はサーバーの安全性、もう一方は通信相手の真正性を脅かす問題でした。 サイバーセキュリティは、侵入を防ぐことだけではありません。 私たちが何を根拠に、誰を信頼しているのか。 その信頼を、誰が検証し、誰が取り消せるのか。 インターネットの信頼基盤と、監査・認証・ガバナンスの本質を考えます。