O serviço systemd alcança o proxy, mas não o arquivo CA

Você instalou o pacote CA aprovado e a requisição funciona no terminal. O serviço ainda relata erro ao carregar o certificado. Antes de trocar o IP do proxy, veja se esse processo consegue abrir o mesmo arquivo.

Um serviço pode rodar como outro usuário Unix, começar em outro diretório ou enxergar um sistema de arquivos restrito. Um caminho válido para seu login não é automaticamente válido para ele.

Comece com um caminho absoluto

Confira o caminho configurado no cliente real. No curl, por exemplo, --cacert seleciona o pacote CA do destino; um proxy HTTPS tem opções CA de proxy separadas. Outros clientes usam suas próprias chaves de configuração ou variáveis de ambiente.

Inspecione o arquivo e os diretórios que levam até ele:

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

São exemplos de diagnóstico, não instruções para tornar o arquivo gravável por todos. A permissão de atravessar diretórios importa tanto quanto a leitura do arquivo final.

As permissões talvez não sejam todo o problema

Com ProtectHome=yes, o systemd torna os locais padrão dos diretórios pessoais inacessíveis a esse serviço. Alterar o modo do arquivo de certificado não desfaz essa restrição de namespace. Um diretório raiz configurado também pode mudar para onde um caminho absoluto aponta dentro do serviço.

Use um local de configuração adequado ao serviço, como um diretório sob /etc destinado ao aplicativo, e conceda apenas a leitura necessária. Atualize o caminho CA do cliente. Não remova restrições de sistema de arquivos sem relação só porque a primeira cópia foi salva no seu diretório pessoal.

Leia o primeiro erro útil

«Não é possível carregar o arquivo CA» e «a cadeia de certificados não é confiável» são falhas diferentes. A primeira pode ocorrer antes de o cliente verificar qualquer coisa. A segunda pode significar que o pacote legível contém a autoridade errada ou está sendo aplicado à conexão TLS errada.

Depois de corrigir o acesso, teste novamente no contexto do serviço. Um comando bem-sucedido no terminal continua sendo uma comparação útil, mas não prova quais arquivos o serviço enxerga nem qual configuração de confiança seu cliente usa.