カスタム CA バンドルを使ったリダイレクト後の SSL 証明書エラー
明示的に選択した CA ファイルに、リダイレクト先のホストを含む実際のリクエスト経路が必要とする信頼材料がすべて含まれているか確認します。
会社の CA ファイルで最初の URL は解決しても、リダイレクト後の検証で失敗します。カスタム CA オプションがクライアントの以前の信頼入力を置き換えたのか、単に追加したのかを確認してください。
この動作は TLS バックエンドとオプションに依存します。企業 CA だけを含むファイルでは、クライアントが必要とする他の認証局が欠けることがあります。
- 各相手を追跡します。 最初のホストは企業の発行者配下で傍受されている場合があります。後のホストはバイパス、別の検査経路、または公的に発行されたチェーンを使うことがあります。
- 失敗したクライアントの入力を記録します。 要求したホスト名、リダイレクト先、受信した発行者、検証結果、選択した信頼設定を保持します。動作するブラウザは別のルートストアを使っている可能性があります。
- バックエンドの選択規則を確認します。 curl のビルドはネイティブ検証やファイルベースのルートを使うことがあり、明示的な CA オプションでその選択が変わり得ます。その実行ファイル向けのレシピは Python 環境や JVM を設定するものではありません。
アプリケーションが信頼するべき公開認証局と非公開認証局を含む、保守されたバンドルまたはサポートされた信頼ストア構成を使用してください。次のエラーを消すためだけに CA の秘密鍵を追加したり、失敗する各リーフ証明書をルートに昇格させたりしないでください。
信頼材料はデプロイのサポートされた更新経路で配布してください。ベンダーの CA パッケージを手動で置き換えると、次回の更新で元に戻る場合があります。所有者と保守プロセスを明確にし、リクエスト経路全体で検証が続くようにしてください。