El servicio systemd llega al proxy, pero no a su archivo CA

Has instalado el paquete CA aprobado y la petición funciona en el terminal. El servicio sigue indicando un error al cargar el certificado. Antes de cambiar la IP del proxy, comprueba si ese proceso puede abrir el mismo archivo.

Un servicio puede ejecutarse como otro usuario Unix, empezar en otro directorio o ver un sistema de archivos restringido. Una ruta válida para tu sesión no lo es automáticamente para él.

Empieza por una ruta absoluta

Comprueba la ruta configurada en el cliente real. En curl, por ejemplo, --cacert selecciona el paquete CA del destino; un proxy HTTPS tiene opciones CA de proxy independientes. Otros clientes usan sus propias claves de configuración o variables de entorno.

Inspecciona tanto el archivo como los directorios que llevan a él:

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

Son ejemplos de diagnóstico, no instrucciones para hacer el archivo modificable por todos. Los permisos de atravesar directorios importan tanto como la lectura del archivo final.

Los permisos pueden no ser todo el problema

Con ProtectHome=yes, systemd hace que las ubicaciones habituales de directorios personales sean inaccesibles para ese servicio. Cambiar el modo del archivo de certificado no elimina esa restricción del espacio de nombres. Un directorio raíz configurado también puede cambiar a qué apunta una ruta absoluta dentro del servicio.

Usa una ubicación de configuración adecuada para el servicio, como un directorio bajo /etc destinado a esa aplicación, y concede solo la lectura necesaria. Actualiza la ruta CA del cliente. No retires otras restricciones del sistema de archivos solo porque la primera copia se guardó en tu directorio personal.

Lee el primer error útil

«No se puede cargar el archivo CA» y «la cadena de certificados no es de confianza» son fallos distintos. El primero puede ocurrir antes de que el cliente pueda verificar nada. El segundo puede significar que el paquete legible contiene la autoridad equivocada o se aplica a una conexión TLS incorrecta.

Tras corregir el acceso, vuelve a probar desde el contexto del servicio. El éxito en el terminal sigue siendo una comparación útil, pero no demuestra qué archivos ve el servicio ni qué configuración de confianza usa su cliente.