systemdサービスはプロキシに届くのにCAファイルを読めない
プロキシ証明書の設定が対話型シェルでしか動かない場合は、サービスユーザーのファイル権限とsystemdのファイルシステム制限を調べます。
承認済みのCAバンドルをインストールし、端末のリクエストは動いています。それでもサービスは証明書の読み込みエラーを出します。プロキシIPを変える前に、そのプロセスが同じファイルを開けるかを確認してください。
サービスは別のUnixユーザーで動いたり、別のディレクトリから始まったり、制限されたファイルシステムしか見えなかったりします。ログイン中の自分に有効なパスが、サービスにも有効とは限りません。
絶対パスから確認する
実際のクライアントに設定したパスを確認します。たとえばcurlの--cacertは接続先のCAバンドルを選びます。HTTPSプロキシには別のプロキシCAオプションがあります。他のクライアントは独自の設定キーや環境変数を使います。
ファイルと、そこへ至るディレクトリの両方を調べます。
namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectoryこれは診断用の例であり、誰でも書き込めるファイルにする指示ではありません。最終的なファイルの読み取り権限だけでなく、途中のディレクトリを通過する権限も重要です。
権限だけが問題とは限らない
ProtectHome=yesでは、systemdが標準のホームディレクトリの場所をそのサービスからアクセスできなくします。証明書ファイルのモードを変えても、名前空間の制限は解除されません。ルートディレクトリを設定している場合も、サービス内の絶対パスが指すものは変わり得ます。
そのアプリ用の/etc配下のディレクトリなど、サービス設定に適した場所を使い、必要な読み取り権限だけを与えます。クライアントのCAパスを新しい場所に更新してください。最初のコピーを個人のホームに置いたからといって、無関係なファイルシステム制限まで外さないでください。
最初の有用なエラーを読む
「CAファイルを読み込めない」と「証明書チェーンが信頼されない」は別の失敗です。前者は何かを検証する前に起こり得ます。後者は、バンドルは読めても認証局が違う、または違うTLS接続に適用している可能性を示します。
アクセスを直した後、サービスの実行環境から再テストします。端末のコマンド成功は比較材料になりますが、サービスに見えるファイルや、クライアントが使う信頼設定までは証明できません。