systemd-teenus jõuab proksini, kuid mitte CA-failini

Heakskiidetud CA-pakk on paigaldatud ja päring töötab terminalis. Teenus teatab ikka sertifikaadi laadimisveast. Enne proksi IP vahetamist kontrolli, kas see protsess saab sama faili avada.

Teenus võib töötada teise Unixi kasutajana, alustada teises kataloogis või näha piiratud failisüsteemi. Sinu sisselogimisele sobiv failitee ei sobi automaatselt sellele.

Alusta absoluutsest failiteest

Kontrolli tegelikku klienti seadistatud failiteed. Näiteks curlis valib --cacert sihtkoha CA-paki; HTTPS-proksil on eraldi proksi CA-valikud. Teised kliendid kasutavad oma seadistusvõtmeid või keskkonnamuutujaid.

Uuri nii faili kui ka selleni viivaid katalooge:

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

Need on diagnostikanäited, mitte käsk teha fail kõigile kirjutatavaks. Kataloogide läbimise õigus on sama oluline kui lõpliku faili lugemisõigus.

Õigused ei pruugi olla kogu probleem

Valikuga ProtectHome=yes muudab systemd tavalised kodukataloogiasukohad teenusele ligipääsmatuks. Sertifikaadifaili režiimi muutmine ei tühista nimeruumi piirangut. Seadistatud juurkataloog võib ka muuta, millele absoluutne failitee teenuse sees osutab.

Kasuta sobivat teenuseseadistuse asukohta, näiteks rakendusele mõeldud kataloogi /etc all, ning anna vaid vajalik lugemispääs. Uuenda kliendi CA-failitee sinna. Ära eemalda kõrvalisi failisüsteemipiiranguid üksnes seetõttu, et esimene koopia oli sinu isiklikus kodukataloogis.

Loe esimest kasulikku viga

«CA-faili ei saa laadida» ja «sertifikaadiahelat ei usaldata» on eri tõrked. Esimene võib juhtuda enne, kui klient midagi kontrollib. Teine võib tähendada, et loetav pakk sisaldab valet sertifitseerijat või seda kasutatakse valel TLS-ühendusel.

Pärast ligipääsu parandamist testi uuesti teenuse kontekstist. Edukas terminalikäsk on ikka kasulik võrdlus, kuid ei tõesta, milliseid faile teenus näeb või millist usaldusseadistust klient kasutab.