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 ओळख वेगवेगळे निष्कर्ष आहेत, आणि ते वेगळे ठेवणे हेच फ्रंटएंडची मर्यादा कमकुवत प्रमाणपत्र धोरणात बदलण्यापासून रोखते।