systemd სერვისი პროქსის სწვდება, მაგრამ CA ფაილს ვერ კითხულობს
თუ პროქსის სერტიფიკატის გამართვა მხოლოდ ინტერაქტიულ გარსში მუშაობს, შეამოწმეთ სერვისის მომხმარებლის ფაილის წვდომა და systemd შეზღუდვები.
დააყენეთ დამტკიცებული CA ნაკრები და მოთხოვნა ტერმინალში მუშაობს. სერვისი ისევ სერტიფიკატის ჩატვირთვის შეცდომას აჩვენებს. პროქსის IP-ის შეცვლამდე შეამოწმეთ, შეუძლია თუ არა ამ პროცესს იმავე ფაილის გახსნა.
სერვისი შეიძლება სხვა Unix მომხმარებლით მუშაობდეს, სხვა კატალოგში იწყებოდეს ან შეზღუდულ ფაილურ სისტემას ხედავდეს. თქვენი სესიისთვის მოქმედი გზა მისთვის ავტომატურად მოქმედი არ არის.
დაიწყეთ აბსოლუტური გზით
შეამოწმეთ რეალურ კლიენტში დაყენებული გზა. მაგალითად, curl-ის --cacert დანიშნულების CA ნაკრებს ირჩევს; HTTPS პროქსის ცალკე პროქსი CA პარამეტრები აქვს. სხვა კლიენტები საკუთარ კონფიგურაციის გასაღებებს ან გარემოს ცვლადებს იყენებენ.
შეამოწმეთ ფაილიც და მისკენ მიმავალი კატალოგებიც:
namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectory
ეს დიაგნოსტიკური მაგალითებია და არა ფაილის ყველასთვის ჩასაწერად გახდომის მითითება. კატალოგების გავლის უფლებაც ისეთივე მნიშვნელოვანია, როგორც ბოლო ფაილის წაკითხვა.
პრობლემა შესაძლოა მხოლოდ უფლებები არ იყოს
ProtectHome=yes-ით systemd სტანდარტული სახლის კატალოგების ადგილებს სერვისისთვის მიუწვდომელს ხდის. სერტიფიკატის ფაილის რეჟიმის შეცვლა სახელთა სივრცის შეზღუდვას არ ხსნის. დაყენებულმა ძირეულმა კატალოგმაც შეიძლება შეცვალოს, რას მიუთითებს აბსოლუტური გზა სერვისის შიგნით.
გამოიყენეთ სერვისის კონფიგურაციისთვის შესაფერისი ადგილი, მაგალითად აპისთვის განკუთვნილი კატალოგი /etc-ის ქვეშ, და მხოლოდ საჭირო წაკითხვის უფლება მიეცით. განაახლეთ კლიენტის CA გზა. არ მოხსნათ არაკავშირში მყოფი ფაილური შეზღუდვები მხოლოდ იმიტომ, რომ პირველი ასლი პირად სახლის კატალოგში იყო.
წაიკითხეთ პირველი გამოსადეგი შეცდომა
«CA ფაილი ვერ იტვირთება» და «სერტიფიკატების ჯაჭვი სანდო არ არის» განსხვავებული შეცდომებია. პირველი შეიძლება კლიენტის მიერ რაიმეს შემოწმებამდე მოხდეს. მეორე შეიძლება ნიშნავდეს, რომ წაკითხვად ნაკრებში არასწორი გამცემი ორგანოა ან ის არასწორ TLS კავშირზე გამოიყენება.
წვდომის გასწორების შემდეგ სერვისის კონტექსტიდან თავიდან შეამოწმეთ. ტერმინალში წარმატებული ბრძანება კვლავ გამოსადეგი შედარებაა, მაგრამ ვერ ამტკიცებს, რომელ ფაილებს ხედავს სერვისი ან რომელ ნდობის კონფიგურაციას იყენებს კლიენტი.