HTTPS の証明書の鍵が漏れた件（2026年10月）：Python・Node.js などは何を上げる？

2026年10月17日（UTC）に、HTTPS の証明書を出す仕組みの途中にある「中間証明書」8枚の秘密鍵が漏れている、という届けが Google に寄せられました。Red Hat は、この件はソフトの脆弱性ではなく、この8枚を出した認証局（以下「この認証局」）の秘密鍵の問題だと書いています。同じ日のうちに、Chrome と Firefox は、この8枚を止めました。ところが、ブラウザーの外で動く道具（Python・Node.js・Go・Docker など）は、ブラウザーのような「使ってはいけない証明書」の知らせを受け取らないものが多く、道具ごとに版を上げる必要があります。

先に答えを書きます。使っている道具で、上げるものが変わります。自分の行だけ見てください。

Python（pip・uv・certifi）: certifi（Python の多くの道具が使う、信頼する根の一覧を配るパッケージ）は 2026.10.19 以上、pip は 26.2.2 以上、uv は 0.13.4 以上です。Python 本体（python.org の配布）は、3.15 系なら 3.15.1、3.14 系なら 3.14.9、3.13 系なら 3.13.17 以上です。3.11・3.12 は新しい版が出ないので、pip を上げます
Node.js: 26系は 26.12.1、24系は 24.22.1、22系は 22.23.4 以上です
Go・Rust・Docker: 表を見てください（→「道具の版を上げる（Python・Node.js・Go・Rust・Docker）」）
Linux のサーバー・コンテナ（OS の証明書の一覧 ca-certificates）: Ubuntu・Debian・Alpine・Fedora は直しが出ています（Fedora は、changelog〔変更の記録〕に emSign ECC Root CA - G3 を外すとは書かれていません。Fedora 45 は試験の段階）。RHEL は、10月22日の時点ではまだでした。コンテナのイメージは作り直します。macOS と Windows は確かめられませんでした（→「OS とコンテナの証明書の一覧を更新する」）
Mac で python.org から入れた Python は、OS ではなく certifi を使うので、上の Python の行が当たります
Java: Java の記事を見てください（Ubuntu・Debian は、OS の更新のあとに確かめが要ります）
自分のサイト: チェーン（証明書のつながり）に出る名前は3種類です（→「サイトを運営している人は、何を確かめる？」）。Chrome は、10月27日ごろに emSign ECC Root CA - G3（Google の見込み）を外す予定です
ブラウザー: Chrome と Firefox は、両社の告知を読むかぎり、ふつうの設定なら利用者の操作は要らない書き方でした。Safari と Edge は、Apple と Microsoft の告知が見つからず、確かめられませんでした（→「ブラウザーは、もう守られている？」）

この記事は、Python や Node.js などで開発している人と、自分のサイトを持っている人に向けて書きました。書いてあることは、Google・Mozilla・各言語や OS の公式の告知を、2026年10月22日の16時44分ごろから17時ごろ（日本時間。UTC では 7時44分〜8時）に開いて確かめたものです（一部は、その後に確かめました）。悪用の状況は日々変わるので、時刻を添えました。鍵を割り出す方法や、偽の証明書を使う操作は、書いていません。

この記事でわかること

認証局の中間証明書8枚の秘密鍵が漏れた件は何か。Chrome と Firefox は、どう止めたか
ブラウザーの外の道具（Python・Node.js・Go・Rust・Docker）と OS は、何を上げればよいか
悪用は確認されているか。サイトを運営している人が、自分のチェーンを見る方法
Python・uv を使っている人が上げる版と、このサイトの Python の記事の例との関係

認証局の鍵に、何が起きた？
1. たとえ話：壊れているのはどこか
ブラウザーは、もう守られている？
ブラウザーの外の道具は、何を上げる？
Python・uv を使っている人は、何を上げる？
サイトを運営している人は、何を確かめる？
1. チェーンの見方
悪用はされている？（2026年10月22日時点）
詳しく知りたい人へ（やることは変わりません）
よくある質問
まとめ
参考資料

認証局の鍵に、何が起きた？

HTTPS で使う証明書は、認証局（CA）という組織が出します。証明書そのものや、HTTPS の基本は、HTTPS と証明書の記事に書きました。ここで要るのは、証明書が「一番上の根（ルート）証明書 → 中間証明書 → サイトの証明書」というチェーンでつながっている、ということだけです。ブラウザーや OS は、あらかじめ「この根なら信頼する」という一覧（この記事では「信頼の名簿」と呼びます）を持っていて、その根からチェーンがつながっているサイトの証明書を、本物として受け取ります。

今回、そのチェーンの途中にある「中間証明書」8枚について、秘密鍵（証明書に署名するときだけ使う、持ち主だけが知っているべき鍵）が漏れている、という届けがありました。

たとえ話：壊れているのはどこか

まず、たとえ話で壊れている場所を見ます。

ある会社の本店が、各地の支店に「この支店の公印が押された身分証は、本店が認めたものとして扱ってよい」と許しています。お店（サイト）は、公印が押された身分証をお客に見せます。お客は、手元の名簿（信頼する本店の一覧）に載っている本店が認めた支店の身分証なら、そのお店を本物だと信じて取引します。使ってはいけなくなった公印は、回覧板で知らされます。

