Shërbimi systemd arrin proxy-n, por jo skedarin CA
Kontrolloni aksesin e përdoruesit të shërbimit te skedarët dhe kufizimet systemd kur konfigurimi i certifikatës punon vetëm në shell interaktiv.
Keni instaluar paketën CA të miratuar dhe kërkesa punon në terminal. Shërbimi ende raporton gabim ngarkimi certifikate. Para ndryshimit të IP-së së proxy-t, kontrolloni nëse ai proces mund të hapë të njëjtin skedar.
Një shërbim mund të punojë si përdorues tjetër Unix, të nisë në direktori tjetër ose të shohë sistem skedarësh të kufizuar. Një shteg i vlefshëm për hyrjen tuaj nuk është automatikisht i vlefshëm për të.
Filloni me shteg absolut
Kontrolloni shtegun e konfiguruar në klientin real. Në curl, për shembull, --cacert zgjedh paketën CA të destinacionit; proxy HTTPS ka opsione CA të veçanta për proxy-n. Klientë të tjerë përdorin çelësat e tyre të konfigurimit ose ndryshoret e mjedisit.
Inspektoni skedarin dhe direktoritë që çojnë te ai:
namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectory
Këta janë shembuj diagnostikimi, jo udhëzime për ta bërë skedarin të shkruajtshëm nga të gjithë. Lejet e kalimit nëpër direktori vlejnë po aq sa leja e leximit të skedarit final.
Lejet mund të mos jenë i gjithë problemi
Me ProtectHome=yes, systemd i bën vendndodhjet standarde të direktorive shtëpi të paarritshme për shërbimin. Ndryshimi i mënyrës së skedarit të certifikatës nuk heq kufizimin e hapësirës së emrave. Një direktori rrënjë e konfiguruar mund të ndryshojë edhe çfarë tregon një shteg absolut brenda shërbimit.
Përdorni një vend konfigurimi të përshtatshëm për shërbimin, si një direktori nën /etc për atë aplikacion, dhe jepni vetëm leximin e nevojshëm. Përditësoni shtegun CA të klientit. Mos hiqni kufizime të palidhura të sistemit të skedarëve vetëm sepse kopja e parë ishte në direktorinë tuaj personale.
Lexoni gabimin e parë të dobishëm
«Nuk mund të ngarkohet skedari CA» dhe «zinxhiri i certifikatave nuk është i besuar» janë dështime të ndryshme. I pari mund të ndodhë para çdo verifikimi. I dyti mund të nënkuptojë që paketa e lexueshme ka autoritetin e gabuar ose zbatohet në lidhjen e gabuar TLS.
Pas korrigjimit të aksesit, testoni sërish nga konteksti i shërbimit. Një komandë terminali e suksesshme mbetet krahasim i dobishëm, por nuk provon cilët skedarë shikon shërbimi ose cilin konfigurim besimi përdor klienti i tij.