दो OpenVPN प्रमाणपत्र, एक CCD नाम: क्या गड़बड़ हुई

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

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

आपके प्रमाणपत्र उपकरण आपको चेतावनी नहीं देंगे, क्योंकि X.509 के भीतर की विशिष्टता और OpenVPN नीति नाम की विशिष्टता अलग-अलग प्रणालियों द्वारा लागू की गई अलग-अलग आवश्यकताएँ हैं।

सर्वर नाम खोजता है, फ़िंगरप्रिंट नहीं

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

कुछ परिनियोजन जानबूझकर मैपिंग बदल देते हैं ताकि प्रमाणित उपयोगकर्ता नाम सामान्य नाम की जगह ले, और तब उपयोगकर्ता नाम ही अद्वितीय होना चाहिए। किसी भी तरह, नीति चुनने वाला मान वही है जो आप आरक्षित करते हैं। कुछ भी जारी करने से पहले तय करें कि कौन सा है; टकराव के बाद अनुमान लगाना पूछने से अधिक महँगा है।

जहाँ दो प्राधिकरण एक ही नाम पर मिलते हैं

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

सीरियल नंबर मदद नहीं करते। X.509 माँगता है कि सीरियल अपने जारीकर्ता के दायरे में अद्वितीय हो, जो उस प्राधिकरण के लेखांकन का गुण है, वैश्विक डिवाइस पहचान नहीं। विषय जाँच भी सामान्य-नाम जाँच से भिन्न परीक्षण है: दो प्रमाणपत्र एक CN साझा कर सकते हैं पर संगठनात्मक इकाई में भिन्न हो सकते हैं, और इसलिए अलग विषय रखते हैं। इनमें से प्रत्येक गुण बना रह सकता है जबकि सर्वर अभी भी दोनों प्रमाणपत्रों को एक फ़ाइल नाम पर मैप करता है।

OpenSSL CA दस्तावेज़ उस सेटिंग unique_subject को कवर करते हैं जो उसके अपने डेटाबेस की राय नियंत्रित करती है, और ईमानदार शुरुआत यह है कि आप अपना जारीकर्ता कॉन्फ़िगरेशन पढ़ें, बजाय यह मानने के कि कोई विशेष EasyRSA या OpenSSL डिफ़ॉल्ट लागू है।

हस्ताक्षर से पहले प्रभावी नाम आरक्षित करें

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

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

नवीनीकरण जानबूझकर नाम का पुनरुपयोग करता है

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

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

मशीन पर मौजूद उपकरणों से मैपिंग की पुष्टि करें

किसी डिवाइस को उसकी नई साख देने से पहले, प्रमाणपत्र से नाम उसी तरह पढ़ें जैसे सर्वर पढ़ेगा, फिर उसकी तुलना उस नीति फ़ाइल से करें जिसके चुने जाने की आप अपेक्षा करते हैं।

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

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

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