दो OpenVPN प्रमाणपत्र एक ही CCD नीति क्यों साझा कर सकते हैं

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

सर्वर नाम तय करता है, क्रम संख्या नहीं

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

इस तरह CA पक्ष की विशिष्टता जाँच पास हो जाती है जबकि VPN अभी भी टकराता है। दोनों जाँचें अलग-अलग सवालों का जवाब देती हैं।

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

मैपिंग वास्तव में कौन-सा नाम इस्तेमाल करती है

सामान्य प्रमाणपत्र खोज सामान्य नाम का उपयोग करती है। प्रमाणित उपयोगकर्ता नाम मैप करने के लिए सेट किया गया सर्वर इसके बजाय वह मान इस्तेमाल करता है, जिससे प्रमाणपत्र का सामान्य नाम नीति चयन के लिए अप्रासंगिक हो जाता है। कौन-सी मैपिंग लागू है यह देखने के लिए चल रहा कॉन्फ़िगरेशन पढ़ें।

दोनों मैपिंग एक साथ मौजूद हो सकती हैं, और तब परिणाम उस क्रम पर निर्भर करता है जिसमें सर्वर उन्हें तय करता है। सामान्य नाम पर वापस गिरने वाली उपयोगकर्ता-नाम मैपिंग चुपचाप ऐसा प्रमाणपत्र स्वीकार कर लेगी जिसे रजिस्टर ने कभी मंज़ूर नहीं किया। प्रभावी नाम को उस आदेश के पास लिखें जिसने उसे बनाया, ताकि अगले ऑपरेटर को क्रम दोबारा खोजना न पड़े। प्रति मैपिंग एक कनेक्शन जाँचना सस्ता है और सवाल तय कर देता है।

मैपिंग जो भी उत्पन्न करे, वही आरक्षित करने योग्य मान है। CA में सामान्य नाम आरक्षित करना जबकि सर्वर उपयोगकर्ता नामों पर टिका है, गलत चीज़ आरक्षित करना है।

दो CA एक ही नाम मंज़ूर कर सकते हैं

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

वही तर्क उस CA पर लागू होता है जो सामान्य नाम की विशिष्टता के बजाय पूर्ण विषय की विशिष्टता लागू करता है।

सामान्य नाम साझा करने पर भी संगठनात्मक इकाई में भिन्न दो प्रमाणपत्रों के विषय अलग होते हैं, इसलिए CA कोई टकराव नहीं बताता जबकि सर्वर एक नाम देखता है। डिफ़ॉल्ट मान लेने के बजाय वह सेटिंग जाँचें जिसे आपका जारीकर्ता उपकरण वास्तव में इस्तेमाल करता है। openssl ca दस्तावेज़ में unique_subject का प्रबंधन ही वहाँ प्रासंगिक नियंत्रक है, और उस उपकरण के चारों ओर के रैपर आमतौर पर उसे बदलने के बजाय उजागर करते हैं।

नवीनीकरण आरक्षित पुनरुपयोग है, टकराव नहीं

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

प्रतिस्थापन सौंपने से पहले पढ़ें कि प्रमाणपत्र में वास्तव में क्या है। विषय पंक्ति वही फ़ील्ड है जिसे सर्वर मैप करेगा, फ़ाइल का नाम चाहे जो सुझाए।

openssl x509 -in device42.crt -noout -subject -serial -issuer

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