ところが今回、いくつかの支店の公印は、彫りの形の数が足りず、選べる形がごくわずかでした。そのため、公印を作り直しやすい状態です。公印を作り直せる人は、どの店の名前でも、本物の公印が押された身分証を作れます。その身分証を持って、お客とお店の間に立てる人なら、本物のお店のふりができます。壊れているのは、この「公印の彫りの形の数が足りない」ところです。

本店の公印は、漏れていません。それでもお客は、念のため、「その本店が認めた支店の身分証は、どれも受け取らない」と決めました。

たとえ話の物は、次の物に当たります。

たとえ話	本当の物
お店	サイト
本店	根（ルート）証明書
支店	中間証明書
支店の公印	中間証明書の秘密鍵
公印が押された身分証	サイトの証明書
お客	ブラウザーや、Python・Node.js などの道具
お客とお店の間に立つ	通信の間に入る（Wi-Fi など）
名簿	信頼する根の一覧（信頼の名簿）
回覧板	CRLSet・OneCRL（使ってはいけない証明書の一覧。この記事では「止める一覧」と呼びます）
「その本店が認めた支店の身分証は、どれも受け取らない」	根の信頼を外すこと（Chrome と Mozilla が決めた）

本当の説明では、こうなります。

Google は、8枚の中間証明書の秘密鍵は、乱数が足りない（暗号の意味で弱い）状態で作られていた、と書いています。同時に、CT（Certificate Transparency。発行された証明書を公開の記録簿に載せる仕組み）に載っていない証明書は受け取らない相手には、偽の証明書は使えなかった、とも書いています（→「悪用はされている？（2026年10月22日時点）」）。これらの中間証明書への信頼をまだ外していない道具では、どのサイトにもなりすませる証明書が通ってしまう状態だった、というのが Google の説明です。Google は、ほかの根の鍵に同じ失敗が無いことも確かめた、と書いています。Mozilla は、鍵を作る手順に欠陥があったと書き、本来はとても大きな数から選ぶはずの秘密の数が、とても小さい数だった、と説明しています。なお、本店の公印（根の鍵）が漏れていないことは、この認証局が書いています。「根の信頼が外されたのは用心のため」とも書いています。

この認証局は、8枚を失効させました。失効とは、認証局が「この証明書は、もう使ってはいけない」と宣言することです。ところが、この宣言を読まない道具が多いのです（→「ブラウザーの外の道具は、何を上げる？」）。8枚の名前、根と相互署名、経過、原因は、あとの「詳しく知りたい人へ（やることは変わりません）」にまとめました。

ブラウザーは、もう守られている？

ブラウザーは、止める一覧をすばやく配る仕組みを持っています。Cloudflare は、ブラウザーの開発元はスイッチ1つで直せた、と書いています。

ブラウザー	どう止めたか	利用者がすること（原文の範囲）
Chrome	10月17日 19:45（UTC）に、CRLSet（Chrome が配る止める一覧）の更新で止めた。止め方は公開鍵の指紋なので、同じ鍵を使った証明書は全部止まる	ブラウザーの更新も再起動も要らない（Google）
Android の端末（Google Play Services）	同じ更新を、月曜日（10月19日）の 22:00（UTC）ごろに配った。Google Play Services は、Google が配る端末の部品の更新	すぐ受けたいときは、端末を再起動する（Google）
Firefox	10月17日に、OneCRL（Firefox の止める一覧）で止め、RemoteSettings（Mozilla が設定や一覧を配る仕組み）で同じ日に配った	ふつうの設定なら、何もしなくてよい。RemoteSettings を方針で止めている・ネットの環境で届かない場合は、Firefox 158.0.1・ESR（延長サポート版）153.5.1・ESR 115.43.1（10月20日）以上にする。この3つは、新しい OneCRL の一覧を最初から中に持つ（番号は CVE-2026-113470、重さは high）
Safari・Edge	確かめられなかった	確かめられなかった

Google の原文は、Android について「月曜日」とだけ書いていて、日付がありません。この記事は、告知の流れから10月19日と読みました
Mozilla の告知は、新しい版は RemoteSettings を止めている人や、ネットの環境で届かない人のための物だと書いています。ふつうの設定の人は、10月17日に配られた OneCRL で守られている、という読み方です。Android の Firefox は、一部の profile で、起動したときに一覧が当たらなかったため、158.0.2（10月21日）で直しました
Chrome は、これに続けて emSign ECC Root CA - G3 を信頼の名簿から外す予定です。Google は、すべての端末に届くのは 10月27日（火）の朝（米国太平洋時間）の見込み、Canary や Beta のような先に試す版はもっと早い、と書いています
Safari と Edge は、Mozilla の議論の場に、届けは Apple と Microsoft にも送られた、と書かれています。しかし、Apple と Microsoft 自身の告知は、確かめられませんでした（探したページは、まとめの「確かめていないこと」に書きました）。Cloudflare が「Mozilla の担当者のテストのサイト」と紹介するページ（以下「テストのサイト」。二次の資料）は、Apple の機器は10月19日から、Microsoft の基盤は10月20日から止めている、と書いています。しかし、Apple と Microsoft の言葉ではないので、この記事では言い切りません

ブラウザーは「自動で守られる」と一括りにせず、この表のように、Chrome と Firefox の原文の範囲までを読んでください。

ブラウザーの外の道具は、何を上げる？

ブラウザーには、「使ってはいけない公印の回覧板」（止める一覧）がすぐ届きます。ブラウザーの外の道具には回覧板が届かないので、道具ごとに「信頼の名簿」を入れ替えます。

