OpenVPN पियरहरूका लागि तपाईंको विद्यमान एन्टरप्राइज CA प्रयोग गर्नुहोस्

OpenVPN मा केही पनि प्रमाणपत्र Easy-RSA बाट आउनुपर्ने माग गर्दैन, र पहिले नै संगठनात्मक PKI भएको फ्लीटले सामान्यतया दोस्रो बनाउनु हुँदैन। वास्तविक काम उपकरण छान्नु होइन, तर जारी गरिएका पहिचानहरूको अर्थ के हो, टनेलले कुन पियरहरू स्वीकार गर्छ र नवीकरण तथा रद्दीकरण प्रमाणकसम्म कसरी पुग्छ भन्ने निर्णय गर्नु हो। तलका पाँच चरणहरू क्रमैसँग पूरा गर्नुहोस्, किनकि पछिको चरणले पहिलोमा लिइएको भूमिका-निर्णय सुधार्न सक्दैन।

एउटा साझा पहिचानको सट्टा दुई भूमिका जारी गर्नुहोस्

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

समयसीमाको दबाबमा देखिने छोटो बाटोहरूको प्रतिरोध गर्नुहोस्। वेब सर्भरको कुञ्जी ल्यापटपमा प्रतिलिपि गर्दा भूमिका-जाँच जसको भर पर्छ त्यो भिन्नता मेटिन्छ, र VPN एन्डपोइन्टमा स्थापित CA हस्ताक्षर कुञ्जीले एउटा सम्झौता-ग्रस्त होस्टलाई सम्झौता-ग्रस्त पदानुक्रममा बदल्छ। PKCS12 बन्डलले एन्डपोइन्ट कुञ्जी र त्यसको चेन बोक्न सक्छ, तर त्यो पहिचान अर्को भूमिकामा पुनः प्रयोग गर्ने अनुमति कहिल्यै दिँदैन।

प्रत्येक पक्षमा विश्वास इनपुट जोड्नुहोस्

क्लाइन्ट र सर्भर दुवैलाई क्रमशः विश्वास-एङ्कर, आफ्नै पहिचान र स्पष्ट भूमिका-अपेक्षा चाहिन्छ। तीनवटै उल्लेख गर्ने क्लाइन्ट खण्ड यस्तो देखिन्छ।

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

सर्भर पक्षले remote-cert-tls client र आफ्नै प्रमाणपत्रसँग यसको प्रतिबिम्ब बनाउँछ, र यही क्लाइन्ट प्रमाणपत्रलाई सर्भरको रूपमा स्वीकार हुनबाट रोक्छ। नाम-जाँच भूमिका-जाँचबाट अलग निर्णय हो। ब्राउजर-शैलीको होस्टनेम मिलान मान्नुको सट्टा कुन फिल्ड तुलना गरिन्छ हेर्न तैनाथ कन्फिगरेसन पढ्नुहोस्। दुवै पक्षले आफूले कुन जारीकर्तामा भरोसा गर्छन् भन्ने पनि स्पष्ट बनाउनुपर्छ, किनकि सम्पूर्ण फ्लीटमा साझा फाइल मार्ग साझा नीतिसरह हुँदैन।

विश्वास फराकिलो नबनाई मध्यस्थ प्रमाणपत्रहरू पुर्‍याउनुहोस्

दुई पक्षले एउटै जारी-चेन साझा गर्नुपर्दैन। जब कुनै पियरले मध्यस्थद्वारा हस्ताक्षरित प्रमाणपत्र प्रस्तुत गर्छ, प्रमाणित गर्ने पक्षलाई त्यो मध्यस्थ उपलब्ध चाहिन्छ, र OpenVPN ले विश्वास-एङ्कर इनपुटलाई स्थानीय रूपमा प्रस्तुत चेन पूरा गर्न प्रयोग हुने थप प्रमाणपत्रहरूबाट छुट्याउँछ। OpenVPN 2.6 को TLS विकल्प सन्दर्भ ले दुवैको दस्तावेजीकरण गर्छ।

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

नवीकरण र रद्दीकरण VPN प्रमाणकहरूसम्म कसरी पुग्छ, कुन जारीकर्ताहरू महत्त्वपूर्ण छन् र सूची कसले प्रकाशित गर्छ भन्ने सहित PKI टोलीसँग सहमति गर्नुहोस्। प्रमाणपत्रमा अन्तर्निहित CRL वितरण बिन्दु निर्देश हो, कसैले त्यो ल्यायो भन्ने प्रमाण होइन।

रद्दीकरण वास्तवमा कसरी आउँछ निर्णय गर्नुहोस्

crl-verify ले प्रमाणकलाई फाइल वा एन्डपोइन्टसँग परामर्श गराउँछ, र त्यो व्यवस्थालाई मालिक र रिफ्रेस मार्ग चाहिन्छ। तैनाथीको क्रममा एकपटक प्रतिलिपि गरिएको सूचीले प्रमाणपत्र पहिलोपटक रद्द हुँदा चुपचाप तपाईंको सुरक्षा गर्न छोड्छ।

अपेक्षित प्रसार समय लेख्नुहोस् र रद्द गर्न तयार भएको प्रमाणपत्रसँग परीक्षण गर्नुहोस्। यदि VPN होस्टमा सूची रिफ्रेस गर्न सकिँदैन भने, विकल्प छोटो वैधता अवधि र वास्तवमै चल्ने नवीकरण प्रक्रिया हो, URL छ भन्दैमा रद्दीकरण काम गर्छ भन्ने अनुमान होइन।

वास्तविक क्लाइन्टसँग स्वीकृति प्रमाणित गर्नुहोस्

अनुमति पाउनुपर्ने क्लाइन्ट जोड्नुहोस् र लगमा वार्ता गरिएको प्रमाणपत्रको विवरण पुष्टि गर्नुहोस्। त्यसपछि असफल हुनुपर्ने केसहरू प्रयास गर्नुहोस्: सर्भरका रूपमा प्रस्तुत क्लाइन्ट प्रमाणपत्र, विश्वास-एङ्करबाहिरको जारीकर्ताको प्रमाणपत्र, र थप भएमा रद्द गरिएको प्रमाणपत्र।

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