Een systemd-dienst bereikt de proxy, maar niet het CA-bestand

Je hebt de goedgekeurde CA-bundel geïnstalleerd en het verzoek werkt in een terminal. De dienst meldt nog steeds een fout bij het laden van certificaten. Controleer voordat je de proxy-IP vervangt of dat proces hetzelfde bestand kan openen.

Een dienst kan als een andere Unix-gebruiker draaien, in een andere map starten of een beperkt bestandssysteem zien. Een pad dat voor jouw login geldig is, is dat niet automatisch voor de dienst.

Begin met een absoluut pad

Controleer het pad in de werkelijk gebruikte client. Bij curl kiest --cacert bijvoorbeeld de CA-bundel van de bestemming; een HTTPS-proxy heeft afzonderlijke proxy-CA-opties. Andere clients gebruiken eigen configuratiesleutels of omgevingsvariabelen.

Bekijk het bestand en de mappen op het pad ernaartoe:

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

Dit zijn diagnosevoorbeelden, geen instructie om het bestand voor iedereen schrijfbaar te maken. Rechten om mappen te doorlopen zijn net zo belangrijk als leesrechten op het uiteindelijke bestand.

Rechten zijn misschien niet het hele probleem

Met ProtectHome=yes maakt systemd de standaard home-locaties ontoegankelijk voor die dienst. De bestandsmodus van het certificaat wijzigen heft die namespacebeperking niet op. Een ingestelde hoofdmap kan ook veranderen waar een absoluut pad binnen de dienst naar verwijst.

Gebruik een geschikte serviceconfiguratielocatie, zoals een voor de toepassing bedoelde map onder /etc, en geef alleen de benodigde leesrechten. Werk het CA-pad van de client bij. Verwijder geen ongerelateerde bestandssysteembeperkingen omdat de eerste kopie in je persoonlijke home-map stond.

Lees de eerste bruikbare fout

«CA-bestand kan niet worden geladen» en «certificaatketen wordt niet vertrouwd» zijn verschillende fouten. De eerste kan optreden voordat de client iets verifieert. De tweede kan betekenen dat de leesbare bundel de verkeerde autoriteit bevat of op de verkeerde TLS-verbinding wordt toegepast.

Test na de toegangscorrectie opnieuw vanuit de servicecontext. Een geslaagde terminalopdracht blijft een nuttige vergelijking, maar bewijst niet welke bestanden de dienst ziet of welke vertrouwensconfiguratie de client gebruikt.