Node.js の変更の説明は、Node.js は Mozilla の信頼の名簿を中に持っているが、ブラウザーの CRLSet・OneCRL に当たる物も、既定のオンラインの失効の確かめも無い、と書いています。中間 CA の鍵が漏れても、信頼された根につながっていれば、そのチェーンは通ってしまいます。根ごと外すと、ほかの正しい中間 CA まで止まってしまう、とも書いています。Go の議論（GitHub）でも、Linux の根の一覧の今の形では、中間 CA の失効がアプリに伝わる道が無く、コードに書き込むしかない、と書かれています。

テストのサイト（二次の資料）も、同じ趣旨です。この認証局は失効させたが、多くの道具は失効の知らせを読まないので、ソフトの更新が要る、と書いています。

つまり、答えは「道具の版を上げて、中の信頼の名簿（や止める一覧）を入れ替える」です。ここから、道具の版と、OS の証明書の一覧を、順に見ます。

道具の版を上げる（Python・Node.js・Go・Rust・Docker）

自分の使う道具の行だけ見てください。

道具	上げる版
Python の certifi	2026.10.19 以上（GitHub の告知が書く「直った最初の版」は 2026.10.18）
pip	26.2.2 以上
uv	0.13.4 以上
Python 本体（python.org）	3.15 系なら 3.15.1、3.14 系なら 3.14.9、3.13 系なら 3.13.17 以上。3.11・3.12 は新しい版が出ないので、pip を上げる
Node.js	26系は 26.12.1、24系は 24.22.1、22系は 22.23.4 以上
Go	1.27 系なら 1.27.3、1.26 系なら 1.26.10 以上
Rust の rustup	1.29.2 以上
Rust の rustls-webpki	0.103.16 以上
Rust の webpki-roots・webpki-root-certs	1.0.10 以上
Docker Engine	29.9.2 以上
Docker Desktop	4.96.2 以上。直しは部品ごとに順に出ていて、残りは次の版で出るので、出るたびに上げる（4.96.1 は10月21日）
Java	Java の記事を見てください

これらの版は、10月19日から22日にかけて出ました（Python 本体と Node.js は10月21日、Docker Desktop の 4.96.2 は10月22日）。用語を一言ずつ説明します。

certifi: Python の多くの道具が使う、信頼する根の一覧（CA の束）を配るパッケージです
NSS: Mozilla が、信頼する根の一覧を持つために使う部品です。Node.js や Alpine の一覧は、NSS 3.131.1（Mozilla の名簿の部品）の内容に合わせてあります
webpki-roots・webpki-root-certs: Rust の道具が使う、信頼する根の一覧を配るパッケージです

外したものが、道具ごとに違う

同じ件でも、道具が外したものは違います。「この版に上げれば、どの道具でも同じ状態になる」わけではありません。

emSign ECC Root CA - G3 だけを外した: certifi（2026.10.18 で4つ外し、2026.10.19 で3つ戻した）・webpki-roots・uv（webpki-root-certs 経由）
emSign ECC Root CA - G3 に加えて emSign Root CA - C1・emSign ECC Root CA - C3 も外した: NSS 3.131.1、それを取り込んだ Node.js の3つの版（根の一覧を NSS 3.131.1 に更新した）と Alpine。C1 と C3 は、この件とは別の話で、この認証局が、前から予定していた自発の取り下げだと書いています。certifi 2026.10.19 は、C1 と C3 を残しているので、NSS 3.131.1 とはずれます
emSign ECC Root CA - G3 に加えて Comodo AAA Services root も外した: Debian、Ubuntu の ESM（延長サポート）。Ubuntu の 22.04〜26.10 の告知は、emSign ECC Root CA - G3 だけです
根ではなく、8つの中間 CA の公開鍵の指紋で止めた: Go（crypto/x509 の Verify が、8枚の中間 CA を含むチェーンを捨てる。CVE-2026-111943）、Node.js（26.12.1・24.22.1・22.23.4）、rustls-webpki 0.103.16（RUSTSEC-2026-0382）
中の部品を上げた: pip 26.2.2（中の certifi を 2026.10.19 に）、rustup 1.29.2（中の rustls-webpki と webpki-root-certs を上げただけの小さなリリース）、Docker Engine 29.9.2（中の Go を 1.26.10 に上げ、8枚を含むチェーンを断る）

道具ごとの細かい注意

Node.js の「止める一覧」は、26.12.1・24.22.1・22.23.4 の3つとも入っています（24.22.1 と 22.23.4 は、主な変更の欄ではなく、コミットの一覧に載っています）。また、Node.js の変更の説明は、上げる前にできた TLS（HTTPS の暗号の部分）のセッションを再開した接続は、確かめ直されない（セッションの有効期限が切れれば終わる）と書いています
Docker の公式の python イメージの担当者は、3.11 と 3.12 では pip を上げない見込みだ、と書いています（Python 本家に合わせる）。必要なら、自分の Dockerfile で上げます。10月21日に、3.15-slim の pip が 26.2.1 のままだという報告があり、担当者は同じ日に、直す変更を出したと書いています（イメージが作り直された日は確かめていません）
Docker Engine 29.9.2 の告知は、レジストリ（イメージを置く場所）の証明書のチェーンが、この中間 CA に頼っていると、イメージの pull と push が、証明書の確かめで失敗する、と書いています。その場合は、レジストリ側で、別のチェーンの証明書に取り替えてもらいます

