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 जडानमा लागू भएको छ भन्ने हुन सक्छ।

पहुँच सुधारेपछि सेवाको सन्दर्भबाट फेरि परीक्षण गर्नुहोस्। सफल टर्मिनल कमान्ड उपयोगी तुलना हो, तर सेवाले कुन फाइल देख्छ वा क्लाइन्टले कुन विश्वास सेटअप चलाउँछ भन्ने प्रमाण होइन।