テクノロジー · 実用ガイド
curl error 60？--insecure の前に証明書チェーンと信頼ストアを監査する
「unable to get local issuer certificate」に万能な修正はありません。TLS バックエンド、CAfile、CApath、プロキシ経路を記録し、サーバーチェーン、クライアント信頼、検査プロキシの該当箇所だけを直します。
curl error 60 は検証失敗であり、検証を切る指示ではありません。欠けた環はサーバーの提示チェーン、curl の信頼入力、アプリ専用バンドル、TLS 検査プロキシのいずれかです。
エンドポイント、チェーン、バックエンド、信頼入力、修復の順に監査します。証拠に従い、サーバー、検証済み私有 CA、ネイティブ/ファイルストア、またはプロキシ信頼を直します。
失敗した接続先と curl ビルドを保存する
信頼設定を変える前に URL、ホスト、ポート、ユーザー、プロキシ変数、完全なエラーを記録します。curl -V で TLS バックエンドを、curl -v で CAfile、CApath、接続先、CONNECT プロキシを保存します。ブラウザー成功はブラウザー自身の信頼経路しか証明しません。
実際に失敗するシェル、コンテナ、サービスアカウントで再現します。root、PHP、Git、Composer は別設定を読むことがあります。-k で成功しても検証境界の証拠にすぎず、すぐ外します。
接続先が提示するチェーンを確認する
SNI を含む正確なホストとポートで、葉の subject、issuer、送信された中間証明書を記録します。公開サイトが中間を省略しているならサーバーの full chain を直し、葉をルートとして登録しません。
TLS 検査装置が終端する場合、issuer は組織のものになります。curl -v と環境変数で経路を証明します。HTTPS プロキシの信頼はオリジンの信頼と別です。
curl が使う信頼入力を証明する
Schannel は通常 Windows ネイティブストアを使い、他の多くのバックエンドはファイルを使います。CURL_CA_BUNDLE、SSL_CERT_FILE、SSL_CERT_DIR、アプリ設定、コンテナのマウントを確認します。
--cacert は検証済み PEM CA にだけ使い、--capath は正しく準備します。対応ビルドで意図した方針なら --ca-native を使います。Apple ではネイティブ信頼と独自ファイルを併用できます。
証拠に合う最小修復を適用する
サーバーが中間を省略したらサーバーを直します。私有/企業 CA が意図された場合は、認証済み経路で fingerprint と所有者を確認し、最小範囲で信頼します。Ubuntu と Red Hat では登録場所と更新コマンドが異なります。
一つのアプリだけならその CA パスを直し、HTTPS プロキシだけならプロキシ専用 CA 設定を使います。予期しない issuer は登録せず、調査をエスカレーションします。
検証・範囲・ロールバックを再テストする
-k と一時上書きを外し、ホスト名、issuer、バックエンド、CA 入力を確認してから実アプリとクリーン環境を試します。一時 --cacert の成功は他のランタイムが同じファイルを読む証明ではありません。
失敗証拠、信頼変更、CA 所有者、有効期限、削除手順を記録します。サーバー修復は複数のクリーンなクライアントで、私有アンカーは削除まで検証します。
