स्व-हस्ताक्षरित ग्राहक प्रमाणपत्र? VPN सर्भरले अझै अस्वीकार गर्छ

अपरेटरले ठेगाना र प्रयोगकर्ता नाम पठाउँछ, र ग्राहकले CA फाइल, प्रमाणपत्र र कुञ्जी माग्छ। यी तीनलाई स्थानीय रूपमा बनाउनु अर्को स्पष्ट कदम जस्तो लाग्छ। यसले तपाईंको आफ्नै मेसिनले मात्र विश्वास गर्ने प्रमाणपत्र बनाउँछ। सर्भरको विश्वास तपाईंले नियन्त्रण नगर्ने CA मा आधारित छ, त्यसैले ह्यान्डशेक सुरु हुनुअघि नै सकिन्छ।

विश्वास सर्भरमा बस्छ, तपाईंको प्रोफाइलमा होइन

प्रमाणपत्र प्रमाणीकरण एक तुलना हो। ग्राहकले प्रमाणपत्र प्रस्तुत गर्छ; गेटवेले त्यो आफ्नो कन्फिगरेसनका कुनै CA ले हस्ताक्षर गरेको हो कि भनेर जाँच्छ।

तपाईंको प्रोफाइलले सर्भर प्रमाणित गर्न ग्राहकले प्रयोग गर्नुपर्ने CA फाइलको नाम दिन्छ। सर्भरले तपाईंलाई प्रमाणित गर्न प्रयोग गर्नुपर्ने CA को नाम दिन सक्दैन। कन्फिगरेसनको त्यो आधा भाग तपाईंको होइन।

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

किन स्व-हस्ताक्षरित प्रमाणपत्रले यसको ठाउँ लिन सक्दैन

स्व-हस्ताक्षरित प्रमाणपत्र आफ्नै कुञ्जीले हस्ताक्षर गरिन्छ। हस्ताक्षर त्यही फाइलविरुद्ध प्रमाणित हुन्छ, जसले यसलाई आत्म-संगत र अरू कसैको गेटवेका लागि प्रमाणका रूपमा निरुपयोगी बनाउँछ।

गेटवेले प्रमाणपत्र आन्तरिक रूपमा संगत छ कि भनेर सोध्दैन। विश्वसनीय जारीकर्ताले हस्ताक्षर गरेको हो कि भनेर सोध्छ।

त्यसैले त्रुटि सन्देशहरू भ्रमित गर्छन्। ग्राहकले सर्भरको समस्या जस्तो सुनिने प्रमाणीकरण असफलता रिपोर्ट गर्न सक्छ, जबकि सर्भरले अज्ञात जारीकर्ता लग गर्छ। दुवैले एउटै अमिल्दोलाई विपरीत छेउबाट वर्णन गर्छन्।

CSR मार्गले तपाईंको निजी कुञ्जी राख्छ

तपाईं अझै धेरै काम स्थानीय रूपमा गर्न सक्नुहुन्छ। कुञ्जी जोडी बनाउनुहोस्, सार्वजनिक आधा वरिपरि प्रमाणपत्र हस्ताक्षर अनुरोध बनाउनुहोस् र त्यो अनुरोध अपरेटरलाई पठाउनुहोस्। तपाईंको मेसिनबाट अनुरोध मात्र जान्छ। निजी आधा तपाईंले बनाएकै ठाउँमा रहन्छ।

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

अपरेटरले आफ्नो CA ले अनुरोधमा हस्ताक्षर गरेर प्रमाणपत्र फर्काउँछ। तपाईंको निजी कुञ्जी कहिल्यै यात्रा गरेन, र नतिजा गेटवेले विश्वास गर्ने एङ्करसँग शृंखलाबद्ध हुन्छ।

व्यवस्थित सेवाहरूले प्रायः CSR छोडेर पूरै बन्डल जारी गर्छन्। त्यही प्रदायकले पहिले नै टनेल अन्त्य गरी CA राखेको हुन्छ भने त्यो उचित साटासाट हो। कुञ्जी राख्नुले यसको संरक्षण सुधार्दैन, किनकि प्रदायकले जुनसुकै बेला नयाँ बनाउन सक्छ।

बन्डलहरू आयात गरिन्छन्, स्थापना गरिँदैनन्

सुरक्षित जस्तो नाम भएका विक्रेता बन्डलहरू प्रायः OpenVPN प्रोफाइल हुन्छन्। तिनमा कन्फिगरेसन र कहिलेकाहीँ प्रमाणपत्रहरू हुन्छन्, र तिनले केही पनि स्थापना गर्दैनन्। प्रोटोकल बोल्ने ग्राहकमा फाइल आयात गर्नुहोस्, र जडान कन्फिगर हुन्छ।

व्यवहार नियम सामग्रीबाट आउँछ। प्रोफाइलमा निजी कुञ्जी समावेश छ भने त्यो प्रमाण हो र पासवर्ड जस्तै हेरचाहको योग्य छ: इमेल छैन, भण्डार छैन, साझा डाउनलोड फोल्डर छैन। जब अपरेटरले ca.crt, client.crt र client.key अलग-अलग दिन्छ, तिनलाई प्रतिबन्धित अनुमतिसँगै राख्नुहोस् र प्रोफाइललाई तिनतिर देखाउनुहोस्।

अपरेटरले छुटाएका हुन सक्ने जाँचहरू थप्नुहोस्

राउटरले बनाएको प्रोफाइलमा कहिलेकाहीँ पियर प्रमाणीकरण हुँदैन। remote-cert-tls server ले पियर प्रमाणपत्रमा सर्भर प्रमाणीकरणको उद्देश्य हुनुपर्ने माग गर्छ, ताकि ग्राहक प्रमाणपत्रलाई सर्भरको रूपमा पुनः चलाउन नसकियोस्। त्यो एक लाइन स्पष्ट औचित्यसहितको सानो परिवर्तन हो।

verify-x509-name अपरेटरले अपेक्षित विषय वा SAN को नाम दिन सक्दा अझ अगाडि जान्छ। दुवै प्रोफाइलमा साना थप हुन्, र दुवै उचित छन्। आयात गर्नुअघि तपाईंले पाएको कुरा जाँच्नुहोस्।

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

प्रमाणीकरण सेटिङहरू टुटेको शृंखलाको मर्मत होइनन्। जारीकर्ता गलत छ भने उत्तर सही CA को प्रमाणपत्र हो, जाँच बन्द गर्ने झन्डा होइन। प्रमाणीकरण बन्द गर्दा प्रमाणीकरण असफलता नदेखिएको असफलतामा बदलिन्छ।

एउटा बन्डल माग्नुहोस्: PEM रूपमा अधिकारीको प्रमाणपत्र, त्यो अधिकारीले हस्ताक्षर गरेको ग्राहक प्रमाणपत्र, तपाईंले बनाएको वा तपाईंले विश्वास गर्ने माध्यमबाट आएको कुञ्जी, र प्रमाणपत्रले प्रस्तुत गर्नुपर्ने ठ्याक्कै सर्भर नाम। त्यही सन्देशमा म्याद सकिने मिति लेख्नुहोस्, किनकि म्याद सकिएको प्रमाणपत्र महिनौंपछि नेटवर्क खराबी जस्तो देखिन्छ।