OS とコンテナの証明書の一覧を更新する

次は、OS が持つ証明書の一覧（ca-certificates）です。これは OS の信頼の名簿です。告知を開いた時刻（10月22日、日本時間）は、Ubuntu と Debian が 16時55分、Alpine と Fedora が 16時56分、RHEL・macOS・Windows が 16時58分です。USN・DSA・DLA は、Ubuntu（USN）と Debian（DSA は通常のセキュリティ、DLA は長期サポート〔LTS〕）が告知に付ける番号です。

OS	状況	版・告知
Ubuntu 22.04・24.04・26.04・26.10	出た	USN-8944-1（10月20日）。22.04 は `20260816ubuntu0.22.04.1`、24.04 は `20260816ubuntu0.24.04.1`。`emSign ECC Root CA - G3` を外す
Ubuntu 14.04〜20.04（ESM。延長サポート）	出た	USN-8944-2（10月20日）。こちらは `Comodo AAA Services root` も外す
Debian 13（trixie）	出た	DSA-6572-1（10月20日）。`20250419+deb13u1`。`emSign ECC Root CA - G3` と `Comodo AAA Services root` を外す
Debian 12（bookworm・LTS）	出た	DLA-4845-1（10月20日）。`20250419~deb12u2`。同じ2つの根
Alpine edge・3.24・3.23・3.22・3.21・3.20	出た	`ca-certificates` の `20261020-r0`（10月20日）。NSS 3.131.1 の一覧
Fedora 43・44・46	出た（changelog に `emSign ECC Root CA - G3` を外すとは書かれていない）	`ca-certificates-2026.2.92_v9.0.319-1`（NSS 3.131.1 から）。続きの `-2`（コード署名用の根を外す）は、46 で配信中、43・44 では試験の段階
Fedora 45	まだ（試験の段階）	`-1` は `-2` に置き換えられ、`-2` は試験の段階
RHEL 6〜10	まだ	Red Hat の告知（RHSB-2026-012）は、直ったパッケージは下の節で知らせる、と書くが、その節に版が無い（10月22日にも更新されている）
macOS	確かめられなかった	Apple の告知が見つからなかった
Windows	確かめられなかった	Microsoft の告知が見つからなかった

OS のパッケージで入れた Java は、OS の ca-certificates から自分の一覧（cacerts）を作ります。ただし手元で試すと、Ubuntu 24.04・Debian 13 では、Java を入れたあとに OS の一覧を更新しても、Java の一覧に古い根が残りました（Fedora 44・Alpine 3.24 では消えました。2026年10月22日）。確かめ方と、いまできることはJava の記事を見てください
Fedora は、変更の記録（changelog）に、emSign ECC Root CA - G3 を外すとは書かれていません。この記事は、版の番号までにしました
RHEL では、rpm -q ca-certificates で入っているパッケージの版を見られます。Red Hat は、直ったパッケージが出るまでの手当てとして、関係する根をブロックリストに入れる方法がある、と書いています
Windows も、テストのサイト（二次の資料）は、Microsoft が Windows の自動の証明書の信頼の一覧（CTL）の更新で止めたと書いています。これも Microsoft の言葉ではありません

コンテナのイメージの中の一覧も、別です。 OS の ca-certificates は、コンテナのイメージの中にも入っています。Python の告知は、コンテナのイメージを作り直して、OS の最新の証明書を入れるよう書いています。Red Hat も、基になるイメージが更新されたら、自分のコンテナを作り直すよう書き、Cloudflare は、影響を受けるイメージを作り直す（rebuild affected images）よう書いています。

Java の配布元の公式イメージ（eclipse-temurin など）は、作り直しても Java の一覧は変わりません（→ Java の記事）。

作り直すときは、基になるイメージを取り直して、前の作りのキャッシュを使わないようにします。

docker pull イメージの名前
docker build --pull --no-cache .

--pull は、参照している基になるイメージを、いつも取りに行く指定です。--no-cache は、前のビルドの結果（キャッシュ）を使わない指定です。どちらも、Docker の文書の説明（"Always attempt to pull all referenced images"・"Do not use cache when building the image"）にもとづきます。

上げたあとに気をつけること

証明書のエラーが出ても、確かめを切って直さないでください。Cloudflare は、証明書のエラーを、確かめ（検証）をやめて消してしまうと、今回の更新が取り戻そうとしている、相手が本物かを確かめる守りまで外れてしまう、と書いています
SDK だけ上げても足りないことがあります。証明書の確かめは、HTTP のライブラリー・言語の実行環境・OS・自分の設定のどれかに任されているからです。依存の木（使っているパッケージの、そのまた先に使うパッケージ）も見て、影響のあるものを更新し、イメージを作り直し、再読み込み・再起動・配り直しが要るかを確かめます
ブラウザーで開けたことは、裏で動く道具が守られている証明になりません。curl で試しても、アプリが別の確かめ方を使うなら同じです。確かめるときは、そのアプリが通る TLS の道で確かめます

出典: Google のブログ・Mozilla の議論の場（Bugzilla）・Cloudflare のブログ・Mozilla の告知 MFSA 2026-111・Firefox 158.0.1 のリリースノート・Node.js の変更 #66871・Node.js 24.22.1 のリリース・Node.js 22.23.4 のリリース・Go の議論・Red Hat の告知 RHSB-2026-012・Docker の文書: docker buildx build

