Le service systemd atteint le proxy, mais pas son fichier CA

Vous avez installé le bundle CA approuvé et la requête fonctionne dans un terminal. Le service signale toujours une erreur de chargement de certificat. Avant de remplacer l’IP du proxy, vérifiez si ce processus peut ouvrir le même fichier.

Un service peut s’exécuter sous un autre utilisateur Unix, démarrer dans un autre répertoire ou voir un système de fichiers restreint. Un chemin valable pour votre session ne l’est pas automatiquement pour lui.

Commencer par un chemin absolu

Vérifiez le chemin configuré dans le client réellement utilisé. Dans curl, par exemple, --cacert sélectionne le bundle CA de destination ; un proxy HTTPS dispose d’options CA de proxy distinctes. Les autres clients utilisent leurs propres clés de configuration ou variables d’environnement.

Inspectez le fichier et les répertoires qui y mènent :

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

Ce sont des exemples de diagnostic, pas une invitation à rendre le fichier modifiable par tous. Les droits de traversée des répertoires comptent autant que le droit de lecture du fichier final.

Les permissions ne sont peut-être pas tout le problème

Avec ProtectHome=yes, systemd rend les emplacements standard des répertoires personnels inaccessibles au service. Modifier le mode du fichier de certificat ne lève pas cette restriction d’espace de noms. Un répertoire racine configuré peut aussi changer la cible d’un chemin absolu dans le service.

Utilisez un emplacement de configuration adapté au service, par exemple un répertoire sous /etc prévu pour l’application, et n’accordez que la lecture nécessaire. Mettez à jour le chemin CA du client. Ne supprimez pas d’autres restrictions du système de fichiers simplement parce que la première copie se trouvait dans votre répertoire personnel.

Lire la première erreur utile

« Impossible de charger le fichier CA » et « chaîne de certificats non approuvée » sont deux échecs différents. Le premier peut survenir avant toute vérification. Le second peut signifier que le bundle lisible contient la mauvaise autorité ou s’applique à la mauvaise connexion TLS.

Après correction de l’accès, refaites le test dans le contexte du service. Une commande réussie en terminal reste un point de comparaison utile, mais ne prouve pas quels fichiers voit le service ni quelle configuration de confiance son client emploie.