rancher-desktop

eMudhra中間CAの秘密鍵漏えいに対して、手元のMacで何をしたか eMudhra中間CAの秘密鍵漏えいに対して、手元のMacで何をしたか 2026年10月20日に、eMudhraの中間CA証明書8枚の秘密鍵が漏えいしたと公表されました。 この記事では、この事象に対して、開発用のMac1台で実際に何を確認し、何を直したかを順に書きます。 :::note info この記事は、2026年10月25日現在におこなった対応をまとめたものであり、それ以降に発見された脆弱性への対応は記載していません。 これなどは未対応です・・・ x.com ::: どんな事件？ eMudhraが発行した中間CA証明書8枚について、秘密鍵が誤った方法で生成されていました。 この鍵は証明書の情報から第三者が復元できるため、鍵を手に入れた人はどのWebサイトやサービスにもなりすませます。 該当の証明書は、2025年4月の作成時点から復元可能だったとされています。 (話題になり始めた時のツイート) x.com ブラウザ側はすでに対処済みで、FirefoxとChromeは10月17日、Appleは19日、Microsoftは20日から、この中間CAをブロックしています。 一方で、失効情報を参照しないクライアントは、ソフトウェア自体を更新しないと中間CAを信頼し続けます。 curlやgit、Pythonのpipなど、ブラウザ以外の道具がこれに当たります。 出典は公表文書（eMudhra Intermediate CA Compromise）です。 emudhra.we-have-a-problem.com やるべきことを一言で 信頼できないCAを信頼しないようにする、です。 信頼の判断は、OSの信頼ストア、各言語やツールが同梱するCAバンドル、コンテナ内の信頼ストアの3か所に分散しています。 どこか1か所でも古いままだと、そこ経由の通信だけ侵害された中間CAを受け入れます。 確認には、公表文書にあるテスト用ホストへ2本とも接続します。 2本は別のルートを経由するため、片方だけ直っている状態がありえます。 curl https://dv-g3b-emudhra.we-have-a-problem.com/ # emSign ECC Root CA - G3 経由 curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ # AAA Certificate Services 経由 両方とも SSL certificate problem（curlの終了コード60）などの証明書エラーになれば、そのクライアントは問題の中間CAを信頼していません。 HTTP 404や500が返る場合も、TLSは成立しているので未対策です。 curl以外のツールは、同じURLをそのツールの方法で叩いて確かめます（pipなら --index-url に指定するなど）。 対応 OSアップデート macOSを26.7.1に更新し、その後27.0.1へ更新しました。 26の段階で該当ルート2つをcert.pemから除去しました。しかし、27.0.1に更新すると、/etc/ssl/cert.pem が元の状態に戻り、2つのルート（AAA Certificate Services と emSign ECC Root CA - G3）が再び入っていました。 標準のcurlはこのファイルを参照するため、更新後に確認用の2本へ接続できてしまいました。 公表文書の回避策（該当のルート2つをこのファイルから取り除くコマンド）を、更新のたびに再実行する必要があります。 emudhra.we-have-a-problem.com 公表文書のコマンドは、退避してからその場でファイルを上書きします。 実行前に結果を確かめたかったので、一時ファイルに書き出して中身を検証してから置き換える形にしました。 更新のたびに実行するため、退避ファイル名には日付を付け、前回の退避を上書きしないようにしています。 t=$(mktemp) && awk '/^(===|###) /{skip=0} /^=== .*\/CN=(AAA Certificate Services|emSign ECC Root CA - G3)$/{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo cp -p /etc/ssl/cert.pem "/etc/ssl/cert.pem.bak-$(date +%Y%m%d)" && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t" 除くのは AAA Certificate Services と emSign ECC Root CA - G3 の2つです。 片方だけ除くと、除かなかったルート経由の確認用ホストに接続できてしまいます。 実際に、emSign ECC Root CA - G3 だけを除いたファイルでは、dv-g3b-aaa-emudhra への接続が成功しました（curlの終了コード0）。 2つとも除いたファイルでは、2本とも終了コード60になります。 ブラウザのアップデート 公表文書は、ブラウザとOSを最新にするよう案内しています。 ブラウザ側は失効情報の配布機構（OneCRL、CRLite、CRLSets）で対処済みです。 ブラウザ上で先ほどのサイトを開き、did not connectになれば、ブラウザ上は問題ないようです。 !スクリーンショット 2026-10-25 20.53.24.png macOSのネイティブpipなどの対応 macOS標準の curl、git、python3、perl、ruby、openssl は、失効確認をせずに /etc/ssl/cert.pem で証明書を検証します。 このファイルから該当ルートを除く回避策を適用し、curlとgitとpython3が確認用の2本を拒否することを確かめました。 標準のpip3は、このファイルを使わず、自前の古いバンドルを使います。 Command Line Toolsに入っているPython 3.9は、pipを修正版の26.2.2に上げられません。 そこで公表文書の手順どおり、標準のpython3の sitecustomize.py に PIP_CERT=/etc/ssl/cert.pem を設定し、pipに修正済みのファイルを使わせました。 この設定はmacOSの更新後も残っていました。 Homebrewとcertifiの更新 Python環境側は、certifi を2026.10.19、pip を26.2.2に更新しました。 対象は、miniforgeの各環境、asdfで入れたPython、pipenvの仮想環境です。 プロジェクトの Pipfile.lock は古い版を固定したままなので、pipenv sync で古い版に戻ります。 Homebrewは、ca-certificates が2026-10-20版、nss が3.131.1から3.132へ更新済みです。 そのほかのformulaは、公開から1週間以上経った版だけを入れる方針で更新しました。 Rancher Desktop周りの対応 Rancher Desktopは、コンテナ管理用のツールになりますが、これによって作成される環境には、問題が2つありました。 rancherdesktop.io 1つ目は、起動のたびに、macOSのキーチェーンにあるルート証明書がVMへ注入し直される点です。 VM内のAlpineの ca-certificates を修正版（20261020-r0）に上げても、この経路で2つのルートが再び信頼ストアに入りました。 VMを再起動するたびに、ca-certificates の更新、該当ルート2枚の除去、dockerdの再起動を行うスクリプトを実行しています。 実行後に、VM内から確認用の2本が拒否されることを確かめます。 <details><summary>VMの再起動のたびに実行するスクリプト</summary> #!/bin/bash # Rancher Desktop VM の信頼ストアから、問題の2つのルートを外す（VMの再起動のたびに実行） # 使い方: RESTART_DOCKER=1 bash rd_vm_fix.sh set -u RDCTL=$(command -v rdctl 2>/dev/null || echo "$HOME/.rd/bin/rdctl") "$RDCTL" shell true >/dev/null 2>&1 || { echo "Rancher Desktop VM が起動していません"; exit 1; } "$RDCTL" shell sudo sh -c ' # Alpineのca-certificatesを修正版へ更新 apk upgrade -q ca-certificates ca-certificates-bundle 2>/dev/null mkdir -p /root/emudhra-removed # キーチェーンから注入された証明書のうち、問題の2つを退避 for f in /usr/local/share/ca-certificates/*.crt; do s=$(openssl x509 -in "$f" -noout -subject 2>/dev/null) case "$s" in *"CN=AAA Certificate Services"*|*"CN=emSign ECC Root CA - G3"*) echo "remove $(basename "$f"): $s"; mv "$f" /root/emudhra-removed/ ;; esac done update-ca-certificates >/dev/null 2>&1 apk info -v 2>/dev/null | grep "^ca-certificates-[0-9]" # 確認用の2本が拒否される（curlの終了コード60）ことを確認 for h in dv-g3b-emudhra dv-g3b-aaa-emudhra; do curl -sS -o /dev/null --max-time 12 https://$h.we-have-a-problem.com/ 2>/dev/null [ $? -eq 60 ] && echo "OK (拒否) $h" || echo "NG (接続できる/不明) $h" done ' # dockerdは起動時に信頼ストアを読むため、反映にはVM内でdockerサービスの再起動が必要 # （Rancher Desktop自体の再起動だと、また注入し直される） if [ "${RESTART_DOCKER:-0}" = 1 ]; then echo "dockerd を再起動します (実行中コンテナは止まります)" "$RDCTL" shell sudo rc-service docker restart else echo "dockerd に反映するには: RESTART_DOCKER=1 bash $0" fi </details> 2つ目は、コンテナのイメージです。 OSの信頼ストアは、Debian 13とUbuntu 24.04のイメージでは問題ありませんでした。 Alpineは修正版が出ています。 残っていたのは、公式の python:3.11-slim と python:3.12-slim に入っているpip（24.0と25.0.1）が同梱するcertifiでした。 同じイメージの中で、Python本体は確認用ホストを拒否するのに、pipは接続できました。 この2つは配布元の最新イメージでも同じ状態です。再ビルドだけでは直りません。 そこでDockerfileに、OSの信頼ストアを指定してpipを更新する行を足しました。 RUN pip install --no-cache-dir --cert /etc/ssl/certs/ca-certificates.crt -U pip python:3.12系のpip 25.0.1は、--cert を指定しても同梱の古いcertifiを一緒に信頼しました。 3.12系では、この行だけではpipを更新する通信自体が守れません。 同梱のcertifiファイルをOSの信頼ストアで置き換えてからpipを更新する形にしています。 dbt-snowflake周りの対応 dbt-snowflake 1.9.4と1.12.3は、依存関係で certifi<2025.4.26 を要求します。 ベースイメージを最新にしても古いcertifiに固定されるため、依存関係を入れたあとにcertifiを上書きする1行を追加しました。 再ビルドは --pull --no-cache で行います。 キャッシュが効くと、古いaptやpipのレイヤーが残るためです。 Dependabotは FROM のタグしか見ず、RUN の中の apt-get や pip install は追いません。 ちなみに、dbt-snowflakeが古いバージョンを要求する件については、現在は修正済みのようです。 dbt-adapters#2230 dbt-adapters#2241 残り VS Code VS Codeに含まれるElectronが古いままです。 公表文書が示すElectronの修正版は、44.9.1、43.8.1、42.11.16です。 手元のVS Codeは43.7.7で、修正版に届いていません。 VS Codeの更新が配布されるのを待っています。 Claude.app（Electron 44.9.0）も同じ状態です。 Claude.appは、アプリ内に独自の「信頼しない証明書」一覧を持っていることを、アプリの中身で確認しました。 ただし、実際に確認用ホストへ接続して拒否されるかは試せていません。 Rancher Desktop Rancher Desktop本体は、まだ修正版が出ていません。 修正の追跡は、次のissueで行われています（2026年10月25日時点）。 rancher-desktop#11197 このissueは「Open」で、マイルストーンは1.25です。 Development欄にリンクされたブランチやPull Requestはありませんが、このissueを参照するコミットが2件あります。 本体が修正版になるまでは、VMを起動し直すたびに前述のスクリプトを実行します。 まとめ - eMudhraの中間CA 8枚の秘密鍵が復元可能だったため、失効情報を見ないクライアントは、ソフトウェアを更新しないと偽の証明書を受け入れる。 - 確認は、テスト用ホスト2本へ接続して、2本とも証明書エラーになるかで行う。 - OS、各言語のcertifiとpip、コンテナのイメージが、それぞれ別の信頼ストアを持つため、場所ごとに直して確認する。 - 更新で元に戻るものがある。macOS更新後の /etc/ssl/cert.pem と、Rancher Desktop再起動後のVMは、毎回確認する。 - ElectronアプリとRancher Desktop本体は、配布元の修正待ち。 参考情報 - eMudhra Intermediate CA Compromise（2026年10月20日の公表文書） - rancher-desktop#11197

Need containers on your laptop without a complicated setup? 🐳 Rancher Desktop brings container management and local Kubernetes to Windows, macOS and Linux. 🖥️ rancher-sandbox/rancher-desktop #DevTools #浇朋友 #蓝朋友 #互关 #fo

本地跑容器，还得记一堆命令？🐳 Rancher Desktop 用图形界面管理容器镜像，并提供本地 Kubernetes 环境。适合开发调试。🖥️ rancher-sandbox/rancher-desktop #Docker #浇朋友 #蓝朋友 #互关 #fo