eMudhra中間CA鍵8件が漏洩 — Go 1.27.3の緊急更新と「失効を見ないクライアント」の対処

はじめに

インドの認証局 eMudhra が運用する中間 CA 証明書 8 件の秘密鍵が漏洩しました。これらの中間 CA は Mozilla・Microsoft・Apple・Chrome が信頼するルートにつながっているため、鍵を持つ人は理論上どんなドメインの証明書でも発行でき、任意のサイトになりすませます。

ブラウザは報告から数時間でブロックを済ませました。一方で、Go 製のツールや Python・Node.js のアプリのように失効情報を確認しないクライアントは、ソフトウェアを更新するまで危険な中間 CA を信頼したままです。Go は 1.27.3 / 1.26.10 を緊急リリースしました。この記事では、何が起きたのか、なぜブラウザ以外が取り残されるのか、開発者が何をすればよいのかを整理します。

何が起きたのか

発端は 10 月 17 日、Wayne と名乗る研究者がルートプログラム各社へ送った報告です。8 件の中間 CA それぞれの秘密鍵で「We have a problem here - Wayne」というメッセージに署名し、鍵を実際に持っていることを証明しました。公開サイトには証明書・公開鍵・署名が置かれていて、誰でも OpenSSL で署名を検証できます（秘密鍵そのものは公開されていません）。

各社の対応は次のとおりです。

日時（UTC）	出来事
10/17 18:05	Chrome Root Program が報告を受領
10/17 19:45	Chrome が CRLSet でブロック
10/17 20:06	Mozilla が報告を受領
10/17 22:59	Firefox の OneCRL 配信が完了（受領から 3 時間弱）
10/19	Apple 製品がブロック開始。Go 1.27.3 / 1.26.10 リリース
10/20	Firefox 158.0.1・NSS 3.131.1 リリース、Microsoft がブロック、開示サイト公開

Chrome の説明では、8 件のうち 6 件が TLS 証明書を発行する中間 CA、2 件がコード署名用です。また、ブロック前の時点で 6 件の TLS 用中間 CA につながる証明書は Certificate Transparency（CT）のログに 1 件も記録されていなかったと報告しています。

鍵がどうやって流出したのか、研究者以外に鍵を持つ人がいるのかは、10 月 21 日時点で公表されていません。一部の海外メディアは「数秒で解読できる鍵だった」という見出しを付けましたが、その記事の本文でさえ「公開情報からはそうは言えない」と書いています。原因はまだ分かっていないと考えるのが正確です。

技術的な背景 — なぜブラウザ以外が取り残されるのか

中間 CA の鍵が漏れると何がまずいか

TLS の信頼は「ルート CA → 中間 CA → サーバー証明書」という鎖でできています。クライアントはルートだけを手元に持ち、中間 CA はサーバーが送ってくる鎖の中で検証します。中間 CA の鍵があれば、その中間 CA の名前で新しいサーバー証明書をいくらでも作れます。ルートを信頼している限り、クライアントはそれを正しい証明書として受け入れます。

ブラウザは「独自の失効リスト」で守っている

本来は CA が証明書を失効させ、クライアントが CRL や OCSP で確認すれば済みます。しかし実際には、失効確認は遅く失敗しやすいので、多くの実装は確認しないか、失敗しても通します。そこでブラウザ各社は、失効情報を自前でまとめて配っています。

Chrome の CRLSets：今回は公開鍵情報（SPKI）のハッシュでブロックしました。同じ鍵を使う Sectigo の相互署名（クロスサイン）証明書もまとめて止められます
Firefox の OneCRL：中間 CA 用の失効リストで、ブラウザの更新や再起動なしで届きます

加えて Chrome は CT ログへの記録を求めているので、ログに載っていない偽証明書はそもそも信頼しません。今回ブラウザの利用者に大きな実害が出にくかったのは、この二重の防御があったからです。

失効を見ないクライアントは「ルートの中身」がすべて

Go の crypto/x509、Python の certifi、Node.js の同梱ルート、Rust の webpki-roots などは、CRLSets も OneCRL も読みません。報道によれば、Go の検証器は失効確認自体をしません。こうしたクライアントは、中間 CA が失効していても、ルートが手元にある限り鎖を受け入れてしまいます。

そのため対処は「ルート証明書の一覧を更新する」か「問題の鍵を名指しでブロックする」のどちらかになります。Mozilla は NSS 3.131.1 で、問題の中間 CA に署名したルートを信頼リストから外しました。Go は公開鍵のハッシュで 8 件を拒否する変更を入れています。Cyber Kendra の報道では、この拒否は証明書全体ではなく公開鍵で照合するため相互署名版も止められ、macOS や Windows で OS に検証を任せる経路でも働き、無効にする設定はないとされています。

エンジニアへの影響と対処

自分のコードや配布物について、次の順で確認するのが確実です。

Go 製のバイナリは再ビルドする：Go のツールチェーンを 1.27.3 / 1.26.10 に上げただけでは、すでに配ったバイナリは古いままです。HTTPS クライアント・サーバー、社内 CLI、コンテナイメージを新しいバージョンでビルドし直して配り直します。Go 1.25 以前はサポート外で修正は出ません
言語ごとのルート束を上げる：開示サイトでは、修正版として Python certifi 2026.10.19、pip 26.2.2、uv 0.13.4、Rust rustls-webpki 0.103.16 / webpki-roots 1.0.10、Electron 44.9.1 / 43.8.1 / 42.11.16、Elixir castore 1.0.22 が挙がっています。ロックファイルで固定している場合は明示的に更新が必要です
OS とコンテナのベースイメージ：Ubuntu の ca-certificates、Homebrew、Arch、Gentoo、Chainguard は修正済みです。Debian・FreeBSD・Node.js・Bun・Composer の ca-bundle は 10/20 時点で未対応でした。Debian ベースのイメージを使っている場合は、更新が出たらイメージを作り直します
回避策は慎重に：開示サイトにはルートを手作業で外す手順も載っていますが、「一般ユーザーには推奨しない」と明記されています。自社の信頼ストアを管理しているチームが、修正版が出るまでの間に使うものと考えてください

なお、コード署名用の 2 件は Chrome では対象外でした。Chrome の検証ロジックでは、コード署名用途に限定された中間 CA を通って TLS の鎖を組めないからです。

まとめ

eMudhra の中間 CA 8 件（TLS 用 6・コード署名用 2）の秘密鍵が漏洩し、研究者が署名で所持を証明した
ブラウザは CRLSets・OneCRL で数時間以内にブロックし、ブロック前に TLS 用中間 CA につながる証明書は CT ログに記録されていなかった
失効を確認しない Go・Python・Node.js などは、ルート束の更新か鍵の名指しブロックが必要
Go は 1.27.3 / 1.26.10 で対応したが、効くのは再ビルドしたバイナリだけ

Chrome は該当ルートを外す Root Store の更新を予告しており、流出経路の公表とあわせて、eMudhra の他のルートの扱いが次の焦点になります。