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 सामान्य home डिरेक्टरीची ठिकाणे सेवेला उपलब्ध होऊ देत नाही. सर्टिफिकेट फाइलचा मोड बदलल्याने नेमस्पेस मर्यादा जात नाही. कॉन्फिगर केलेली रूट डिरेक्टरीदेखील सेवेच्या आत पूर्ण पाथ काय दर्शवतो ते बदलू शकते.

सेवा कॉन्फिगरेशनसाठी योग्य जागा वापरा, जसे /etcखाली त्या ॲपची डिरेक्टरी, आणि आवश्यक तेवढाच वाचन प्रवेश द्या. क्लायंटचा CA पाथ तिथे बदला. पहिली प्रत वैयक्तिक home डिरेक्टरीत होती म्हणून असंबंधित फाइल सिस्टिम मर्यादा काढू नका.

पहिली उपयोगी त्रुटी वाचा

«CA फाइल लोड करता येत नाही» आणि «सर्टिफिकेट चेन विश्वसनीय नाही» या वेगळ्या त्रुटी आहेत. पहिली क्लायंटने काही पडताळण्याआधीच येऊ शकते. दुसरीचा अर्थ वाचता येणाऱ्या बंडलमध्ये चुकीचे प्राधिकरण आहे किंवा ते चुकीच्या TLS जोडणीला लागू होत आहे असा असू शकतो.

ॲक्सेस सुधारल्यानंतर सेवेच्या संदर्भातून पुन्हा तपासा. यशस्वी टर्मिनल कमांड उपयोगी तुलना आहे, पण सेवा कोणत्या फाइल पाहते किंवा क्लायंट कोणती विश्वास सेटिंग वापरतो ते सिद्ध करत नाही.