Python・uv を使っている人は、何を上げる？

このサイトの uv の記事・pyproject.toml の記事・Python 3.15 の記事で使っている certifi・uv・pip が、今回の件に関わります。Python の公式の掲示板の告知は、certifi のような CA の束から emSign の根を外す必要があったので、下の版以上にすぐ上げ、コンテナのイメージを作り直して OS の最新の証明書を入れてほしい、と書いています。怠ると、python.org や pypi.org を含めて、TLS を使う側が通信の間に入られる恐れがある、とも書いています。

何を	当たる範囲	上げる版
certifi	2019.03.09 以上で、2026.10.18 より前（GitHub の告知）	2026.10.19 以上
pip	26.2.2 より前	26.2.2 以上
uv	0.13.4 より前（特に設定を変えていない人は、既定の束を使っているので当たります）	0.13.4 以上

certifi の版は、GitHub の告知が「直った最初の版は 2026.10.18」と書く一方で、Python の告知は、関係のない emSign の根と合うように 2026.10.19 を勧めています。この記事は 2026.10.19 以上、と書きます。

pip：自分の中の certifi が残る

pip は、certifi を自分の中に持っています。さらに 24.2 からは、既定で OS の証明書も、certifi に足して使います（OS の一覧だけを使うのではありません）。同じ掲示板の、CPython のコア開発者の投稿（10月20日）は、だから 26.2.2 より前の pip は、OS の側で信頼を外しても、中の certifi で信頼し続ける、と書いています。pip を 26.2.2 以上に上げるのが、確かな直しです。

--cert や PIP_CERT で別の束を指す方法は pip の文書にありますが、コア開発者は、これらは CA を足すだけで、中の certifi を外せない、と書いていて食い違うので、この記事は手当てとして勧めません。

pip を上げる安全なコマンドは、公式の掲示板の告知に、ハッシュ付きで書かれています。ここに写すと間違えやすいので、告知から写してください。

uv：特に設定を変えていない人が当たる

uv の告知は、uv に入っている CA の束（既定の束）を使う人が当たると書いています。特に設定を変えていない人は、既定の束を使っているので当たります。--system-certs・SSL_CERT_FILE・SSL_CERT_DIR を使っている人は、その束に、問題の中間 CA や根が無いかを確かめます。CPython のコア開発者の投稿は、uv では、OS の信頼の名簿で外したうえで UV_SYSTEM_CERTS=true を使う方法もある、と書いています（pip ではこの方法は効きません）。

uv の告知には、こうも書かれています。これは、オープンソース全体に広がった件で、certifi や webpki-root-certs のような、CA の束を中に持つパッケージを使うソフトは、必ず上げる必要がある。uv だけではないので、ほかのパッケージも自分で確かめてほしい。uv の上げ方は、uv の記事にあるとおり、uv self update か pip install --upgrade uv です。

Python 本体と、macOS のインストーラ

python.org の macOS のインストーラで入れた Python は、キーチェーン（macOS の証明書の置き場）の証明書を既定では使わず、certifi の束を使います。「Install Certificates」は、pip install --upgrade certifi を流すスクリプトです。Python 3.15.1・3.14.9・3.13.17（10月21日）は、中に入れる pip を 26.2.2（certifi 2026.10.19 入り）に上げました。3.13 は、セキュリティだけの期間に入ったばかりなので、特別に出した、と書かれています。3.11 と 3.12 の新しい版は出さず、pip はふつうの手段で上げます。

このサイトの記事の例を、読み替える

uv の記事は、書いたときの最新版 uv 0.13.1 を例にしています。0.13.4 より前なので、0.13.4 以上に上げてください
uv の記事とpyproject.toml の記事の出力の例には、certifi==2026.7.22 のような行が出てきます。書いた時点の出力ですが、2026.7.22 は上の「当たる範囲」に入っています。自分の手元では、2026.10.19 以上になっているかを確かめてください
Python 3.15 の記事は、Install Certificates.command をダブルクリックする手順を書いています。このスクリプトは certifi を上げるだけで、pip（と、その中の certifi）は上げません。Python 3.15.1 以上を入れるか、告知のコマンドで pip を 26.2.2 以上に上げてください

固定した版を書いた物（pip freeze の出力を保存した requirements.txt や、ロックファイル）は、書き換えないかぎり、古い certifi を入れ直します。固定してある場合は、版の行を新しいものに書き換えます。

出典: Python の公式の掲示板の告知（同じ掲示板の、CPython のコア開発者の投稿〔10月20日〕も）・certifi の GitHub の告知・pip の文書: HTTPS の証明書・uv 0.13.4・Python 3.15.1 などの告知

サイトを運営している人は、何を確かめる？

Chrome は、10月27日（火）の朝（米国太平洋時間）ごろに、emSign ECC Root CA - G3 を信頼の名簿から外す予定です（Google の見込み）。自分のサイトを持っている人は、証明書のチェーン（証明書のつながり）を見ます。Google は、こう書いています。emSign ECC Root CA - G3 につながる証明書を使っているサイトの運営者は、壊れるのを避けるために、別の根につながる認証局（Chrome の信頼の名簿に入っているもの）から、新しい TLS 証明書（HTTPS で使う証明書）を、すぐに取って入れ直す必要があります。この根につながる正しい証明書の一部は、Chrome で動かなくなります。

