鍵が推測できた認証局。Pythonは緊急更新、Chromeでは27日から一部の証明書が使えなくなる

インドの認証局eMudhraの中間証明書8件で、秘密鍵が弱い乱数で作られ、誰でも偽の証明書を作れる状態でした。Chromeは即日遮断し、27日には元の証明書を信頼の一覧から外します。Pythonはpipに入っている証明書の一覧を更新しました。サイト運営者と開発者がやることをまとめます。

この記事の結論

  1. インドの認証局eMudhraの中間証明書8件で、秘密鍵が弱い乱数で作られていた。誰でも、どんなサイトにもなりすませる偽の証明書を作れる状態だった
  2. Chromeは報告から約2時間で遮断。偽の証明書が使われた形跡はないとしている。さらに10月27日から、元になる証明書「emSign ECC Root CA - G3」を信頼の一覧から外す
  3. Pythonは3.15.1 / 3.14.9 / 3.13.17を緊急公開。ただし作ってある仮想環境は自動では直らない。pipなどを環境ごとに上げる必要がある
  • インドの認証局eMudhraの中間証明書8件で、秘密鍵が弱い乱数で作られていた。誰でも、どんなサイトにもなりすませる偽の証明書を作れる状態だった
  • Chromeは報告から約2時間で遮断。偽の証明書が使われた形跡はないとしている。さらに10月27日から、元になる証明書「emSign ECC Root CA – G3」を信頼の一覧から外す
  • Pythonは3.15.1 / 3.14.9 / 3.13.17を緊急公開。ただし作ってある仮想環境は自動では直らない。pipなどを環境ごとに上げる必要がある

Webサイトのhttpsは、認証局という機関が発行する証明書で「このサイトは本物だ」と保証している。認証局が使う秘密鍵は、その仕組みの根っこにあたる。

その秘密鍵が、推測できる作りになっていた。インドの認証局eMudhraの件だ。ブラウザ、OS、プログラミング言語が一斉に対応している。

何が起きたのか

Googleの発表によると、経緯はこうだ。

  • 10月17日(協定世界時)、セキュリティ研究者から、eMudhraの8つの中間認証局の秘密鍵が漏れたも同然だと報告があった
  • 原因は、秘密鍵を作るときの乱数が不十分だったこと。そのため、誰でも信頼された証明書を偽造して、どのサイトにもなりすませる状態だった
  • Chromeは報告から約1時間40分後に、問題の鍵を使う証明書をすべて遮断する更新を配った。ブラウザの更新や再起動は要らない仕組みだ
  • Androidにも、Google Play開発者サービス経由で同じ対策が届いた

偽の証明書は使われたのか

Googleは、遮断する前に、問題の中間認証局から出た証明書が「証明書の透明性(CT)」の公開記録に一枚も載っていなかったとしている。Chromeは、公開記録に載っていない証明書を信頼しない。

そのため、Chromeを使う人に対して偽の証明書が使われた可能性はない、というのがGoogleの説明だ。

SPONSORED

サイトを持つ人へ:27日から使えなくなる証明書

Googleはさらに、問題の中間認証局の元になっている「emSign ECC Root CA – G3」を、Chromeが信頼する一覧から外す。

  • 反映は2026年10月27日(火)朝(米国太平洋時間)の予定。日本時間では27日の深夜から28日の未明ごろになる
  • この証明書につながる正規の証明書も、Chromeで使えなくなる
  • Googleは、該当するサイトの運営者に、ほかの認証局の証明書にすぐ取り替えるよう求めている

日本のサイトでemSignの証明書を使っているところは多くないと思われる。だが、海外のサービスや取引先のサイト、社内で使っている外部のシステムが急に開けなくなることはありうる。

自分のサイトの証明書の発行元は、ブラウザのアドレスバーの鍵のマークから確かめられる。有効期限と名前が合っているかは、このサイトのSSL証明書の期限チェックでも見られる。

