eMudhra のインシデント

eMudhra のインシデントは、インドのルート認証局（Root CA）である eMudhra が、実質1バイトの強度しかない中間認証局の秘密鍵を作って使っていた事案である。原因はキーセレモニーの不備だった。鍵を逆算すれば、世界中のどのドメインの証明書でも、正規として検証されるものを作れる状態だった。事案が公表されたのは2026年10月である¹。

背景

HTTPS では、ブラウザや OS に入った認証局の証明書を起点に、サーバーの証明書がなりすましでないことを確かめる。認証局の秘密鍵は Hardware Security Module（HSM）の中で作られ、外に取り出せない。鍵を作る際には関係者が集まって手順を確かめるキーセレモニーを行い、運用が正しいかを WebTrust の監査で第三者が確かめる¹。

経緯

eMudhra のキーセレモニーでは、スクリプトのバグによって本来の鍵とは別にごく弱い鍵が作られ、取り違えによってそれが中間認証局の鍵に採用された¹。

P-384 の秘密鍵は本来ランダムな48バイトのはずだが、問題の8つの鍵は上位47バイトがすべて0で、値は4、56、66、115、155、156、230、237だった。256通りほど総当たりすれば逆算できる¹。

問題の中間認証局は Sectigo との相互署名（Cross Root）を受けていたため、eMudhra をブラウザの信頼から外すだけでは足りず、CRLSet や OneCRL のような失効の仕組みで個別に無効にする必要があった¹。

eMudhra は Mozilla の Bugzilla での議論に、SNS や投資家、顧客の詮索のせいで有意義な分析ができないと返信した。その後、発見から14時間以内に影響を受けた認証局を失効させたと述べたうえで、世界向けの SSL/TLS 証明書事業から撤退すると発表した¹。

影響

鍵を逆算した攻撃者は、空港の偽の無料 Wi-Fi のような中間者の立場から、どのサイトへの HTTPS 通信も警告なしに改ざんできる。Jxck は、ブラウザや OS は失効の仕組みで対応できても、Electron アプリや curl、プログラミング言語の HTTPS 実装のように独自の証明書の一覧を同梱するものは、個別に更新しなければならないと指摘した。暫定策として、仕事中の VPN の常用や、無料 Wi-Fi を避けることを挙げている¹。

評価

Jxck は、同じ時期の PHP2Shell と比べ物にならないほど深刻で、Web の信頼を失墜させる事態だと論じた。監査が杜撰なキーセレモニーを見逃したのなら、何のための監査なのかとも問うている¹。

Sloppedia の持ち主の masseater は、ブラウザベンダーが機械的に対応できるので大した問題ではないと考えている。

出典

1. Jxck「eMudhra のインシデントは Web にとって何を意味するのか」blog.jxck.io、2026年10月25日。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