どのくらいのサイトが当たるのかについて、この認証局は、困るのは米国の1つの利用者の団体だけで、ほとんどの証明書は別の根の下にある、と書いています。さらに、移行が要る証明書は約30,000枚で、約97％は ACME（証明書を自動で取り直す仕組み）で出したものだとして、利用者を emSign Root CA - G1（RSA の根）の下へ移すと書いています（10月20日）。自動で取り直しているサイトも、取り直したあとに同じ見方でチェーンを確かめてください。

チェーンの見方

次のコマンドで、サーバーが送ってくる証明書の並びを見られます。サイトの名前 は、自分のサイトの名前に置き換えます。

openssl s_client -connect サイトの名前:443 -servername サイトの名前 -showcerts </dev/null 2>/dev/null | grep -E '^ ?[0-9]+ s:|^ +i:'

-connect サイトの名前:443: つなぐ先です
-servername サイトの名前: TLS の SNI（つなぎ先の名前を相手に伝える項目）に入れる名前です
</dev/null 2>/dev/null: 入力待ちで止まらないようにし、途中の表示を捨てます
grep -E '^ ?[0-9]+ s:|^ +i:': 証明書の持ち主（s:）と、発行者（i:）の行だけを残します

出てくる行は、番号 0 がサイトの証明書で、そのあとが中間です。この行の形（ 0 s: i:）は OpenSSL 3.6.0 で確かめたもので、macOS の /usr/bin/openssl（LibreSSL）は書き方が違うので、grep を付けずに全部を読んでください。

大事なのは、これがサーバーが送ってきた並びで、確かめ済みのチェーンではない、ということです。OpenSSL の文書も、-showcerts は、サーバーが送った証明書の並びを順に表示するだけで、確かめ済みのチェーンではない、と書いています。ブラウザーや OS が手元で信頼する根とは、別の物です。

見る名前は、次のとおりです。

emSign ECC Root CA - G3
emSign Root TLS CA - G3（Web 用の6枚のすぐ上の名前。自分で署名した根の形もあります）（→「根と相互署名」）
EM DV TLS CA - G3B・EM OV TLS CA - G3B・EM EV TLS CA - G3B、および G3C の3枚

このどれかが s: か i: の行に出たら、当たっている可能性があります。証明書を出した業者に問い合わせるか、別の根につながる認証局（Chrome の信頼の名簿に入っているもの）の証明書に取り替えます。出なければ、少なくとも、サーバーが送ってくる並びには、今回の中間証明書は入っていません。AAA Certificate Services という名前は、今回の8枚の相互署名にも出てきますが、それだけで当たるとは決まりません。見るのは、上の中間証明書の名前が出るかどうかです。

出典: Google のブログ・この認証局の告知・Mozilla の議論の場（Bugzilla）・OpenSSL: s_client

悪用はされている？（2026年10月22日時点）

10月22日に確かめた範囲を、だれが・いつ・どの範囲で書いたかを添えて並べます。「悪用は確認されていない」と、一言でまとめることはしません。

先に、Google が書いたことから始めます。CT は、先に書いたとおり、発行された証明書を公開の記録簿に載せる仕組みです。記録簿に載っていない証明書は受け取らない相手がいます。

誰が	いつ	書いていること
Google	10月20日	ブロックより前に、Web 用の6枚の中間 CA につながる証明書は、CT に1枚も記録されていない。だから、CT を求める相手には、偽の証明書は使えなかった。Chrome は、公に信頼される証明書すべてに、既定で CT を求める。Android も、最新の SDK を対象にしたアプリや、自分で CT を求めるアプリは同じ
Cloudflare	10月20日	Cloudflare のサービスの上では、実際の悪用は見つかっていない（範囲は自社のサービスだけ）
この認証局	10月21日	公表の前に、弱い鍵が割り出されたり悪用されたりした証拠は、知らない
Red Hat	10月21日〜22日	鍵が漏れただけで、どこかのシステムが破られたことにはならない。悪用には、通信の間に入れる位置にいて、偽の証明書を見せる必要がある

一方で、鍵そのものは外に出ています。Mozilla は、10月20日（13:06 UTC）に、複数の人が独立にこれらの中間 CA の秘密鍵を（計算で）割り出し、公開した人もいる、と書きました。Mozilla 自身も、届けの方法を知らないまま、10月17日の 21:48（UTC）に鍵を（計算で）割り出した、と書いています。鍵の公開場所は、この記事では書かず、リンクもしません。

ここで大事なのは、Google の「CT に載っていなかった」という話が、CT を求める相手にだけ当てはまることです。テストのサイト（二次の資料）は、ブラウザーの外の道具の多くは CT を求めないので、攻撃者がこれらの道具を狙ったかは分からない、と書いています。だから、ブラウザーの外の道具は、版を上げておきます。

悪用の有無の読み方は、脆弱性の知らせの読み方に書きました。「確認されていない」は「されていない」の証明ではない、という点も同じです。上の表は、この日までに見つかった範囲で、この先は変わります。

出典: Google のブログ・Cloudflare のブログ・この認証局の告知・Red Hat の告知 RHSB-2026-012・Mozilla の議論の場（Bugzilla）

詳しく知りたい人へ（やることは変わりません）

ここから先は、何が起きたかを詳しく知りたい人向けです。読まなくても、上に書いた「上げるもの」は変わりません。

対象の8枚