Pythonを使う人へ:仮想環境ごとに直す

ブラウザが直っても、プログラムは別の証明書の一覧を持っていることがある。Pythonがそうだ。

Pythonのpipやrequestsは、certifiという部品に入った証明書の一覧を使う。そこに問題の元の証明書が残っていると、OS側で信頼を外しても、pipは信頼したままになる。Pythonのセキュリティ担当は、放っておくとpython.orgやpypi.orgへの通信も、なりすましを受けるおそれがあると警告した。

Pythonの対応

  • 10月21日、Python 3.15.1 / 3.14.9 / 3.13.17を緊急公開。同梱のpipを26.2.2(certifi 2026.10.19入り)に上げた
  • 3.13はセキュリティ修正だけの段階に入ったばかりで、通常はpipを上げないが、特例として出した
  • 10月24日には、Python本体のsslモジュールに、問題の鍵を拒む一覧を入れる修正(CVE-2026-115557)も公表された。開発中の版に取り込まれた段階で、各版への反映は今後の公式の案内で確かめる必要がある

やること

  1. 既にある仮想環境ごとに、pipとuvを上げる。Pythonを入れ直しても、作ってある仮想環境の中のpipは古いままだ
  2. 公式は、古いpipのまま通信するのを避けるため、ハッシュ値を指定してpip 26.2.2を入れるコマンドを案内している。Pythonの公式の案内からそのまま使う
  3. そのあとで、certifiを2026.10.19以上に上げる
  4. uv、sigstore、conda、pixiを使っているなら、公式が示す版以上に上げる(uv 0.13.4、sigstore 4.5.1、conda 26.9.4、pixi 0.82.1)
  5. コンテナのイメージは、キャッシュを使わずに作り直す。OSの最新の証明書を取り込むためだ
  6. python.orgから入れたmacOS版のPythonにも、certifiが入っている。公式の案内に、版ごとのコマンドがある

公式は、REQUESTS_CA_BUNDLEのような設定で信頼先を足しても、古いpipが持っている問題の証明書は消えないとしている。pip自体を上げるのが対策だ。

証明書が外れて正規の通信までつながらなくなったときも、証明書の確認を切って逃げない。相手が新しい証明書に替えるのを待つか、問い合わせる。

今週の流れの中で

今週は、Chromeがhttpにつなぐ前に警告するようになった。httpsの価値は、証明書が本物であることに支えられている。その根っこの鍵が推測できたら、鍵のマークは何も保証しない。

Googleが2時間足らずで遮断し、公開記録の仕組みのおかげで実害が出なかったのは、何重にも守りを重ねてきた結果だ。一方で、Pythonのように自前で証明書の一覧を持つソフトは、それぞれが更新しないと直らない。Brotliの件と同じ構造だ。

まとめ

  • eMudhraの中間証明書8件で、秘密鍵が弱い乱数で作られ、偽の証明書を作れる状態だった
  • Chromeは約2時間で遮断。公開記録に偽の証明書はなく、Chromeの利用者が狙われた可能性はない
  • 27日から「emSign ECC Root CA – G3」をChromeが信頼しなくなる。該当するサイトは証明書の取り替えを
  • Pythonは仮想環境ごとにpip 26.2.2以上、certifi 2026.10.19以上。コンテナはキャッシュなしで作り直す
SPONSORED

出典

本記事は2026年10月25日時点の公式発表に基づく。Chromeの反映日時は予定であり、変わる場合がある。Pythonの更新コマンドは、必ず公式の案内の最新版を使うこと。

新しい記事が出たら、ブラウザの通知でお知らせします。

メールアドレスの登録は要りません。いつでも止められます。

AUTHOR

北海道のWEB屋

北海道を拠点に、Web業界14年・サポート実績1,000件以上。WordPressの復旧、サーバー移転、独自ドメインとメールの設定、PHP・JavaScriptの修正まで対応します。相談と見積もりは無料です。

SPONSORED

関連記事

RELATED