Naabot ng systemd service ang proxy pero hindi ang CA file

Na-install mo na ang aprubadong CA bundle at gumagana ang request sa terminal. Nag-uulat pa rin ang serbisyo ng certificate-loading error. Bago palitan ang proxy IP, tingnan kung nabubuksan ng process na iyon ang parehong file.

Maaaring ibang Unix user ang ginagamit ng serbisyo, iba ang panimulang directory, o limitado ang filesystem na nakikita nito. Hindi awtomatikong valid para rito ang path na valid sa login mo.

Magsimula sa absolute path

Suriin ang path na naka-configure sa aktuwal na client. Sa curl, halimbawa, --cacert ang pumipili ng CA bundle ng destinasyon; may hiwalay na proxy CA option ang HTTPS proxy. Sariling configuration key o environment variable ang gamit ng ibang client.

Suriin ang file at ang mga directory na dinaraanan papunta rito:

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

Diagnostic example ang mga ito, hindi utos na gawing nasusulatan ng lahat ang file. Mahalaga rin ang pahintulot na makadaan sa directory, hindi lang ang read permission sa huling file.

Baka hindi lang permission ang problema

Sa ProtectHome=yes, ginagawang hindi maaabot ng systemd ang karaniwang home-directory location para sa serbisyong iyon. Hindi inaalis ng pagpapalit ng mode ng certificate file ang namespace restriction. Maaari ring baguhin ng naka-configure na root directory ang tinutukoy ng absolute path sa loob ng serbisyo.

Gumamit ng angkop na lugar para sa service configuration, gaya ng directory sa ilalim ng /etc na para sa app, at ibigay lang ang kailangang read access. I-update ang CA path ng client. Huwag alisin ang ibang filesystem restriction dahil lang nasa personal mong home directory ang unang kopya.

Basahin ang unang kapaki-pakinabang na error

Magkaibang kabiguan ang «Hindi mai-load ang CA file» at «hindi pinagkakatiwalaan ang certificate chain». Maaaring mangyari ang una bago pa makapag-verify ang client ng anuman. Maaaring ibig sabihin ng ikalawa na nababasa ang bundle pero maling authority ang laman o sa maling TLS connection inilalapat.

Pagkatapos ayusin ang access, subukan muli mula sa konteksto ng serbisyo. Kapaki-pakinabang na paghahambing pa rin ang matagumpay na terminal command, pero hindi nito pinatutunayan kung aling file ang nakikita ng serbisyo o aling trust configuration ang gamit ng client nito.