8枚のうち6枚は Web（TLS）用で、Chrome・Mozilla・Microsoft・Apple の4つが信頼していました。残る2枚はコード署名用（ソフトに署名するための証明書）で、Microsoft が信頼していました。名前は、Docker のリリースノートの並びで書くと、次のとおりです。それぞれに G3B と G3C の2枚があります。

用途	名前（G3B と G3C の2枚ずつ）
ドメイン認証の TLS（DV）	`EM DV TLS CA - G3B`・`EM DV TLS CA - G3C`
組織認証の TLS（OV）	`EM OV TLS CA - G3B`・`EM OV TLS CA - G3C`
拡張認証の TLS（EV）	`EM EV TLS CA - G3B`・`EM EV TLS CA - G3C`
コード署名	`EM OV CS CA - G3B`・`EM OV CS CA - G3C`

DV・OV・EV は、証明書を出すときにどこまで確かめたかの種類です。Web 用の6枚のすぐ上の発行者は emSign Root TLS CA - G3、コード署名用の2枚のすぐ上は emSign Root CS CA - G3 と、Mozilla の議論の場（Bugzilla）の一覧に書かれています。

この認証局は、自分の告知で、8枚のうち7枚は本番で使っておらず、使っていた1枚も、証明書を1枚も出していない、と書いています（2026年10月21日の更新）。

根と相互署名

8枚の上の根は、書く人によって言い方が違います。Google とこの認証局は emSign ECC Root CA - G3 の下と書き、Red Hat は Comodo AAA Services root を加えた2つと書いていて、この記事は「根は1つだけ」とは書きません（Chrome と Mozilla が信頼を外すと決めたのは emSign ECC Root CA - G3 です。両社の原文）。実際、8枚のすぐ上の emSign Root TLS CA - G3 と emSign Root CS CA - G3 には、emSign ECC Root CA - G3 が署名した形と、自分で署名した根の形の両方があり、8枚には、AAA Certificate Services という別の認証局の根による相互署名（同じ中間証明書に別の根からも署名をもらい、チェーンの道を2本にすること）の証明書も、crt.sh で数えて8枚ありました。AAA Certificate Services の根を運営する認証局は、Bugzilla に、その根は Chrome と Mozilla の信頼の名簿からは前に外れていて、Microsoft と Apple ではまだ信頼されている、と書きました。Mozilla も、その根は Mozilla の信頼の名簿に入っていない、と書いています。

ここまでの経過（UTC）

日付は、告知の書き方にそろえて UTC で書きます。日本時間にするには 9時間を足します。

日時（2026年）	出来事	書いた人
10月17日 18:05	Chrome の担当が、8枚の秘密鍵が漏れているという届けを受ける	Google
10月17日 19:45	Chrome が、8枚を止める更新を配る（CRLSet）	Google
10月17日 20:06	Mozilla が、同じ届けを受ける（Chrome から転送）	Mozilla
10月17日 22:59	Firefox で信頼を外す手続き（OneCRL）が終わる。配ったのは同じ日	Mozilla
10月18日 09:24〜09:38	この認証局が、8枚を失効させる（理由は CA の鍵の漏えい）	Bugzilla の表
10月19日	相互署名の証明書が失効する	Bugzilla（相互署名した認証局）
10月20日	Mozilla と Chrome が `emSign ECC Root CA - G3` の信頼を外すと決める。NSS 3.131.1 が出る	Mozilla・Google

届けを受けた時刻は、Google が「18:05 に Chrome が受けた」、Mozilla が「20:06 に Mozilla が受けた」と書き（受け取った窓口が違います）、失効の日は、この認証局の告知の年表が「10月19日に8枚とも失効させた」と書いていて、Bugzilla の表の10月18日と1日ずれるので、この記事は Bugzilla の表の時刻を使いました。

原因は、どう書かれている？

原因は、書く人によって言い方が違い、どれか1つに決まっていません。この記事では、どれも「〇〇は〜と書いている」の形で並べ、どれか1つを事実として言い切りません。

誰が	書いている内容	原文の言葉
Google	秘密鍵は、乱数が足りない状態で作られた	insufficient randomness・weak cryptographic entropy
Mozilla	鍵を作る手順に欠陥があった。作られた署名の問題ではなく、鍵の作り方の問題	the key generation process was flawed
この認証局	鍵を作る式の手順の1つに欠陥があり、強い鍵とは別に弱い鍵の組ができて、ブラウザーの信頼の名簿に載ったのは弱いほうだった	a flaw in one step of the ceremony procedure
Cloudflare	鍵そのものが弱い	the keys themselves are weak

この認証局は、10月19日の予備の見立てでは、その日に使った式のスクリプトに欠陥があったようだ、と書いています。10月21日の告知では、正確な根本原因はまだ確かめておらず、調べ終わったら公表する、と書いています。

「弱い乱数のせい」は Google の言い方です。原因がはっきりしていない部分は、はっきりしていないと読んでください。

よくある質問

Chrome や Firefox を使っているだけの人は、何かすることがありますか？

Google と Mozilla の原文を読むかぎり、ふつうの設定なら、利用者の操作は要らない書き方です。Safari と Edge は、Apple と Microsoft の告知が見つからず、確かめられませんでした（→「ブラウザーは、もう守られている？」）。

OS を更新すれば、Python や Node.js も直りますか？

道具が自分の信頼の名簿を持っていると、OS の更新だけでは直りません。26.2.2 より前の pip は、OS の側で信頼を外しても、中の certifi で信頼し続けます。Go と Node.js も、道具の側に止める一覧を入れています（→「道具の版を上げる（Python・Node.js・Go・Rust・Docker）」）。

