En systemd-tjeneste når proxyen, men ikke CA-filen
Kontroller tjenestebrukerens filtilgang og systemds filsystembegrensninger når proxysertifikatoppsettet bare virker i et interaktivt skall.
Du har installert den godkjente CA-pakken, og forespørselen virker i terminalen. Tjenesten melder fortsatt om feil ved innlasting av sertifikatet. Kontroller om prosessen kan åpne den samme filen før du bytter proxy-IP.
En tjeneste kan kjøre som en annen Unix-bruker, starte i en annen mappe eller se et begrenset filsystem. En sti som er gyldig for innloggingen din, er ikke automatisk gyldig for tjenesten.
Begynn med en absolutt sti
Kontroller stien som er satt i den faktiske klienten. I curl velger for eksempel --cacert målets CA-pakke; en HTTPS-proxy har separate proxy-CA-alternativer. Andre klienter bruker egne konfigurasjonsnøkler eller miljøvariabler.
Undersøk filen og mappene på veien til den:
namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectory
Dette er diagnoseeksempler, ikke instruksjoner om å gjøre filen skrivbar for alle. Tillatelse til å passere mapper er like viktig som lesetilgang til den endelige filen.
Rettigheter er kanskje ikke hele problemet
Med ProtectHome=yes gjør systemd de vanlige hjemmemappeplasseringene utilgjengelige for tjenesten. Å endre sertifikatfilens modus opphever ikke den navneromsbegrensningen. En konfigurert rotmappe kan også endre hva en absolutt sti viser til inne i tjenesten.
Bruk et egnet sted for tjenestekonfigurasjon, som en mappe under /etc beregnet for programmet, og gi bare nødvendig lesetilgang. Oppdater klientens CA-sti dit. Ikke fjern uvedkommende filsystembegrensninger bare fordi den første kopien lå i den personlige hjemmemappen din.
Les den første nyttige feilen
«Kan ikke laste CA-fil» og «sertifikatkjeden er ikke betrodd» er ulike feil. Den første kan oppstå før klienten kan verifisere noe. Den andre kan bety at den lesbare pakken inneholder feil utsteder eller brukes på feil TLS-forbindelse.
Test på nytt fra tjenestens kontekst etter at tilgangen er rettet. En vellykket terminalkommando er fortsatt en nyttig sammenligning, men beviser ikke hvilke filer tjenesten ser, eller hvilken tillitskonfigurasjon klienten bruker.