証明書の世界では、見た目が正しくても中身が壊れていることがあります。今回の話は、認証局 eMudhra の中間証明書の秘密鍵が、実質的に 8 ビットぶんしか強度を持っていなかった、というかなり衝撃的な発見です。しかもそれは理論上の心配ではなく、公開されている証明書から数ミリ秒で復元できたと報告されています。ブラウザ側はすでに遮断に動いていますが、問題は Web ブラウザの外にどれだけ広がるのか、という点にあります。
元記事で扱っているのは、認証局 eMudhra の中間証明書に使われていた秘密鍵が、あまりにも弱かったという話です。2026年10月17日、あるセキュリティ研究者が Apple、Google、Microsoft、Mozilla、そして eMudhra に対し、eMudhra の 8 つの中間証明書の秘密鍵が侵害されていると報告しました。その日のうちに Chrome は CRLSet でそれらをブロックし、Mozilla も数時間後には OneCRL で遮断しました。10月20日には Mozilla が公表し、NSS の更新で eMudhra の root を外しました。Chrome も、Chrome Root Store v43 でその root を外す予定だと確認しています。
問題の 8 つは、TLS 用の中間 CA が 6 個、コード署名用の CA が 2 個です。いずれも 2025年4月に作成され、同年5月には Sectigo の AAA Certificate Services root にもクロス署名されていました。ここで本質的なのは「誰かが鍵を盗んだ」のではない、という点です。記事によれば、秘密鍵の値は P-384 曲線の本来あるべき大きな乱数ではなく、4、56、115 といった極端に小さい数でした。P-384 の秘密鍵は本来 384 ビットの乱数であるべきですが、実際には 47 バイトがゼロで、最後の 1 バイトだけが値を持つような状態だったのです。つまり探索範囲は 256 通りしかなく、公開鍵から秘密鍵を求める作業は「1×G、2×G、3×G……」と順に試せばよく、最大でも 255 回で終わります。著者は公開された証明書をもとに、16 個ぶんの鍵のうち 8 個の秘密鍵をラップトップで一瞬にして復元したと書いています。
一覧にされていた値もかなり具体的です。EM DV TLS CA - G3B は 156、EM DV TLS CA - G3C は 230、EM EV TLS CA - G3B は 115、EM EV TLS CA - G3C は 56、EM OV TLS CA - G3B は 155、EM OV TLS CA - G3C は 4、EM OV CS CA - G3B は 66、EM OV CS CA - G3C は 237 でした。見た目上はどれも正しい曲線上の公開鍵で、形式も問題なく、構造チェックも通ります。だからこそ、弱さは外からは分かりません。検証して初めて気づくタイプの事故です。
記事が特に強調しているのは、この問題が「封じ込められない」ことです。通常、CA の秘密鍵漏えいなら、誰かが盗んだ時点や流出経路をある程度想像できます。ところが今回は、証明書が存在した時点で鍵がほぼ公開情報だったのと同じです。2025年4月以来、誰でもその証明書を見れば、ミリ秒単位で秘密鍵を復元できた可能性がある。しかもその期間は 17 か月あり、実際に誰かが復元したかどうかを後から見分ける方法はありません。
ブラウザについては、事情は少しマシです。Chrome は Certificate Transparency を必須にしているため、これらの CA に連なる偽造 TLS 証明書が Chrome で既定信頼されることはなかった、と記事は説明します。Mozilla も Firefox でブロックし、Safari も CT を要求します。ただし、CT は「発見」には役立っても「防止」そのものではありませんし、そもそも多くの TLS クライアントは CT を見ません。curl、Python、Node、Go、Java、git、各種 package manager などは、ディスク上の CA バンドルを信頼し、失効確認を既定では行わず、CT も確認しません。だから eMudhra と Sectigo が中間証明書を revoke しただけでは不十分だ、というのが著者の主張です。
実際、著者はローカルサーバーを立て、api.stripe.com を名乗る証明書で試験しています。デフォルト設定の curl は SSL certificate verify ok と返し、Python はハンドシェイクを完了し、Node でも authorized: true でした。Linux と macOS で同様だったといいます。Windows では CryptoAPI がチェーンを受け入れ、失効チェックを有効にしても片方の経路しか revoked と判定されなかったそうです。だから、ネットワーク上で中間者攻撃が成立する状況なら、任意のホスト名を入れた証明書で通信を偽装できる、という警告につながっています。
この話でいちばんぞっとするのは、「Chrome が守ってくれるなら大丈夫」とは到底言えない点です。Web の議論はついブラウザ中心になりがちですが、実際に TLS を使っているのはブラウザだけではありません。むしろ、サーバー同士の通信、CI/CD、開発ツール、パッケージマネージャー、IoT 製品の更新処理のほうが、証明書の検証を雑に済ませていることが多い。そこに弱い CA が混ざると、被害は「ブラウザの警告を見逃した」では終わりません。コードの取得、更新、署名、秘密情報の送受信まで巻き込まれる。元記事が curl、Python、Node、Go、Java を並べたのは大げさではないと思います。現実に動いているソフトの大半が、その棚に載っているからです。
認証局の事故が起きると、しばしば「もう revoke したから大丈夫」という空気が出ます。でも今回の記事は、それがブラウザ以外ではあまり効かないことを丁寧に示しています。失効確認を既定でしないクライアントは多いし、CA バンドルも更新されなければ古い信頼が残ります。しかも組み込み機器や OT、家電のように更新が難しいものは、そもそも更新されないまま何年も動き続ける。記事の最後で 2039年まで trust が残ると触れているのは、誇張ではなく、更新できない世界の怖さをそのまま言っているのだと思います。PKI の問題は「証明書が壊れた」だけでは済まず、「壊れた信頼をどこまで配れたか」に変わります。
更新情報では、Mozilla の incident ticket 公開後、eMudhra 側が経緯を説明しています。どうやら ceremony 用のスクリプトにバグがあり、HSM 上で別の弱い鍵ペアが作られ、名前が似ていたために人為的ミスで CSR に誤った鍵が使われた、という説明です。事実として、これは暗号の理論破りではなく、運用ミスがそのまま 8 ビットの信頼に落ちた例です。ここが厄介で、強い暗号を採用しても、手順が雑なら意味がない。逆に言うと、攻撃者が高度でなくても、手作業と自動化の境目で事故は起きる。しかも今回は、証明書の外観だけでは異常が見えない。だからこそ、CA の監査や ceremony の検証は「形式的に通したか」では足りず、実際に生成物をサンプリングして確認するくらいの執念が必要なのだと思います。暗号は強いのに、運用は驚くほど脆い。その落差がこの事件のいちばんの教訓でしょう。
参考: Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds
