eMudhra証明書の鍵漏えい｜Macのcurlを確かめて直す

「eMudhra の証明書が危ないと聞いたけれど、ブラウザが対応済みなら自分のMacは関係ないのでは」——Claude Code や Codex にコマンドを任せて開発している人ほど、この判断で止まりがちです。

結論から言うと、ブラウザは10月17〜22日に遮断済みですが、Mac 標準の curl・git・python3 や、古い Node.js は今も eMudhra の問題の中間証明書を信じています。自分の Mac が該当するかは、開示ページが用意した検証用ホストに1行のコマンドを当てれば3分で分かり、該当した道具は直った版へ上げれば済みます。

株式会社Fyveは、記事作成や定期処理を無人で回している Mac mini で、この確かめ方を実際に試しました。本記事では、その結果（標準の道具はすべてつながった）と、道具ごとの直し方を、一次情報の範囲でまとめます。

eMudhra の証明書で何が起きたのか

eMudhra（イーマドラ）はインドの認証局で、Webサイトの証明書を発行する会社です。問題になったのは、eMudhra の中間証明書8枚です。中間証明書とは、ルート証明書（OS やブラウザに最初から入っている信頼の起点）と、各サイトの証明書の間をつなぐ証明書のことです。

開示ページによると、この8枚は秘密鍵の作り方を誤っていました。原文は "The private keys for the intermediate certificates were incorrectly generated by the CA." で、その結果 "anyone can recover them from the certificates"、つまり公開されている証明書そのものから、誰でも秘密鍵を復元できる状態でした。

中間証明書の秘密鍵があれば、その中間証明書を信じている道具に対して、任意のサイトになりすました証明書を作れます。開示ページは「どのWebサイトやサービスにもなりすませる」と影響を説明しています。証明書は2025年4月に作られ、その期間の証明書の公開記録（CT ログ）には載っていなかったとされています。

日付の整理（2026年10月）

日付は開示ページの記載に合わせています。Mozilla のバグ管理には「eMudhra: Private key compromise of Intermediate Certificates」という件名の報告が 2026年10月18日（UTC）付で作られています。

ブラウザが守られても、ターミナルの道具は守られていない

ここがこの件のいちばん大事なところです。ブラウザ（Chrome・Firefox・Edge・Safari）は、証明書が CT ログに載っているかを確かめるうえ、遮断の情報（失効の一覧）もブラウザの会社から配られます。だから今回の8枚は、ブラウザではすでにエラーになります。

一方、開示ページは「ブラウザの外の多くの道具は CT を確かめない」と書いています。さらに多くの道具は失効の確認もしません。手元の証明書の一覧に問題の証明書の親（ルート証明書）が入っていて、それを外す更新が来ていなければ、ターミナルの道具は今も問題の中間証明書を信じたままです。

Mac で影響を受ける道具

開示ページが macOS について挙げているのは次のとおりです。

• macOS 標準の curl・git・python3・perl・ruby・openssl：/etc/ssl/cert.pem という証明書の一覧を読みます。このファイルは更新されておらず、失効も確かめません
• macOS 標準の pip3：自分用の古い証明書の一覧を持っています
• Node.js・Python の certifi・Docker Desktop など：それぞれが自前の証明書の一覧を持つため、道具ごとに更新が要ります

AI に開発を任せている人ほど関係がある理由

Claude Code や Codex は、作業の途中で curl・git・python3・npm・pip を裏で何度も呼びます。パッケージを入れる、API を叩く、リポジトリを取ってくる、といった処理です。これらはすべてブラウザではなく、上のリストの道具です。

つまり「ブラウザで開いたら警告が出たから安全」という感覚は、AI が動かすコマンドには当てはまりません。私たち自身、ふだんの開発では Claude Code にコマンドを任せきりにしていて、どの道具がどの証明書の一覧を読んでいるかを意識したことはほとんどありませんでした。

この記事を読んでいるあなたへ無料プレゼントClaudeのこの5つの設定、今すぐ見直した方がいい共有・学習・入力・権限・委任。事故が起きるのはこの5つだけ（全28ページ）

見落としやすい共有リストは3つある（3つ目は画面の下）学習をオフにしても残る、公式の例外条項権限モード6つの違いと、Shift+Tabでの切り替え方

無料でダウンロード

中身のプレビューを見る ↓登録すると、過去の特典もまとめて受け取れます（PDF 18点・合計468ページ ＋ すぐ使えるzip素材 3点）

私たちの Mac mini で確かめた結果

2026年10月23日の朝、記事作成や定期処理を無人で回している Mac mini（macOS 15.5）で、開示ページの検証用ホストに道具ごとにつないでみました。結果は次のとおりです。

検証用ホストは4つ（通常・AAA 系、それぞれに CT なし）あり、標準の curl は4つすべてにつながりました。試した道具はすべて、問題の中間証明書を信じている状態でした。

あわせて分かったことが3つあります。

