Ein systemd-Dienst erreicht den Proxy, aber nicht seine CA-Datei

Das freigegebene CA-Bundle ist installiert, und die Anfrage funktioniert im Terminal. Der Dienst meldet weiterhin einen Fehler beim Laden des Zertifikats. Prüfen Sie vor dem Austausch der Proxy-IP, ob dieser Prozess dieselbe Datei öffnen kann.

Ein Dienst kann unter einem anderen Unix-Benutzer laufen, in einem anderen Verzeichnis starten oder ein eingeschränktes Dateisystem sehen. Ein für Ihre Anmeldung gültiger Pfad ist nicht automatisch für ihn gültig.

Mit einem absoluten Pfad beginnen

Prüfen Sie den im tatsächlichen Client eingestellten Pfad. Bei curl wählt etwa --cacert das CA-Bundle des Ziels; ein HTTPS-Proxy hat separate Proxy-CA-Optionen. Andere Clients verwenden eigene Konfigurationsschlüssel oder Umgebungsvariablen.

Prüfen Sie sowohl die Datei als auch die Verzeichnisse auf dem Weg zu ihr:

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

Dies sind Diagnosebeispiele, keine Anweisung, die Datei für alle beschreibbar zu machen. Die Durchquerungsrechte der Verzeichnisse sind ebenso wichtig wie das Leserecht der Datei.

Berechtigungen sind möglicherweise nicht das ganze Problem

Mit ProtectHome=yes macht systemd die üblichen Home-Verzeichnisse für diesen Dienst unzugänglich. Eine Änderung des Dateimodus hebt diese Namensraumgrenze nicht auf. Auch ein konfiguriertes Wurzelverzeichnis kann ändern, worauf ein absoluter Pfad im Dienst verweist.

Verwenden Sie einen geeigneten Dienstkonfigurationsort, etwa ein für die Anwendung bestimmtes Verzeichnis unter /etc, und gewähren Sie nur die nötigen Leserechte. Aktualisieren Sie den CA-Pfad des Clients darauf. Entfernen Sie keine anderen Dateisystemgrenzen, nur weil die erste Kopie im persönlichen Home-Verzeichnis lag.

Den ersten hilfreichen Fehler lesen

„CA-Datei kann nicht geladen werden“ und „Zertifikatskette ist nicht vertrauenswürdig“ sind unterschiedliche Fehler. Der erste kann auftreten, bevor der Client überhaupt etwas prüft. Der zweite kann bedeuten, dass das lesbare Bundle die falsche Zertifizierungsstelle enthält oder auf die falsche TLS-Verbindung angewandt wird.

Testen Sie nach der Zugriffskorrektur erneut im Kontext des Dienstes. Ein erfolgreicher Terminalbefehl bleibt ein hilfreicher Vergleich, beweist aber weder, welche Dateien der Dienst sieht, noch welche Vertrauenskonfiguration sein Client nutzt.