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 कनेक्शन पर लागू हो रहा है।

पहुँच ठीक करने के बाद सेवा के कॉन्टेक्स्ट से फिर जाँचें। सफल टर्मिनल कमांड उपयोगी तुलना है, लेकिन यह सिद्ध नहीं करती कि सेवा कौन-सी फ़ाइलें देखती है या क्लाइंट कौन-सा ट्रस्ट सेटअप इस्तेमाल करता है।