• /etc/ssl/cert.pem は2025年5月4日付のままで、中に入っている証明書は128枚でした（grep -c "BEGIN CERT" で数えた値）。Apple がこのファイルを更新するまで、標準の道具は直りません
• Node.js は v22.23.1 で、直った版の 22.23.4 より前でした。別に入れた Python 3.13 の環境の certifi も 2026.07.22 で、直った版（2026.10.19）より前です
• Claude Code は 2.1.296 で、開示ページが直った版として挙げる 2.1.303 より前でした。この Mac は定期処理を止めないために更新のタイミングを手で決めていて、それが今回は遅れにつながっていました

Claude Code の更新履歴を見ると、2.1.303 の項目は「Bug fixes and reliability improvements」の1行だけで、証明書の話は書かれていません。開示ページの一覧を見なければ、この版が今回の問題の修正を含むとは気づけませんでした。更新履歴に載らない修正の見つけ方は、別の記事でも扱っています。

Claude Code更新履歴に載らない修正｜Plugin4Shellと自動更新

なお、これは私たちの Mac mini 1台での結果です。macOS の版や、Homebrew で入れた curl を使っているかどうかで結果は変わります。だからこそ、次の手順で自分の Mac を確かめてください。

自分の Mac での確かめ方（3分）

開示ページは検証用のホストを用意しています。判定にはCT なしのホストを使うのが確実です。CT なしのホストにつながる道具は、問題の中間証明書を信じていて、しかも CT を確かめていない、いちばん危ない状態です。

curl で確かめる

ターミナルで次の1行を実行します。

curl -sS -o /dev/null -w "%{http_code}\n" https://dv-g3b-noct-emudhra.we-have-a-problem.com/

200 などの数字が出たら、つながっています（＝信じている）。SSL certificate problem のような証明書のエラーが出たら、信じていません（＝安全）。

Homebrew で別の curl を入れている人は、which -a curl でどの curl が先に呼ばれているかを確かめ、両方を試してください。

Python で確かめる

python3 -c "import urllib.request; print(urllib.request.urlopen('https://dv-g3b-noct-emudhra.we-have-a-problem.com/').status)"

数字が出たらつながっています。CERTIFICATE_VERIFY_FAILED が出たら信じていません。仮想環境を使っている場合は、その環境の python で別に試します。requests を使うコードは certifi の一覧を読むので、python3 -m pip show certifi で版も見ておきます。

Node.js で確かめる

node -e "fetch('https://dv-g3b-noct-emudhra.we-have-a-problem.com/').then(r=>console.log(r.status)).catch(e=>console.log(e.cause?.code||e.message))"

数字が出たらつながっています。証明書のエラーのコードが出たら信じていません。node -v で版も確かめます。

git で確かめる

git ls-remote https://dv-g3b-noct-emudhra.we-have-a-problem.com/x.git

検証用ホストは git のリポジトリではないので、つながっても「not valid: is this a git repository?」という応答になります。この応答が出たら、証明書の確認は通過している（＝信じている）ということです。SSL certificate problem と出たら信じていません。

結果の読み方

Claude Code や Codex に確かめさせる場合

道具が多くて手で回すのが面倒なら、AI に確かめさせることもできます。そのときは、「確かめるだけで、何も直さない」と先に書いておくのが大事です。指示が曖昧だと、つながらなかった道具に対して勝手に設定を変えようとすることがあります。たとえば次のような指示文です（本記事の確かめ方をそのまま指示にしたもの）。

https://dv-g3b-noct-emudhra.we-have-a-problem.com/ に、
このMacの curl（which -a で出るものすべて）・python3・node・git から接続を試して、
道具ごとに「版」「つながったか、証明書のエラーか」を表にしてください。
設定の変更・インストール・証明書の確認を切るオプションの使用はしないこと。

表が出たら、つながった道具だけを次の章の一覧と照らします。AI が出した版の数字は、念のため自分でも node -v などで1つ2つ確かめておくと安心です。

直し方：道具ごとに上げる版

開示ページは、直った版の一覧を道具ごとに出しています。2026年10月23日時点の記載から、Mac で開発する人が使うことの多いものを抜き出しました。

Node.js の公式ブログも、10月のセキュリティ更新の対象に「ca-cert (eMudhra Intermediate CA Compromise) on 26.x, 24.x, 22.x」を挙げています。Node.js の配布一覧では、22.23.4 と 24.22.1 が10月20日、26.12.1 が10月21日の公開で、いずれもセキュリティ更新の印が付いています。Python の certifi 2026.10.19 は、PyPI への公開が10月20日（UTC）です。

Node.js のこの更新には、証明書の件のほかにも重大度の高い修正が含まれています。Node.js を使っているなら、証明書の件と関係なく上げておく価値があります。

macOS 標準の curl・git・python3 は別扱い

macOS 標準の道具は /etc/ssl/cert.pem を読むため、Apple がこのファイルを更新するまで直りません。開示ページには手動の回避策が載っています。概要は「/etc/ssl/cert.pem を控えてから、影響するルート証明書2つ（Comodo AAA Services と emSign ECC Root CA - G3）の項目を外す」というものです。標準の pip3 については、直った一覧を読ませる設定を足す方法が示されています。

