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 पहचानों पर हस्ताक्षर करता है, जहाँ पदानुक्रम अनुमति देता है। अगर नहीं देता, तो चौड़े एंकर को जानबूझकर स्वीकृत जोखिम के रूप में दस्तावेज़ करें, उसे अंतर्निहित छोड़ने के बजाय।

PKI टीम के साथ सहमत हों कि नवीनीकरण और रद्दीकरण VPN सत्यापनकर्ताओं तक कैसे पहुँचते हैं, जिसमें यह भी शामिल है कि कौन-से जारीकर्ता मायने रखते हैं और सूची कौन प्रकाशित करता है। प्रमाणपत्र में अंतर्निहित CRL वितरण बिंदु एक निर्देश है, इस बात का सबूत नहीं कि किसी ने उसे लाया।

तय करें कि रद्दीकरण वास्तव में कैसे पहुँचता है

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

अपेक्षित प्रसार समय लिखें और उसे ऐसे प्रमाणपत्र से परखें जिसे रद्द करने को आप तैयार हैं। अगर VPN होस्ट पर सूची रीफ़्रेश नहीं हो सकती, तो विकल्प छोटी वैधता अवधि और वास्तव में चलने वाली नवीनीकरण प्रक्रिया है, URL होने से रद्दीकरण काम करता है यह मान लेना नहीं।

असली क्लाइंट से स्वीकृति साबित करें

ऐसा क्लाइंट जोड़ें जिसे अनुमति मिलनी चाहिए और लॉग में बातचीत किए गए प्रमाणपत्र का विवरण पुष्टि करें। फिर वे मामले आज़माएँ जिनमें विफल होना चाहिए: सर्वर के रूप में प्रस्तुत क्लाइंट प्रमाणपत्र, ट्रस्ट एंकर के बाहर के जारीकर्ता का प्रमाणपत्र, और रद्द किया गया प्रमाणपत्र यदि आपके पास एक अतिरिक्त हो।

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