Claude Code に頼む
そのまま貼れるプロンプト
調べる、承認してから直す、の順に分けています。最初から「全部直して」と頼むと、どこが古かったのかが記録に残りません。
1. このマシンを診断する
2026年10月に見つかった eMudhra(emSign)中間証明書の秘密鍵漏えいについて、このマシンが影響を受けるかを調べてください。まだ何も更新しないでください。
対象: Node.js、Bun、Deno、Python(certifi)、uv、pip、Go、curl、Homebrew の ca-certificates、cloudflared、OS の証明書ストア、ローカルにある Docker イメージ
1. 各ツールについて、インストール場所とバージョンを実際にコマンドを実行して調べてください。Homebrew、nvm、mise、asdf などで同じツールが複数入っていれば全部挙げてください
2. 修正版の番号は、各プロジェクトの公式リリースノートかセキュリティ告知で確かめてください。ニュース記事やまとめサイトの番号は使わないでください。確かめられなかったものは「未確認」と書いてください
3. できるものは、そのツールが信頼するルート証明書に「emSign ECC Root CA - G3」が入っているかを直接調べてください(例: Node.js なら tls.rootCertificates を X509Certificate で解析する)
4. 結果を「ツール / 場所 / 今のバージョン / 修正版 / 判定 / 確認方法」の表にしてください
この書き方にした理由
- Node.js と Bun は証明書リストを本体に埋め込んでいます。OS を更新しても直らないので、ツールごとに見る必要があります
- 同じツールが複数入っていると、ターミナルで使う版と本番スクリプトが使う版が違うことがあります
- この件の修正版番号は、ニュースサイトどうしで食い違っていました。公式のリリースノートで確かめるよう指定しています
- 「更新しないで」と書くことで、最初は調べるだけにとどめます。何が古かったかが表に残ります
2. 承認してから更新する
さっきの表で修正版より古かったものを、修正版に更新してください。
- 更新する前に、何をどのコマンドで更新するかを一覧にして、私の承認を待ってください
- 更新したら、もう一度バージョンとルート証明書の中身を調べて、更新前と並べて見せてください
- Bun のように修正版がまだないものは、更新せずに「未修正」として残してください
- 証明書エラーが出ても、NODE_TLS_REJECT_UNAUTHORIZED=0、verify=False、curl -k、InsecureSkipVerify などで検証を無効にしないでください。エラーが出たらそこで止めて報告してください
この書き方にした理由
- Homebrew での更新は、ほかのツールの依存も一緒に上がることがあります。先に一覧を見て判断できるようにしています
- 更新前と更新後を並べると、本当に直ったかを自分の目で確かめられます
- 証明書エラーを消すために検証を切ると、今回の修正が無意味になります。Cloudflare も告知で、検証を無効にして回避しないよう呼びかけています
3. 全リポジトリの実行環境を洗い出す
ホームディレクトリ以下にある自分のリポジトリを全部見て、本番と CI で使っている実行環境のバージョン指定を洗い出してください。
見る場所: .nvmrc、.node-version、package.json の engines と packageManager、Dockerfile の FROM、GitHub Actions の setup-node / setup-go / setup-python / setup-bun、go.mod の go と toolchain、mise.toml、.tool-versions、requirements や uv.lock に入っている certifi のバージョン
修正版より古いものを、リポジトリごとに表にしてください。直すのは私が選んだリポジトリだけにして、リポジトリごとにブランチを切って PR にしてください。
この書き方にした理由
- 手元のマシンを直しても、Docker イメージ、サーバー、CI は古いバージョンのまま動き続けます
- Go で作ったバイナリは、Go を更新したあとに再ビルドしないと直りません
- Python の certifi はプロジェクトごとのロックファイルに固定されています。マシン全体の更新では変わりません
- 直す対象を自分で選ぶことで、動いているサービスがまとめて止まるのを避けます
4. 証明書の検証を切っている箇所を探す
私のリポジトリ全体から、TLS の証明書検証を無効にしている箇所を探してください。まだ書き換えないでください。
探すもの: NODE_TLS_REJECT_UNAUTHORIZED、rejectUnauthorized: false、verify=False、curl の -k と --insecure、InsecureSkipVerify: true、npm や yarn の strict-ssl false、git の http.sslVerify false
見つかった箇所ごとに、ファイルと行、なぜそうなっていそうか、どう直せばよいかを出してください。
この書き方にした理由
- 検証を切っているコードは、ツールを修正版にしても偽の証明書を受け入れます
- 開発中に一時的に入れた設定が、本番やCIに残っていることがよくあります
5. 自分のサイトの証明書を確かめる
次のドメインについて、openssl s_client で TLS 証明書を取得して、発行元(Issuer)と証明書の連鎖を一覧にしてください。eMudhra か emSign が含まれていたら教えてください。
ドメイン:
(ここに自分のドメインを1行に1つずつ書く)
この書き方にした理由
- eMudhra は、問題のルートの配下にある約3万件の証明書を別のルートへ移すとしています。emSign の証明書を使っているサイトは、ブラウザがルートを外すと接続エラーになります
- Let's Encrypt や Google Trust Services の証明書なら、この件で対応することはありません