एक सामान्य नाम, दो प्रमाणपत्र: अनुमति सूची या निरसन?

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

सर्वर जो नामकरण नीति उपयोग करता है, उससे शुरू करें

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

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

दोनों मार्ग एक ही प्रमाणपत्र के लिए भिन्न अनुमत नामों का समूह बनाते हैं। यहाँ अनुमान लगाने का अर्थ है गलत फ़ाइल संपादित करना और यह निष्कर्ष निकालना कि नियंत्रण काम नहीं करता।

जाँचें कि वास्तव में ग्राहक को क्या स्वीकार करता है

एक client-config-dir मिलती फ़ाइल के साथ प्रति-ग्राहक विकल्प देता है; अकेले में यह स्वीकृति नियम नहीं है। नाम से स्वीकृति के लिए आवश्यक है ccd-exclusive, जो ऐसे ग्राहकों को अस्वीकार करता है जिनके पास मिलती फ़ाइल नहीं है। इसे चालू परिनियोजन पर सक्षम करने से वे सभी डिस्कनेक्ट हो जाते हैं जिनके नाम की फ़ाइल नहीं है, इसलिए कुछ भी बदलने से पहले फ़ाइलें गिन लें।

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

गिनती ही जाँच है: निर्देशिका सूची की तुलना उन पहचानों से करें जिनके जुड़ने की आप अपेक्षा करते हैं।

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

गेटवे जो CRL लोड करता है उसकी जाँच करें

CRL निरसित प्रमाणपत्रों को जारीकर्ता और क्रम संख्या से नामित करता है, जो वह सूक्ष्मता है जो नाम जाँच में नहीं है। दो प्रमाणपत्र एक सामान्य नाम साझा कर सकते हैं और क्रम संख्या में भिन्न हो सकते हैं, और केवल क्रम-संख्या स्तर की सूची ही उन्हें अलग करती है।

फ़ाइल पर बिल्कुल भी भरोसा करने से पहले कॉन्फ़िगर किया गया पथ, जारी करने की तिथि और अगले अद्यतन का फ़ील्ड पुष्टि करें।

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

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

बदलें, फिर दोनों परिणाम सिद्ध करें

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

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

पहले से स्थापित सत्र अलग बात है, क्योंकि निरसन नए प्रमाणीकरणों पर लागू होता है, जब तक गेटवे को जीवित कनेक्शन गिराने के लिए भी कॉन्फ़िगर न किया गया हो। किसी से वादा करने से पहले तय करें कि तत्काल हटाना आवश्यक है या नहीं।

नाम जाँच जो कभी नहीं कर सकती

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

जहाँ प्रमाणपत्र-स्तरीय नियंत्रण आवश्यक है, वहाँ ऐसा तंत्र उपयोग करें जो प्रमाणपत्र का नाम ले: CRL प्रविष्टियाँ, या सत्यापन हुक जो ऑपरेटर द्वारा बनाए रखी गई फ़िंगरप्रिंट की जाँच करता है। दोनों में रखरखाव का खर्च है, और दोनों उस वस्तु के बारे में ईमानदार हैं जिसकी वे जाँच करते हैं। OpenVPN 2.6 पुस्तिका दस्तावेज़ित करती है crl-verify और ग्राहक-विशिष्ट स्वीकृति को अलग विकल्पों के रूप में, इसी कारण।

लिखें कि कौन-सा नियंत्रण कौन-सा काम करता है, फिर नकारात्मक स्थिति का परीक्षण करें। ऐसा निरसन जिसे आपने कभी किसी कनेक्शन को अस्वीकार करते नहीं देखा, वह ऐसा कॉन्फ़िगरेशन है जिसके काम करने की आप आशा करते हैं।