निरस्त क्लाइंट अब भी जुड़ता है: सूची कभी पहुँची ही नहीं
निरस्तीकरण प्रमाणपत्र सत्यापन का इनपुट है, सत्र समाप्त करने वाला आदेश नहीं। तुलना कीजिए कि नया कनेक्शन और चलती टनल सूची को कैसे देखते हैं।
निरस्तीकरण कभी चलती टनल में घुसकर सत्र नहीं मिटाता। सूची प्रमाणपत्र सत्यापन का इनपुट है और TLS सत्र आरंभ करने वाले नियंत्रण-चैनल के आदान-प्रदान के दौरान देखी जाती है। यह एक तथ्य दोनों आश्चर्य समझाता है: निरस्त क्लाइंट फिर जुड़ता है, क्योंकि सूची कभी सत्यापनकर्ता तक नहीं पहुँची, और मौजूदा सत्र जीवित रहता है, क्योंकि किसी ने कुछ भी दोबारा सत्यापित नहीं किया।
सूची एक इनपुट है, कोई क्रिया नहीं
सत्र बनाते समय सर्वर क्लाइंट प्रमाणपत्र को अपने विश्वास-एंकरों के विरुद्ध मान्य करता है, और निरस्तीकरण निर्देश उस निर्णय में सूची-खोज जोड़ता है। जाँच सर्वर पर होती है, इसलिए क्लाइंट देख नहीं सकता कि उसका प्रमाणपत्र निरस्त हो गया है और वही प्रमाणपत्र देता रहता है। इसलिए जो प्रोफ़ाइल अब भी जुड़ता है वह केवल यह सिद्ध करता है कि किसी सत्यापनकर्ता ने श्रृंखला स्वीकार की, यह नहीं कि निरस्तीकरण विफल रहा।
सूची स्वयं एक हस्ताक्षरित वस्तु है जिसकी जारी तिथि और अगली अद्यतन तिथि होती है। असंबंधित सूची, किसी दूसरे प्राधिकारी द्वारा हस्ताक्षरित सूची या जिसकी अगली अद्यतन तिथि बीत चुकी है, वर्तमान सूची का विकल्प नहीं है, और पुरानी सूची अस्वीकार होती है या चुपचाप स्वीकार, यह परिनियोजन पर निर्भर है।
नया कनेक्शन बनाम चलता सत्र
निरस्तीकरण का मूल्यांकन सत्र स्थापित या पुनः बातचीत होने पर होता है, हर पैकेट पर डेटा-चैनल के विरुद्ध नहीं। जो क्लाइंट पहले से जुड़ा है उसके पास ट्रैफ़िक कुंजियाँ होती हैं, इसलिए उसका प्रमाणपत्र सूची में आने के बाद भी वह पैकेट पास करता रहता है। डिफ़ॉल्ट पुनः-बातचीत अंतराल घंटों में मापा जाता है, इसलिए अद्यतन सूची नए आने वालों पर लागू हो सकती है जबकि चलती टनल बनी रहती है।
| Situation | What the list does | When it applies |
|---|---|---|
| Fresh connection | Blocks the handshake | At verification, immediately |
| Renegotiation | Blocks the new exchange | At the next renegotiation interval |
| Established data channel | Nothing | Until the session ends |
तत्काल प्रवर्तन के लिए केवल सूची नहीं, जानबूझकर की गई कार्रवाई चाहिए। सेवा पुनः आरंभ करने से हर क्लाइंट दोबारा जुड़ने को बाध्य होता है, जबकि प्रबंधन इंटरफ़ेस से एक सत्र समाप्त करने पर बाकी अछूते रहते हैं। हर घटना के लिए एक चुनें और लिखें कि आपने कौन-सा इस्तेमाल किया। दोनों विकल्पों का प्रभाव-दायरा अलग है, और यही असली निर्णय है।
वह फ़ाइल पहुँचाइए जिसे सत्यापनकर्ता वास्तव में पढ़ता है
सूची प्राधिकारी के रिकॉर्ड से बनाकर फिर प्रमाणपत्र सत्यापित करने वाली हर मशीन पर प्रतिलिपि की जानी चाहिए। इसे CA होस्ट पर बनाकर सर्वर पर कभी संस्थापित न करना सबसे आम विफलता है, और यह ठीक टूटी हुई निरस्तीकरण सुविधा जैसी दिखती है।
ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pemदो ब्यौरे तय करते हैं कि फ़ाइल वास्तव में पढ़ी जाती है या नहीं। सापेक्ष पथ कॉन्फ़िगरेशन निर्देशिका के सापेक्ष हल होता है, इसलिए ऑपरेटर के होम में छोड़ी गई प्रतिलिपि कभी न मिले। और डेमन आमतौर पर शुरू होने के बाद विशेषाधिकार छोड़ देता है, इसलिए रनटाइम खाते को हर मूल निर्देशिका पर खोज अनुमति और फ़ाइल पर पढ़ने की अनुमति चाहिए। दोनों को रनटाइम खाते से जाँचें, root से नहीं, वरना परीक्षण गलत बात सिद्ध करता है।
systemd होस्ट पर कठोर किया गया यूनिट भी पथ छिपा सकता है, केवल-पठन दृश्य या सुरक्षित सिस्टम निर्देशिका के साथ। सेवा के भीतर से यह गुम फ़ाइल से अलग नहीं पहचाना जा सकता, इसलिए अनुमति की गलती खोजने जाने से पहले यूनिट के प्रतिबंध जाँचें। फ़ाइल के मोड को दोष देने से पहले यूनिट फ़ाइल पढ़ें।
सर्वर पर पुष्टि करें, क्लाइंट पर नहीं
सर्वर लॉग बताता है क्या हुआ: सूची खोलना, उसे लोड करना, या निरस्त क्रमांक के साथ सत्यापन विफल होना। क्लाइंट केवल सामान्य हैंडशेक विफलता बताता है, इसलिए निरस्तीकरण निर्णय खोजने के लिए क्लाइंट लॉग खराब जगह है।
निरस्त प्रोफ़ाइल से नए प्रयास के साथ सत्यापित करें और फिर रुकें। उस प्रोफ़ाइल से सफल कनेक्शन ही फ़ाइल पथ और रनटाइम खाते की जाँच करने का संकेत है, यह मानने का नहीं कि सूची गलत थी। उस सफल प्रयास को स्वीकृति परीक्षण के रूप में रखें, और जो पुनः-कनेक्शन आपने नहीं देखा उसे न गिनें।
क्या कुछ निरस्त नहीं करता
लैपटॉप से प्रोफ़ाइल मिटाना, क्लाइंट से प्रमाणपत्र फ़ाइल हटाना या उपयोगकर्ता से जुड़ना बंद करने को कहना सर्वर पर कुछ नहीं बदलता। प्रमाणपत्र तब तक वैध रहता है जब तक प्राधिकारी निरस्तीकरण दर्ज न करे और सत्यापनकर्ता परिणामी सूची न पढ़े।
इसीलिए श्रृंखला लिखना उचित है: निरस्तीकरण दर्ज करें, सूची बनाकर हस्ताक्षर करें, ठीक वही फ़ाइल वितरित करें, और पुष्टि करें कि सेवा खाता उसे पढ़ सकता है। हर कड़ी छोटी है, और कोई भी छूटी हुई कड़ी निरस्त क्लाइंट को खुशी से जुड़ने देती है। चार पंक्तियों की जाँच-सूची बिना किसी पंक्ति वाली धारणा से बेहतर है।