テクノロジー · 実用ガイド

pip の CERTIFICATE_VERIFY_FAILED？TLS を回避する前に信頼経路を確認する

Python、pip 設定、プロキシの発行者、CA の出所を特定し、最小限の対応箇所を修復してから回避なしで元の要求を再検証します。

執筆 Watch at Ease News · 2 分で読めます公開 2026/10/15 7:17 UTC

pip の TLS エラーは一つの万能コマンドで直る問題ではない。別の Python、隠れた設定、傍受プロキシ、不完全な CA チェーン、古い証明書バックエンド、別経路を使う隔離ビルドなどが同じエラーを出す。設定を変える前に実行プロセスと信頼元を特定する。

失敗したプロセスと要求を固定する

`python -m pip ...` で再現し、実行ファイル、OpenSSL、pip の版を記録する。索引ホストと、主処理・依存解決・隔離ビルドのどこで失敗したかも残す。ブラウザーの成功は Python が同じ信頼ストアやプロキシを使う証明ではない。

`python -m pip config debug` で見えているファイルと値を出し、CA、プロキシ、索引に関する環境変数を確認する。資格情報は公開しない。ユーザー設定、仮想環境、環境変数が想定外に優先されることがある。

公開 CA、組織プロキシ、予期しない中間証明書のどれがチェーンを発行したか調べる。対応する新しい組み合わせでは truststore がシステム証明書と certifi を利用するが、pip と Python の版で動作が変わる。明示的 CA ファイルも経路を変える。

Python が違えば対象を明示し、古い版なら許可された保守手順で更新する。組織が TLS を検査する場合は管理者からルート証明書を取得し、OS の信頼ストアか承認済み CA バンドルへ入れる。誤ったプロキシや索引設定は発生源で直す。

trusted-host や検証無効化は境界の確認には使えても、サーバーの身元を証明せず信頼チェーンも直さない。グローバル設定、イメージ、CI、共有コマンドに残さず、一時試験後すぐ削除し、秘密情報を公開課題へ貼らない。

新しいシェルまたは再構築環境で回避なしの同じ要求を実行し、設定も再確認する。対象 Python と CA が有効で、直接依存とビルド依存の双方が動くか確かめる。隔離ビルドだけ失敗する差は別プロセス境界の証拠として残す。