eMudhra CAキー脆弱性、大手ブラウザが対応済も一部アプリには注意

これまでの経緯

• eMudhraのCA秘密鍵が数ミリ秒でクラック、極端に脆弱な設計が明らかに

eMudhra中間CAキーが漏洩、大手ブラウザは迅速対応

2026年10月20日に公開された情報によると、インドの認証局eMudhraの中間CA証明書に紐づくプライベートキーが8件、漏洩したことが明らかになりました（Hacker News (API)）。これらのキーは、Mozilla、Microsoft、Apple、Chromeのルートプログラム、そして多くのダウンストリームトラストストアによって信頼されているルートに連鎖しています。

攻撃者は、漏洩した中間CAのプライベートキーを用いて、任意のウェブサイトやサービスを偽装することが可能です。

この問題は、Wayne氏によって発見され、10月17日にルートプログラムチームに報告されました。彼は、漏洩を証明するために、8つの中間CAそれぞれのプライベートキーで特定のメッセージに署名し、その証拠を提出しています。

各プラットフォームにおける対応状況

主要なプラットフォームは、この脆弱性に対して迅速な対策を講じています。各ベンダーの対応状況は以下の通りです。

Mozillaは、報告を受けてから3時間足らずでOneCRLによるブロックを完了させ、ユーザーがアップデートや再起動なしで保護されるようにしました（Lobsters）。これは非常に迅速な対応であり、評価に値すると感じます。

一部のアプリケーションやライブラリへの影響と注意点

主要なブラウザやOSベンダーが迅速な対応を行った一方で、すべてのクライアントが自動的に保護されるわけではない点に注意が必要です。特に、以下のクライアントは手動での対応が必要となる可能性があります。

• 独自のCAバンドルを同梱しているアプリケーションやライブラリ
• Electronベースのアプリケーション（SlackやDiscordなど）

これらのクライアントは、失効情報を消費しない、またはアップデートされない限り、依然として侵害された中間CAを信頼し続ける可能性があります。OSやブラウザのアップデートだけでは不十分なケースがあるため、開発者の方は自身のアプリケーションや利用しているライブラリについて確認が必要です。

多くの非ブラウザクライアント、特にcurlなどのコマンドラインツールはCertificate Transparency（CT）を強制しないため、より高いリスクに晒されています。

CTは証明書のログを公開することで、不正な証明書の発行を検知する仕組みですが、これを強制しないクライアントは、不正な証明書が発行されても検知が難しくなります。curlなどのツールで脆弱性を確認するには、特定のURLにアクセスし、証明書エラーが発生するかどうかで判断できます。

エンジニア目線の考察：サプライチェーンリスクとクライアントの対応設計

今回のeMudhra中間CAキー漏洩は、CAのサプライチェーン全体に潜在するリスクを改めて浮き彫りにした事例だと感じます。特に、クラウドインフラを多用し、様々なサードパーティ製サービスやライブラリを利用している開発者にとっては、CAの信頼性だけでなく、その失効メカニズムまでを考慮に入れる必要性があるのではないでしょうか。

私の個人プロダクトでも、API連携や外部サービスとの通信でHTTPSを利用していますが、今回のケースを考えると、クライアント側での証明書検証ロジックがどの程度強固であるか、また失効情報をどのように処理しているかを詳細に確認する必要があると感じます。特にElectronベースのデスクトップアプリや、自作のPythonスクリプトなどでrequestsライブラリなどを使っている場合、OSやブラウザが対応しても、アプリケーション自体が旧来の信頼ストアを参照し続けるリスクは無視できません。Claude Codeに投げて、各環境での証明書検証のベストプラクティスを調べつつ、既存のコードに脆弱性がないか確認してみたいと思います。

更新のサイクルが遅いアプリケーションでは、セキュリティパッチの適用が遅れることがそのままリスクに直結するため、CI/CDパイプラインに証明書失効リスト（CRL）やOCSPステープリングのチェックを組み込むことも検討すべきかもしれません。そうでなければ、意図しない中間者攻撃のリスクに晒され続けることになります。