【海外の反応】認証局eMudhraの秘密鍵流出、Web PKI全体が危機に
姉妹サイトの新着
デジタル証明書を発行する認証局(CA)の一つ、インドのeMudhraで、傘下のサブCAが使っていた中間証明書の秘密鍵が外部に漏れていたことが明らかになった。この鍵さえあれば理屈の上では、ほぼすべてのWebサイト向けのTLS証明書を偽造し、通信を盗み見る「中間者攻撃」が可能になる。Hacker Newsでは、GoやRust、Python、Electronなど主要な開発環境がすでに緊急の失効対応を済ませた一方、Android版Firefoxなど一部の環境では侵害された証明書への接続が依然ブロックされないという報告も相次ぎ、議論は「CAが1社でも暴走すれば世界中のhttps通信が危険にさらされる現在の仕組み自体が欠陥では」という、Web PKIの構造的な問題にまで発展した。
eMudhraの中間CA証明書が侵害されていた問題について
出典: emudhra.we-have-a-problem.com / 元記事はこちら
ネットの情報によると、流出した鍵は https://repository.emsign.com/certs/<redacted>.crt に置かれていたらしい。本当ならかなり笑えない話だ。IoT機器が大量にハッキングされる準備はできてるか?
>>3 まさかこんなに眩しい『一筋の光明』があるとは思わなかったけど、言われてみれば一理ある。
>>3 実際いい指摘だ。IoT機器の多くは何かに署名できるくらいには『セキュア』だけど、証明書ピンニングをわざわざ実装するほどセキュアじゃない……それに、秘密鍵をネットに公開したまま放置したことがない人なんていないだろ?(笑)
>>3 ソースは?本当ならとんでもない大失態だけど、まあ証明書が置いてありそうなURLではあるな。
Goを使ってる?1.27.3か1.26.10にアップグレードを。Rust+rustlsを使ってる?rustls-webpki 0.103.16か webpki-roots/webpki-root-certs 1.0.10に。Pythonは?certifiを2026.10.19に。Homebrewのca-certificatesは2026-09-25_1に。Electronは44.9.1、43.8.1、42.11.16のいずれかに。
>>4 GoとRustlsのアップグレードは特にこの中間証明書をブロックする内容だと思う。どちらもシステムの失効リストを使っていないからだ。CAのルート証明書が入っていないトラストストアにアップグレードすれば、それで解決するはず。他の言語のことはよく分からない。
>>4 Windowsを使ってる?Linuxにアップグレードしよう。
これはおそらく、既存ソフトウェアへの被害範囲が想像もつかないレベルになる。
eMudhraに何かお咎めはあるの?
>>6 このCAのこと聞いたことがなくて調べてみた。インドの上場企業らしい。市場はこれを織り込むだろうね。
このサービスが主にどこで使われているのか知りたい。軽くググった感じだと……インド政府関連のサイトや、確定申告などのサービスに関係してる?影響はインド国民がこうしたサービスを使う範囲に集中すると考えていい?
>>8 Webの仕組み上、CA(認証局)はほぼどんなWebサイト向けのTLS証明書でも発行できてしまう。つまりこの鍵を持っている人間は、このCAが発行した証明書に限らず、ほぼすべてのhttps通信を中間者攻撃(MITM)できる可能性があるということだ。
>>23 必ずしもそうとは限らない。X509のname constraintsを使えば『このCAが発行/発行禁止にできるSubjectはここまで』と制限できるし、DNSのCAAレコードという手もある。(もっとも前者は信頼されたルートCAを制限する目的というより組織内PKI向けの機能だけど、知っておく価値はある)
>>23 『どのCAもほぼどんなWebサイト向けの証明書でも作れてしまう』——これは昔からとんでもなく愚かな仕組みだった。
>>2 Pixel 7のAndroid 17でFirefox Mobile 158.0を使ってるけど、デモサイトに全部警告なしで繋がってしまう。『アップデートなしでも自動的に守られる』はずなのに、この組み合わせだとなぜ効かないんだろう?
>>10 同じ端末のベータ版アプリ(159.0b4)でも同じ現象が出てる。Chromeだと正しくブロックされるのに。
>>10 自分は同じFirefoxのAndroid版だけど、ちゃんとブロックされてるよ。
>>10 Pixel 10、Firefox 158.0.1だけど、emSignの証明書にまだ繋がってしまう……追記:Android設定でeMudhraのCAを全部無効にしても何も変わらない、参ったね。追記:CRLの更新を手動で要求する方法も無さそうで、参った。
>>2 つまり、あなたとChromeは通常のCRLやOCSPのサポートをやめて、代わりに(一般ユーザー向けには)ブラウザが管理する中央集権的なリストに置き換えた、ってことだよね。
>>2 『反応はまちまちだった』じゃなくて、影響範囲は文字通り『全員』が完全かつ丸ごと侵害されかねないものだった、が正しい。すべてのドメイン、公開ルートプログラムを使っているすべてのクライアント、そのクライアントの全ユーザーが対象だ。
>>2 Mozillaなんかに聞きたいんだけど。自前のCRLもどきを持ってるのは結構だけど、お前らこの間抜けどもをルートプログラムに受け入れたんだろ。鍵を紛失したんだぞ。HSM(ハードウェアセキュリティモジュール)すら使わないCAの審査基準って一体何なんだ?あの『Honest Achmed』のジョークCAですらここまで杜撰じゃなかったぞ。
>>14 審査は公開された場でやってるし、数週間のパブリックコメント期間中は誰でも意見を述べる権利がある。概要はこちら:wiki.mozilla.org/CA/Root_Inclusion_Overview
>>14 鍵を紛失したのはこのCA自身じゃなくて、傘下のサブCAだ。つまりサブCAという仕組み自体が、塞ぐべき巨大な抜け穴だということ。特にRFC5280の4.2.1.10節にあるname constraintsを使っているところなんて、ほぼ無いんじゃないか。
>>14 ついこの間まで、審査プロセスは『自分たちはいい子です』と自己申告するだけだった記憶がある。
>>7 『Web PKIをまともなシステムに置き換えるまで、あと何回これを読まされるんだ?』——まるで簡単な話みたいに言うけど、単に『やらない』という選択をしてるわけじゃないんだぞ。
>>7 『ドメイン所有権を階層的に委任する仕組みはすでにある』——そうだね。DANEが本来勝つべきだった。name constraintsもあればいいけど、誰がCAに使わせるんだ?あと頼むからクライアント側もたまにはCRLくらいチェックしてくれ。
>>22 DANEはこの仕組みを、暗号学的な性質はほぼ同じまま、悪質業者を排除できない——証明書の透明性ログで監視することすらできない——システムに置き換えるだけだ。今より明確に劣る。
>>22 DANEについてはここで散々議論されてきたから、もう付け加えることはあまりないと思う。ただ、少なくともブラウザはCAの失効には迅速に対応している。エンドエンティティ証明書の失効についても、程度の差はあれ対応していて、Firefoxは完全にカバーしているし、他のブラウザも部分的にはカバーしている。
>>8 インド企業で広く使われていて、電子署名サービスも提供してる。かなり普及しているプラットフォームだよ。
>>9 Web PKIは『各クライアントが自前のルート証明書を同梱しなければならない』なんて義務付けていない。挙げられたクライアントは全部、中央管理されたトラストストアを使うよう設定できる。デフォルトでそうなっていないのは、そのクライアントが意図的に選んだトレードオフであって、規格のせいじゃない。
>>25 じゃあなんで、あの巨大なパッケージマネージャーたちはOSのCAストアを使わずに、必要なら追加のストアを任意で設定できるようにしないんだ?パッケージマネージャーとCA側で更新のタイミングがそんなに違うのか?含まれるCAの顔ぶれがOSベンダーとそんなに違うのか?
他サイトの新着
>>9 『メールの世界では実は本当にイノベーションが起きている』……そのPKIまわりのイノベーションについて、もう少し詳しく教えてもらえる?
>>19 Linuxって、中間証明書を失効させる仕組みを一切提供してなくて、各証明書ライブラリが自前で失効処理を実装するしかない、あのLinuxのこと?Windowsは今日の時点で、ユーザーが何もアップグレードしなくても、侵害されたCAをすでにブロックしてるぞ。
>>34 どのプラットフォームで動かしていようと、証明書ライブラリは結局自前で失効処理を実装する必要がある。WindowsはシステムレベルでそれをやるAPIを提供しているだけで、アプリ側がサードパーティのTLSライブラリを同梱していたら意味がない。
>>45 Windowsでアプリがサードパーティの証明書検証ライブラリを使うのは珍しい。WindowsはそれをやってくれるAPIを提供しているから。Linuxでは選択肢がなくて、OSが提供するのはPEM証明書の束だけだから、自前でやるしかない。
>>33 審査プロセスが今の形になったのは2000年代後半あたりからで、もっと関与の度合いが強くなっている。20年を『つい最近』と呼ぶのは、Webの歴史の文脈ではちょっと違うと思う。
>>36 『今より明確に劣る』とは限らない。みんながname constraintsを実装して、CA/Bフォーラムがそれを義務付ければの話だけど。でも今の状態だと、制約のないサブCAはWeb PKIにとって害悪でしかない。
>>39 なぜ?特定の証明書プロバイダにサイトをピン留めするってどうやるんだ?乗り換えたくなったらどうする?
>>50 CAAも一つの方法だけど、証明書本体やその証明書チェーンをピン留めすることもできる(ただしこれはこれでデメリットがある)。
>>50 なぜなら、一番セキュリティの緩いCAと同レベルの安全性しか持てなくなるから。HSMすら使わないような本当にダメなCAに引っ張られる。
この話題の背景と論点
Web PKIは、ブラウザやOSがあらかじめ「信頼する認証局(ルートCA)」のリストを持ち、そこから鎖状に発行された証明書を検証する仕組みで成り立っている。問題は、理屈上どのCAも世界中のどのドメイン向けの証明書でも発行できてしまう点で、今回のように傘下のサブCAが秘密鍵を流出させただけで、発行元と無関係なサイトへの攻撃が理論上可能になる。スレッドでは「DANEのようなDNSベースの仕組みに置き換えるべきだ」という意見と、「DANEには証明書透明性ログのような不正監視の仕組みがなく、むしろ改悪になる」という反論が対立し、決着はついていない。また、同じ侵害証明書でもOSやブラウザ、パッケージ管理ツールによって失効の反映速度にばらつきがある点も、一見地味だが実害に直結する論点として挙がっていた。
※本記事は海外掲示板 Hacker News のスレッド「EMudhra Intermediate CA Compromise」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。