שירות systemd מגיע לפרוקסי, אבל לא לקובץ ה-CA שלו

התקנתם את חבילת ה-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 שגוי.

אחרי תיקון הגישה, בדקו שוב מהקשר השירות. פקודה מוצלחת במסוף היא עדיין השוואה מועילה, אבל אינה מוכיחה אילו קבצים השירות רואה או באיזו הגדרת אמון משתמש הלקוח שלו.