A systemd Service Can Reach the Proxy but Not Its CA File

You have installed the approved CA bundle and the request works in a terminal. The service still reports a certificate-loading error. Before replacing the proxy IP, check whether that process can open the same file.

A service can run as another Unix user, start in a different directory, or see a restricted filesystem. A path that is valid for your login is not automatically valid for it.

Start with an absolute path

Check the path configured in the actual client. For curl, for example, --cacert selects the destination CA bundle; an HTTPS proxy has separate proxy CA options. Other clients use their own configuration keys or environment variables.

Inspect both the file and the directories leading to it:

namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectory

These are diagnostic examples, not instructions to make the file world-writable. Directory traversal permissions matter as well as the final file's read permission.

Permissions may not be the whole problem

With ProtectHome=yes, systemd makes the standard home-directory locations inaccessible to that service. Changing the certificate file's mode does not undo that namespace restriction. A configured root directory can also change what an absolute path refers to inside the service.

Use an appropriate service configuration location, such as a directory under /etc intended for that application, and grant only the required read access. Update the client's CA path to that location. Do not remove unrelated filesystem restrictions merely because the first copy was stored in your personal home directory.

Read the first useful error

“Cannot load CA file” and “certificate chain is not trusted” are different failures. The former may happen before the client can verify anything. The latter can mean the readable bundle contains the wrong authority or is being applied to the wrong TLS connection.

Retest from the service's context after correcting access. A successful terminal command remains a useful comparison, but it cannot prove which files the service sees or which trust configuration its client uses.