ブラウザーで開けたので、自分のプログラムも大丈夫ですか？

ブラウザーで試して通っても、裏で動く道具が守られている証明にはなりません。curl で試しても、アプリが別の確かめ方を使うなら同じです（Cloudflare）。そのアプリが通る TLS の道で確かめます（→「上げたあとに気をつけること」）。

上げたら証明書のエラーが出ました。確かめを切ってもいいですか？

切らないでください。確かめを切ると、今回の更新が取り戻そうとしている守りが外れます（→「上げたあとに気をつけること」）。

自分の手元で確かめること（チェックリスト）

使っている道具の版を比べる。certifi 2026.10.19 以上、pip 26.2.2 以上、uv 0.13.4 以上、Node.js は 26系なら 26.12.1・24系なら 24.22.1・22系なら 22.23.4 以上、Go は 1.27 系なら 1.27.3・1.26 系なら 1.26.10 以上、Docker Desktop は最新（→「道具の版を上げる（Python・Node.js・Go・Rust・Docker）」）
Python を使っているなら、固定した版（requirements.txt やロックファイル）に、古い certifi・pip・uv が残っていないかを見る（→「Python・uv を使っている人は、何を上げる？」）
OS の ca-certificates を更新する。RHEL は、10月22日の時点ではまだ出ていなかったので、告知を待つ（→「OS とコンテナの証明書の一覧を更新する」）
コンテナのイメージを、取り直して作り直す（→「OS とコンテナの証明書の一覧を更新する」）
Java を使っているなら、Java の記事の手順で確かめる（→ Java の記事）
自分のサイトを持っているなら、openssl s_client の出力に emSign ECC Root CA - G3 などの名前が出ないかを見る。出たら、証明書を取り直す（→「サイトを運営している人は、何を確かめる？」）
上げたあとに証明書のエラーが出ても、確かめを切って直さない（→「上げたあとに気をつけること」）
Chrome・Firefox は、ふつうの設定なら何もしなくてよい。Firefox の一覧の配信を方針で止めている・届かない環境なら、158.0.1・ESR 153.5.1・115.43.1 以上か確かめる。Safari・Edge は、告知が見つかっていないので、各社の更新の案内を見る（→「ブラウザーは、もう守られている？」）

まとめ

2026年10月17日（UTC）に、認証局の中間証明書8枚（Web 用6枚・コード署名用2枚）の秘密鍵が漏れている、という届けがあった。原因の言い方は分かれていて、Google は「乱数が足りない」、Mozilla は「鍵を作る手順の欠陥」、この認証局は「正確な根本原因はまだ確かめていない」と書いている
Chrome（CRLSet）と Firefox（OneCRL）は、10月17日に止めた。Chrome は更新も再起動も要らない。Safari・Edge・macOS・Windows は、Apple と Microsoft の告知が見つからず、確かめられなかった
ブラウザーの外の道具の多くは、失効の知らせを受け取らないので、道具の版を上げて、中の信頼の名簿（や止める一覧）を入れ替える。certifi 2026.10.19 以上・pip 26.2.2 以上・uv 0.13.4 以上・Go 1.27.3/1.26.10 以上・Node.js 26.12.1/24.22.1/22.23.4 以上・Docker Desktop は出るたびに。外したものは道具ごとに違う
OS は、Ubuntu・Debian・Alpine・Fedora が出ていて、RHEL は10月22日の時点ではまだ。コンテナのイメージは作り直す。Java は別の記事
悪用は、Google が、ブロックより前に6枚につながる証明書は CT に1枚も記録されておらず、CT を求める相手には偽の証明書は使えなかった、と書き、Cloudflare が「自社のサービスでは見つかっていない」と書いている。一方、鍵を割り出して公開した人がいると Mozilla が書き、ブラウザーの外の道具が狙われたかは分からない、とテストのサイト（二次の資料）が書いている。「確認されていない」は「されていない」の証明ではない
サイト運営者は、チェーンに emSign ECC Root CA - G3 などの名前が出ないかを見て、出たら証明書を別の根につながる認証局の物に取り直す。証明書のエラーが出ても、確かめは切らない
この記事で確かめていないこと:
- Safari・Edge・macOS・Windows の、Apple・Microsoft 自身の告知。探したページは、Apple のセキュリティ更新の一覧（最新は2026年9月28日の行）、Apple の信頼の根の一覧のページ（2025年12月17日の公開のまま）、Microsoft の Trusted Root Program のリリースノート（2025年9月の告知まで）。Edge が Chrome と同じ仕組みを使うかも、Microsoft の文書では確かめられなかった
- macOS に入っている curl・git などが失効を見ないという話は二次の資料だけで、Apple の言葉は見つからなかった
- Firefox 158.0.1 が再起動で上がると書いた Mozilla の文書（サポートのページが読めなかった）と、Mozilla のセキュリティのブログ（開けなかった）
- RHEL の直ったパッケージ（Red Hat の手当ての Knowledge Base の記事も開いていない）。Fedora で emSign ECC Root CA - G3 が Web 用の根として外れたか。Alpine 3.19 以前
- Docker の公式イメージが作り直された日と、どのタグの pip が直ったか。Docker の文書に「Engine を上げてもイメージの中の ca-certificates は変わらない」という一文は見つからなかった
- uv が入れる Python が使う束