先に要点
- 2026年10月、認証局 eMudhra が運用する中間CA 8つの秘密鍵が漏えいしていたことが分かりました。悪用されると、他人のサイトの HTTPS 証明書を偽造できるおそれがあります。
- Chrome・Firefox・Apple は報告から数時間〜数日で遮断済みで、Chrome は「遮断前に偽の証明書が公開ログ（CT）に載った例は無い」としています。ブラウザを最新にしていれば、利用者側の作業はほぼ不要です。
- 残る穴は、ブラウザ以外が自前で持つ「信頼する証明書の一覧」です。Python の certifi・Node.js・OS の ca-certificates・Mac のコマンドラインのツール・機器などは、更新するまで古い一覧のままです。
- 自分のサイトの証明書が eMudhra（emSign）から発行されたものなら、ブラウザ以外の相手から接続できなくなる場合があるので、別の認証局での取り直しを検討します。
HTTPS の証明書は、「信頼できる認証局（CA）が発行した」ことで本物だと判断されます。その認証局の中でも、実際に証明書に署名している中間CAの秘密鍵が外に漏れると、その鍵を持つ人はどのサイトの名前でも、本物に見える証明書を作れてしまいます。2026年10月に明らかになった eMudhra の件は、まさにこの状態でした。
この記事では、Mozilla・Chrome の認証局の審査の担当（Root Program）・Apple の公式の発表（2026年10月26日に確認）をもとに、何が起きたか、どこまで対応済みで、どこに穴が残るか、自分の環境で確かめることを整理します。証明書の基本は デジタル証明書とは で解説しています。
何が起きたか：中間CAの秘密鍵の漏えい
eMudhra はインドの認証局で、emSign という名前のルート証明書を運用しています。2026年10月17日に、eMudhra の中間CA 8つの秘密鍵を入手できることが研究者から各社に報告されました。Mozilla は「鍵を握っていることの証明は本物だった」と確認し、Mozilla と Chrome は、ほかの認証局で同じ問題は見つかっていないとしています。
| 項目 | 内容 |
|---|---|
| 漏えいした鍵 | eMudhra の中間CA 8つ（Web サイト用の TLS が6つ、コード署名用が2つ） |
| 報告 | 2026年10月17日（UTC） |
| 危険 | 他人のサイトの HTTPS 証明書を偽造できる。偽のサイトや通信の盗み見に使われうる |
| 遮断前の悪用 | Chrome は「遮断の前に、この6つにつながる TLS 証明書が CT に記録された例は無い」と発表 |
| ほかの認証局 | Mozilla・Chrome とも、同じ問題は見つかっていないとしている |
CT（Certificate Transparency） は、発行された証明書を公開のログに記録する仕組みです。Chrome などのブラウザは、ログに載っていない証明書を原則として信頼しないので、ログに載っていなければ、ブラウザでは偽の証明書が通らなかったことになります。
各社の対応：ブラウザは遮断済み
ブラウザ各社は、報告から数時間〜数日で対応しています。どれも自動で配られる仕組みなので、通常の設定なら利用者が何かをする必要はありません。
| 提供元 | 対応 |
|---|---|
| Chrome | 報告から約2時間後（10月17日）に、CRLSet（ブラウザに配る失効の一覧）で6つの TLS 用の中間CAを遮断。今後の Chrome Root Store（バージョン43）で、署名元の eMudhra のルート証明書も外す予定 |
| Firefox | 報告から3時間以内（10月17日）に OneCRL で遮断。10月20日に Firefox 158.0.1・ESR 115.43.1・ESR 153.5.1 も公開 |
| Mozilla の信頼の一覧（NSS） | NSS 3.131.1 で emSign ECC Root CA - G3 などのルート証明書を削除。Firefox 以外でこの一覧を使うソフトを守るため |
| Apple | 10月19日から12の中間証明書を、10月23日から emSign ECC Root CA - G3 を、設定データの自動更新で遮断（Safari・メール・Apple の通信の仕組みを使うアプリ） |
穴が残るところ：ブラウザ以外の「信頼する証明書の一覧」
ブラウザは自分で失効の一覧を配るので素早く守れますが、サーバーやプログラムの多くは、信頼する証明書の一覧（トラストストア）を自前で持っていて、失効の確認もしないことがあります。この場合、一覧を更新するまで、遮断されたはずの中間CAにつながる証明書を信頼し続けます。Mozilla も、失効を確認しないソフトは影響を受けうるとして、一覧の更新を呼びかけています。
どこで更新が要るか（2026年10月26日時点）
ブラウザ
Chrome・Firefox・Safari は自動の仕組みで遮断済み。
- 最新の版にしておけばよい
- 独自の設定で自動更新を止めている場合は Firefox 158.0.1 などに更新
Python（certifi）
requests などが使う certifi は Mozilla の一覧をもとにしている。
- 2026.10.23 で emSign ECC Root CA - G3 を削除
- pip で更新し、プロセスを再起動
Node.js
同梱のルート証明書を NSS 3.131.1 に更新した版。
- HTTP2Shell の修正版と同じ版
- --use-system-ca を使うなら OS 側の一覧が対象
OS・Mac のコマンドライン
Linux の ca-certificates や Mac の /etc/ssl/cert.pem は、それぞれの更新を待つ。
- Apple は Mac の curl・git・python3 などは今後の更新まで対象外と明記
- ディストリビューションの更新情報を確認
Python は 3.15.2・3.14.10・3.13.18・3.12.16・3.11.18 で、ssl モジュールが漏えいした eMudhra の中間CAの鍵を最後の守りとして拒否するようにしました（CVE-2026-115557、Python の公式の告知）。告知では、これで pip の通常の利用も、更新前の pip のままでもこの鍵を使った攻撃から守られるとしています。3.15.2 と 3.14.10 はインストーラーがあり、3.13.18 以前はソースでの提供です。certifi や OS の一覧の更新とあわせて、Python 本体も上げておきます。
このほか、Java の cacerts、Go のプログラムに組み込んだ一覧、コンテナのベースイメージ、ネットワーク機器やアプライアンスなど、独自の一覧を持つものはすべて同じ扱いです。どれが eMudhra のルート証明書を含んでいるかは製品ごとに違うので、提供元の情報を確かめます。
自分の環境で確かめること
確かめることは2つあります。自分が使っている一覧が更新されているかと、自分のサイトの証明書が eMudhra から発行されていないかです。
# Python：certifi の版（2026.10.23 以降なら削除済み）
python -m pip show certifi
# Node.js：同梱の一覧が NSS 3.131.1 の版（22.23.4 / 24.22.1 / 26.12.1）
node -v
# Debian・Ubuntu：OS の一覧の版と更新
dpkg -l ca-certificates
sudo apt update && apt list --upgradable 2>/dev/null | grep ca-certificates
# 自分のサイトの証明書の発行元（issuer）を見る
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "s:|i:"
最後のコマンドの i: の行に eMudhra や emSign が出てくる場合は、その証明書は今回の影響を受ける系列です。example.com の部分は自分のドメインに置き換えます。
確認と対応の順番
自分のサイトの証明書が eMudhra のものだった場合
Mozilla は、信頼の一覧からルート証明書を外したことで、Firefox 以外の利用者から一部のサーバーにつながらなくなると注意しています。ルート証明書を外した一覧を使うプログラムや API の利用者からは、そのサイトの証明書を信頼できなくなるためです。
eMudhra の証明書を使っている場合は、別の認証局で証明書を取り直して入れ替えるのが確実です。無料の Let’s Encrypt などに切り替えるなら、更新の自動化もあわせて設定します（ACME のチャレンジの種類と自動化）。証明書の入れ替えの注意点は SSL証明書の更新 でも整理しています。
Apple は、Mac の curl・git・python3・ruby・perl・openssl などが参照する /etc/ssl/cert.pem は、今後のソフトウェアの更新まで今回の遮断の対象外だと説明しています。手でルート証明書を外す方法も案内していますが、一部のサイトの確認が失敗するおそれがあり、macOS の更新で元に戻ることもあるとしています。手順は Apple のサポートのページに従い、必要がなければ更新を待つのが無難です。
eMudhra の中間CAの侵害についてよくある質問
Q. 普通にブラウザを使っているだけです。何かする必要はありますか？
A. ブラウザを最新の状態にしていれば、特別な作業は要りません。Chrome・Firefox・Safari は自動で配られる仕組みで遮断済みです。会社のパソコンで自動更新を止めている場合は、管理者に更新を確認してください。
Q. 遮断の前に、偽の証明書で攻撃された可能性はありますか？
A. Chrome は、遮断の前にこの6つの中間CAにつながる TLS 証明書が CT のログに記録された例は無いと発表しています。CT を確認するブラウザでは、偽の証明書は通らなかったことになります。一方、CT も失効も確認しないプログラムについては、各社の発表は「影響を受けうる」としているだけで、悪用の有無は分かっていません。
Q. 自分のサーバーが外部の API を呼ぶだけでも関係がありますか？
A. 関係があります。外部の API に HTTPS でつなぐプログラムは、その相手の証明書を自分の一覧で確かめています。一覧が古いと、攻撃者が偽の証明書で相手になりすました場合に見抜けません。Python の certifi や Node.js、OS の ca-certificates を更新しておきます。
Q. HTTP2Shell の対応で Node.js を上げました。これも済んでいますか？
A. Node.js 22.23.4・24.22.1・26.12.1 は、同梱のルート証明書も NSS 3.131.1 の内容に更新されているので、今回の対応も含まれています。HTTP2Shell については HTTP2Shellとは？ で整理しています。
まとめ
- eMudhra の中間CA 8つの秘密鍵が漏えいし、他人のサイトの証明書を偽造できる状態でした。
- Chrome・Firefox・Apple は数時間〜数日で遮断し、Chrome は遮断前に偽の証明書が CT に載った例は無いとしています。
- 穴が残るのは、ブラウザ以外が持つ信頼の一覧です。certifi（2026.10.23）、Node.js（22.23.4 / 24.22.1 / 26.12.1）、OS の ca-certificates、機器の一覧を更新します。
- 自分のサイトの証明書が eMudhra のものなら、別の認証局で取り直します。
参考リンク
- Mozilla: Protecting Firefox users following the compromise of eMudhra intermediate certificates
- Mozilla dev-security-policy: Compromised eMudhra Intermediate Certificates（Mozilla と Chrome Root Program の告知）
- Mozilla Bugzilla: eMudhra: Private key compromise of Intermediate Certificates
- Apple: About the compromised eMudhra intermediate CAs
- Node.js: crypto: update root certificates to NSS 3.131.1
- certifi: certifi（PyPI）
- Python: Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 are out