Windows पर OpenVPN 3 और Connect में cryptoapicert क्यों विफल होता है

आप एक काम करता OpenVPN 2 प्रोफ़ाइल नए Windows क्लाइंट में कॉपी करते हैं, और पुराने क्लाइंट को खुद मिलने वाला प्रमाणपत्र अब प्रस्तावित नहीं होता। जिस पंक्ति ने यह संभव बनाया वह Community 2 क्लाइंट का Windows-विशिष्ट चयनकर्ता है, और नया अनुप्रयोग अलग क्रेडेंशियल पथ वाला दूसरा प्रोग्राम है। प्रोफ़ाइल उस एक पंक्ति के अलावा अपरिवर्तित है, और यही अंतर को देखना कठिन बनाता है।

उस रिपोर्ट में तीन परतें मिला दी जाती हैं: Community क्लाइंट, मूल लाइब्रेरी और किसी द्वारा स्थापित फ़्रंटएंड। इनमें से केवल एक ने कभी इस निर्देश को समझा।

जहाँ विकल्प मौजूद है वहाँ उसका क्या अर्थ है

Windows पर Community OpenVPN 2 क्लाइंट में, cryptoapicert ऐसे प्रमाणपत्र का नाम देता है जिसे क्लाइंट को फ़ाइल के बजाय Windows प्रमाणपत्र संग्रह में खोजना चाहिए। यह Windows-विशिष्ट सुविधा है, और यह काम करती है क्योंकि वह क्लाइंट संग्रह की सूची बनाना और परिणामी कुंजी अपने TLS स्टैक को देना जानता है। इसलिए निर्देश उस क्लाइंट की कॉन्फ़िगरेशन भाषा का हिस्सा है, OpenVPN प्रोटोकॉल का गुण नहीं। संचरण प्रारूप में कुछ भी उसे नहीं ढोता।

वही पंक्ति किसी दूसरे अनुप्रयोग में कॉपी करें और आपने ऐसा शब्द कॉपी किया है जिसे नया प्रोग्राम पार्स कर सकता है, अनदेखा कर सकता है या अस्वीकार कर सकता है। निर्देश प्रोटोकॉल की विशेषता नहीं है, और यह तो OpenVPN बोलने वाले हर क्लाइंट की विशेषता भी नहीं है।

मूल लाइब्रेरी इसके बजाय क्या प्रदान करती है

OpenVPN 3 Core ऐसी लाइब्रेरी है जिसे अन्य अनुप्रयोग एम्बेड करते हैं, और यह बाहरी क्रेडेंशियल को संग्रह खोज के बजाय API के माध्यम से संभालती है। एम्बेड करने वाला अनुप्रयोग प्रमाणपत्र श्रृंखला देता है और बाद में लाइब्रेरी से बाहरी कुंजी से हस्ताक्षर करने को कहता है, और लाइब्रेरी ऐसा करने के लिए अनुप्रयोग में वापस कॉल करती है। यह अधिक सामान्य डिज़ाइन है, और इसका अर्थ है कि फ़्रंटएंड तय करता है कि कौन से प्रदाता मौजूद हैं। लाइब्रेरी की अपनी विकल्प प्रक्रिया में cryptoapicert उन निर्देशों में दिखता है जो लागू नहीं हैं, जो ज़िम्मेदारी के इस विभाजन के अनुरूप है।

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

Windows फ़्रंटएंड इसके बजाय क्या करता है

OpenVPN Connect दूसरा मार्ग लेता है: ऑपरेटर PKCS#12 फ़ाइल आयात करता है जिसमें प्रमाणपत्र और उसकी निजी कुंजी है, उसे इस उद्देश्य के लिए बनाए गए OpenVPN Certificate Store में रखता है, फिर बाहरी प्रमाणपत्र को प्रोफ़ाइल को सौंपता है। यह जानबूझकर किया गया आयात चरण है, व्यक्तिगत संग्रह में जो है उसकी स्वचालित खोज नहीं। यह अंतर तब मायने रखता है जब कोई मान लेता है कि किसी दूसरे उद्देश्य के लिए स्थापित प्रमाणपत्र बस क्लाइंट की सूची में दिख जाएगा।

आयात का कुंजी नीति पर भी परिणाम होता है, क्योंकि कुंजी को P12 फ़ाइल में निर्यात करना ठीक वही है जिसे गैर-निर्यात योग्य कुंजी रोकने के लिए बनाई गई है। यह कॉन्फ़िगरेशन का नहीं, नीति का प्रश्न है, और किसी के आयात का प्रयास करने से पहले इसका उत्तर मिलना चाहिए।

कुंजी की नीति से मेल खाता मार्ग चुनें

यदि क्रेडेंशियल निर्यात योग्य है और नीति प्रलेखित आयात की अनुमति देती है, तो संगठन की संरक्षित नामांकन प्रक्रिया का उपयोग करें और अस्थायी P12 तथा उसका पासवर्ड लॉग और स्क्रिप्ट से बाहर रखें। यदि कुंजी को कभी स्मार्ट कार्ड या संरक्षित प्रदाता नहीं छोड़ना चाहिए, तो ऐसा क्लाइंट और प्रदाता संयोजन चुनें जो उस आवश्यकता का स्पष्ट समर्थन करता हो, या आपके द्वारा स्थापित संस्करण के लिए विक्रेता से पुष्टि लें। दोनों में से कोई शाखा दूसरी का विकल्प नहीं है।

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

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