この回避策はシステムのファイルを管理者権限で書き換えます。ルート証明書を外すと、そのルートにつながる正当なサイトにも影響が出ます。私たちはこの回避策を、コマンドを写して実行するものではなく、開示ページの説明を読んだうえで自分の環境に当てるか決めるものと考えています。本記事の公開時点では、私たちの Mac mini にもまだ当てていません。

標準の道具を避けたい場合は、Homebrew で入れた curl や、直った版の Python・Node.js を使うようにするのも手です。どの道具が先に呼ばれるかは which -a で確かめられます。

直した後にもう一度確かめる

版を上げたら、同じ CT なしのホストにもう一度つなぎます。証明書のエラーに変われば完了です。数字が返るままなら、まだ古い道具が先に呼ばれていないか、別の仮想環境やコンテナの中ではないかを見直します。

確かめる順番のおすすめは、次のとおりです。

1. ふだんターミナルで使う curl・python3・node・git
2. プロジェクトごとの仮想環境（venv・uv）の python
3. Docker のコンテナの中（Docker Desktop を上げても、古いイメージの中の一覧は古いまま）
4. Claude Code・Codex など、AI の道具そのもの

Docker のイメージは、中の OS の証明書の一覧（ca-certificates）が古いままのことがあります。開示ページは Debian・Ubuntu・Alpine などの直った版も挙げているので、イメージを作り直すときに確かめてください。

AI に開発を任せている人が見直すこと

エラーを消すために検証を切らせない

道具を直した後、どこかで証明書のエラーが出ることがあります。そのとき AI に「エラーを直して」と頼むと、curl -k や NODE_TLS_REJECT_UNAUTHORIZED=0、Python の verify=False のように、証明書の確認そのものを切る直し方を出してくることがあります。

これは今回の件では逆効果です。確認を切った道具は、問題の中間証明書で作られたなりすましの証明書も通してしまいます。私たちは、AI が証明書の確認を切る変更を出してきたら必ず止めて、原因（どの一覧が古いか）を先に調べるようにしています。

AI の道具そのものの版を追う

今回、私たちの Mac mini の Claude Code は、直った版（2.1.303）より前の 2.1.296 のままでした。更新履歴に証明書の話が出ていなかったため、更新履歴を読んでいるだけでは気づけませんでした。セキュリティの開示ページは、各道具の直った版をまとめて出してくれるので、AI の道具の更新を決めるときの材料にもなります。

Claude Code の更新履歴の読み方は、こちらで整理しています。

Claude CodeClaude Codeの更新履歴はどこで見る？「直った」欄の読み方

常時動かしている Mac ほど後回しになる

無人で定期処理を回している Mac は、止めたくないので更新を後回しにしがちです。私たちの Mac mini もまさにそうでした。常時動かしている Mac の安全は、開いている入口を実測で確かめる考え方が役に立ちます。

Claude CodeClaude Codeサーバーは安全か｜IPv6露出を実測した話

よくある質問

Q. ブラウザで eMudhra の証明書のサイトを見るのは危ないですか

開示ページによると、Chrome・Firefox は10月17日、Microsoft は10月20日、Apple は10月22日に遮断しています。ブラウザを最新にしていれば、問題の中間証明書はエラーになります。気にするべきなのはブラウザではなく、ターミナルの道具です。

Q. 実際に悪用された例はありますか

本記事で確かめた一次情報（開示ページ・Mozilla のバグ報告・Node.js の公式ブログ）には、悪用の事例は書かれていません。ただし秘密鍵は証明書から誰でも復元できるとされているため、「悪用の報告が無いから大丈夫」とは言えません。

Q. 社内のサーバーや CI も確かめたほうがいいですか

はい。確かめ方は同じで、そのサーバーや CI の中から検証用ホストにつなぎます。開示ページは Debian・Ubuntu・Alpine・Fedora など OS ごとの直った版も挙げています。GitHub Actions で PyPI へ公開している人向けに、公開用のアクションの直った版も載っています。

Q. 開示ページの回避策は実行したほうがいいですか

macOS 標準の道具を直す方法は、今のところ開示ページの手動の回避策しかありません。ただしシステムのファイルを管理者権限で書き換えるため、内容を読んで理解できる場合に限ります。標準の道具を使わず、直った版の Python・Node.js や Homebrew の curl に寄せるほうが、戻せなくなる心配は少なくなります。

まとめ

• eMudhra の中間証明書8枚は、秘密鍵を証明書から誰でも復元できる状態でした
• ブラウザは10月17〜22日に遮断済み。Mac 標準の curl・git・python3 や古い Node.js は、今も信じたままです
• 私たちの Mac mini では、試した道具がすべて検証用ホストにつながりました
• CT なしの検証用ホストに1行当てれば、自分の Mac が該当するか分かります
• Node.js 26.12.1／24.22.1／22.23.4・certifi 2026.10.19・Claude Code 2.1.303 など、直った版へ上げて、もう一度確かめます
• エラーを消すために、AI に証明書の確認を切らせないでください

株式会社Fyveでは、AI に開発や業務を任せるときの環境の整え方も含めて、実際に試した結果をもとに発信しています。直った版や Apple の対応は今後も動くため、作業の前に開示ページの最新の記載を確かめてください。