「Windowsも更新した方がいい？」「Chromeでは見られるのに、curlやpipで証明書エラーが出る」。eMudhra（イームドラー）の証明書問題では、使うソフトによって確認する場所が違います。
まずはOSとブラウザーを更新。Python・Node.js・Dockerを使う人は、その環境も別に確認してください。ブラウザーの対策が済んでいても、開発ツールの証明書一覧が古いまま残ることがあります。
この記事は2026年10月23日時点の公式発表・開発元資料を基に整理しています。掲載コマンドは確認手順であり、筆者のWindows・macOS実機で実行した結果ではありません。
eMudhra証明書問題で何が起きた？
eMudhraは、8件の中間認証局（中間CA）に関連する鍵の生成工程に不具合があり、弱い鍵が作られたと説明しています。同社はインフラへの侵入とデータ漏えいを否定し、根本原因を調査中です。［1］eMudhra：10月21日公式声明
証明書は、接続先が本物かを確認するための「身分証」に似ています。中間CAは、その身分証にお墨付きを与える発行者です。今回は公開された証明書から、秘密鍵を復元できる弱さが問題になっています。その秘密鍵を第三者が再現できると、偽のサイトにも本物らしい証明書を作れてしまいます。
Mozillaは、この鍵を持つ攻撃者が偽のHTTPS証明書を発行し、通信経路に介入できる場合には、サイトへのなりすましや通信の読み取り・改変につながると説明しています。今回の発表だけで、自分の情報が漏れたと分かるわけではありません。［2］Mozilla：Firefox利用者の保護
10月22日には、eMudhraがグローバルSSL/TLS証明書事業からの撤退を発表しました。既存顧客には移行支援を行い、発行済み証明書が有効期限を迎えるか交換されるまで、失効情報などのサービスを継続するとしています。［11］eMudhra：10月22日SSL/TLS証明書事業撤退の発表
Windows・Chrome・curl・pipの対応早見表
以下の番号は「本件の対応を含むことを確認できた版」の目安です。今から更新する場合は、利用中の系列で提供されている最新の対応版を選んでください。
| 使っているもの | 確認・更新する場所 | 判断のポイント |
|---|---|---|
| Windows | Windows Updateと証明書信頼リストの配信状態 | 更新履歴だけで全アプリの対策完了とは判断しない |
| Chrome・Edge | ブラウザーの更新画面、公開チェッカー | 閲覧できることだけを安全判定に使わない |
| Firefox | 最新版への更新、公開チェッカー | 標準設定ではOneCRLで遮断済み。独自設定の環境も更新する |
| macOS | ソフトウェアアップデートと各アプリ | Safariとターミナルのツールを別々に確認 |
| curl | curl -V、TLSライブラリ・CA一覧 | Schannel版と独自CAファイル利用版で確認先が違う |
| Python certifi | 2026.10.19以降の対応版を確認 | 仮想環境やアプリ同梱版を含めて確認 |
| pip | 26.2.2以降の対応版へ更新 | 通常のcertifiとは別にpip自身も更新 |
| Node.js | 26.12.1／24.22.1／22.23.4 | 自分が使う系列の対応版へ更新 |
| Docker Desktop | 最新パッチ版とリリースノート | 段階的に修正中。コンテナー内部も別途更新 |
| Java | JDK配布元の更新と実際のtruststore | 独自のcacertsやアプリ同梱JREも確認 |
修正版の根拠：［4］certifi：GitHubセキュリティアドバイザリー／［5］pip：26.2.2変更履歴／［6］Node.js：10月21日セキュリティ更新。Dockerは4.96.2・4.96.3のリリースノートに対策を記載していますが、残るコンポーネントも後続パッチで扱うと説明しています。［10］Docker Desktop：リリースノート
一般の利用者：まずOSとブラウザーを更新する
Windowsは「更新済み」の表示だけで判断しない
Windowsの設定から「Windows Update」を開き、利用可能な更新を適用します。Chrome・Edge・Firefoxも、それぞれのメニューからバージョン情報・更新画面を開いて確認してください。
Windowsには、信頼する証明書や信頼しない証明書のリストを自動配信する仕組みがあります。組織の設定で配信が制御・無効化される場合もあるため、管理対象PCや長期間オフラインだったPCはIT担当者に確認してください。［12］Microsoft：Windowsの証明書信頼管理
Firefox・Chromeの遮断と、OS全体の更新は別
Mozillaは、Firefoxの標準設定の利用者にはOneCRLで遮断情報を配信したと公表しています。ChromeもCRLSetで問題のTLS用中間CAの鍵を遮断したと説明しています。どちらも、初動の保護にブラウザーの更新や再起動は必要なかったとしています。［2］Mozilla：Firefox利用者の保護／［3］Mozilla公開フォーラム：Mozilla・Chrome Root Programの説明
ただし、ブラウザー内の保護が、そのPC上のPythonやcurlへそのまま適用されるとは限りません。macOSでも、OS・Safariと、ターミナルで動くツールの確認を分けて考えます。
公開チェッカーの使い方：接続できない方がよい場合がある
技術者向けのeMudhra公開チェッカーをChrome・Edge・Firefoxなど、確認したいブラウザーごとに開き、「Run check」を実行します。これはメーカーの公式診断画面ではなく、本件の技術情報をまとめた外部の確認サイトです。
| 結果 | 読み方 |
|---|---|
| 問題の証明書を拒否した | その試験では接続が遮断された。失効確認・CT（証明書を公開ログへ記録する仕組み）などの仕組みで拒否される場合がある |
| 問題の証明書で接続に成功した | その接続経路では受け入れている。ソフトとCA一覧の更新を確認 |
| タイムアウト・名前解決失敗 | 証明書の安全性は判定できない。通信制限やDNSなどを確認 |
通常の銀行・通販サイトで出た証明書警告を「安全の証拠」と読み替えないでください。拒否されることを確認するのは、問題の証明書を意図的に使った試験先です。また「No CT」の試験だけを拒否しても、中間CA自体の遮断が済んだとは断定できません。［7］技術者向け公開チェッカー・対応状況
curlで確認する方法：Windowsではcurl.exeを指定
WindowsのPowerShellでは、別のコマンドと混同しないよう、curl.exeと明記します。まず版とTLSライブラリを確認し、続けて2つの試験先へ接続します。
curl.exe -V
curl.exe --connect-timeout 10 --max-time 20 https://dv-g3b-emudhra.we-have-a-problem.com/
curl.exe --connect-timeout 10 --max-time 20 https://dv-g3b-aaa-emudhra.we-have-a-problem.com/macOS・Linuxでは、上記のcurl.exeをcurlに置き換えます。この2つは証明書のつながり方が異なる試験先です。両方を確認しても全環境の安全証明にはなりませんが、片方だけの確認による見落としを減らせます。
結果が証明書の失効や信頼できない発行元などを理由に拒否された場合は、その試験の接続を遮断できています。curl: (60)は証明書検証の失敗を表す例ですが、番号だけで本件の対策済みとは判断せず、後に続く説明を読みます。タイムアウトやプロキシのエラーは判定保留です。
curl -VにSchannelと表示される版は、通常Windowsの証明書ストアを使います。一方、OpenSSLなどを使う版はCAファイルを参照する場合があります。curl本体のバージョンだけでなく、何を信頼元として使っているかが確認の要点です。［8］curl：証明書検証とCAストア
Python：certifiとpipを別々に更新する
使用中のPython環境を確認
次のコマンドはWindowsの例です。仮想環境を使っている場合は、その環境を有効にしてから実行します。macOS・Linuxでは環境に応じてpythonをpython3に置き換えてください。
python -c "import sys; print(sys.executable)"
python -m pip --version
python -m pip show certifi
python -c "import pip._vendor.certifi as c; print(c.__version__)"最後のコマンドはpipに同梱されたcertifiの確認です。配布元独自のpipでは同じ方法が使えない場合があります。certifiが見つからない場合は、通常パッケージとしては入っていない可能性があり、Python全体の安全判定はできません。
対応版へ更新し、版をもう一度確認
python -m pip install --upgrade pip certifi
python -m pip --version
python -m pip show certificertifiは2026.10.19で本件への対応を整理しています。pip 26.2.2は、内蔵するcertifiを2026.10.19へ更新しています。外側のcertifiを更新しただけでは、pip内部のコピーまで置き換わるとは限りません。［4］certifi：GitHubセキュリティアドバイザリー／［5］pip：26.2.2変更履歴
pipは設定や版により、OSの証明書ストアも併用します。PIP_CERTなどで独自のCAファイルを指定している場合も、そのファイルの更新が必要です。業務環境では依存関係や固定バージョンを確認し、仮想環境・コンテナーごとに更新してください。［9］pip：HTTPS証明書の検証方法
更新時に証明書エラーが出る場合は、PCの日時、プロキシ、社内CA、接続先の証明書を確認します。–trusted-hostや証明書検証の無効化で通す方法を、恒久対策にはしないでください。
Node.js・Docker・Javaはどこまで確認する？
Node.js：同じ系列の対応版へ
node --version
node -p "process.execPath"Node.js公式は、26.12.1／24.22.1／22.23.4にeMudhra関連のCA更新を含めています。22系を使っているなら22系の対応版など、利用中の系列に合わせて更新します。バージョン管理ツールやアプリ同梱版も確認し、更新後は稼働プロセスを再起動してください。［6］Node.js：10月21日セキュリティ更新
Docker：Desktopとコンテナー内部は別
Docker Desktopを最新のパッチへ更新し、リリースノートの追加対応も確認します。ホスト側を更新しても、既存イメージに入っているca-certificatesやcertifi、Node.jsは自動では入れ替わりません。ベースイメージと依存パッケージを更新し、再ビルド・再配置して確認します。
Java：実際にアプリが使うJREと証明書ストアを確認
java -versionこの表示は、コマンドから呼ばれたJavaの版です。業務アプリが別のJREや独自truststoreを使っていれば、確認先も変わります。配布元の本件対応情報とアプリの起動設定を照合してください。Javaの全配布元に共通する更新番号は、この記事では示しません。
HTTPS接続できない・pip証明書エラーが出るときの切り分け
| 症状 | 先に確認すること |
|---|---|
| 特定サイトだけ開けない | サイト側の証明書・チェーン交換状況。警告画面から強行しない |
| ブラウザーは開けるがcurlは失敗 | TLSライブラリ、CAファイル、プロキシの違い |
| pipのCERTIFICATE_VERIFY_FAILED | pip版、同梱certifi、OS側CA、独自CA設定 |
| Docker内だけ失敗 | コンテナー内のCA・言語ライブラリとイメージ作成日 |
| 更新後も動かない | 実行ファイルの場所、別の仮想環境、常駐プロセスの再起動 |
証明書エラーは、期限切れ、日時のずれ、社内プロキシなどでも起きます。エラー文だけでeMudhraが原因とは断定できません。発生した接続先・ツール・エラー全文をそろえると、利用者側かサイト側かを切り分けやすくなります。
Webサイト管理者は証明書の発行元とチェーンを確認
自社サイトやAPIがemSign系の証明書を使っている場合は、証明書の発行元だけでなく、中間CAからルートCAまでのチェーンを確認し、契約先へ交換要否を問い合わせます。証明書の有効期限が残っていても、利用者側で信頼対象から外れると接続できなくなるためです。
確認時の識別子にはemSign ECC Root CA – G3があります。ただし、名前が「emSign」で始まる証明書をすべて同一扱いにはできません。クロス署名によって別のルートへつながる場合もあるため、対象の中間CA・鍵と接続経路で確認します。［3］Mozilla公開フォーラム：Mozilla・Chrome Root Programの説明
サイト閲覧だけの人はOSとブラウザーの更新から。PythonやDockerを使う人は、普段動かしている環境まで確認する。今回の対応は、この順番で進めると確認漏れを減らせます。
出典・更新情報
確認日：2026年10月23日。更新状況は各配布元の案内を優先してください。以下は記事作成で確認した一次資料と技術者向け確認ページです。
［3］Mozilla公開フォーラム：Mozilla・Chrome Root Programの説明
［4］certifi：GitHubセキュリティアドバイザリー
