10 月 17 日 20:06（UTC）、Mozilla は Chrome ルートプログラムから転送された報告を受け取りました。インドの認証局 eMudhra の中間証明書 8 枚の秘密鍵が漏えいしたという内容で、8 つの鍵すべてを管理できることの証明が添付されていました。21:48 には、Mozilla が報告者の手法を知らないまま自力で鍵を復元しています。Mozilla がインシデント（Bugzilla 2083449）で説明したところでは、8 つの P-384 秘密鍵はいずれも 256 未満の整数で、ほぼすべてがゼロのため、ほぼ一瞬で求められます。8 枚のうち 6 枚は TLS 用の中間証明書で、Chrome、Mozilla、Microsoft、Apple の 4 つのルートプログラムで信頼されていました。残る 2 枚はコード署名用で、Microsoft が信頼していました。これらの鍵は 2025 年 4 月 30 日に行われた鍵生成セレモニーで作られたものです。

時系列

  • 10 月 17 日：Firefox は 22:59（UTC）に OneCRL による失効処理を完了。
  • 10 月 18 日：09:38（UTC）に eMudhra が 8 枚の証明書を失効（理由 caCompromise）。eMudhra はこれらからエンドエンティティ証明書は発行していないとしていますが、鍵は誰でも計算できるため、誰でもそれを使って任意のドメインの証明書を偽造できます。
  • 10 月 20 日：Mozilla はルート証明書 emSign ECC Root CA - G3 の信頼を緊急に取り消すと発表しました。失効情報を使わないクライアントや、特定の中間証明書だけの信頼を取り消す仕組みを持たないクライアントを守るためです。Chrome ルートプログラムも同日、同様の対応を取ると表明しました。eMudhra はこのルート配下のすべての中間証明書からの発行を停止し、移行が必要な証明書は約 30,000 枚、そのうち約 97% は ACME 経由で発行されたものだと見積もっています。
  • 10 月 22 日：eMudhra は、取締役会がグローバルな SSL/TLS 証明書事業から自主的に撤退することを決めたと発表しました。

サーバー側で対応が必要な理由

ブラウザには高速な失効の仕組みがあり、スイッチ一つで遮断できました。サーバー上のプログラムは事情が違います。curl、wget、Python、PHP、Node、Java、Go が HTTPS リクエストを送るときは、多くの場合システムの信頼ストアか同梱の証明書リストに頼っており、ブラウザの更新は何の役にも立ちません。Cloudflare は 10 月 20 日の解説で、SDK を更新しても、最終的に使われる信頼ストア次第で検証方針は変わらないことがあると注意を促し、パッチ適用後に証明書エラーが出ても、検証を無効にして消すことは絶対にしてはいけないとしています。

VPS でやるべきこと

  • Ubuntu：10 月 20 日の USN-8944-1 で ca-certificates から emSign ECC Root CA - G3 が削除されました。22.04 は 20260816ubuntu0.22.04.1、24.04 は 20260816ubuntu0.24.04.1 です。10 月 21 日の USN-8947-1 では NSS も更新され、このルートと「Comodo AAA Services root」が削除されました。
  • Debian：DSA-6572-1 で同じ 2 つのルートが削除され、Debian 13 は 20250419+deb13u1 です。Debian 12 は DLA-4845-1 で 20250419~deb12u2 です。
  • 更新後に ls /etc/ssl/certs | grep -i emsign_ecc_root_ca_-_g3 を実行して何も表示されなければ、このルートはもうシステムの信頼ストアにありません。
  • 独自の証明書バンドルを持つプログラムは個別の更新が必要です。Python の certifi はバージョン 2026.10.18 以降、このルートを含んでいません（同梱の証明書ファイルをリリースごとに確認しました）。Linux 上の Go プログラムは既定でシステムの信頼ストアを使うため、ca-certificates の更新で大半のケースはカバーされます。システムの信頼ストアが更新されないような限られたケースに備えて、10 月 19 日に公開された Go 1.26.10 / 1.27.3 では crypto/x509 に拒否リストが追加されました（GO-2026-6809 / CVE-2026-111943）。自分でコンパイルしている Go プログラムは、新しいバージョンでビルドし直してください。Docker イメージにも独自の ca-certificates が入っているので、イメージを作り直してコンテナを再起動します。VPS での Docker 入門を参照してください。
  • 最後に関連サービスを再起動してください。すでに動いているプロセスは信頼ストアを読み直しません。

多くのサイト運営者にとって、自分の証明書に直接の影響はありません。Let's Encrypt などほかの CA を使っているなら証明書を取り替える必要はなく、設定方法は Let's Encrypt の SSL 証明書の設定のとおりです。ただ今回の件は、偽造証明書への備えには何層もの対策が必要だということを改めて示しています。.gh、.sl、.as のレジストリ乗っ取りの記事で取り上げた CT 監視と CAA レコードは、ここでも有効です。