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

प्रमाणपत्र दो काम करता है जिन्हें आपस में मिला दिया जाता है

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

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

परिणामी सत्र की ताक़त कुंजी के आकार और सिफर सूट से आती है, हस्ताक्षरकर्ता से नहीं। इसीलिए स्व-हस्ताक्षरित प्रमाणपत्र को "कम एन्क्रिप्टेड" कहना बस ग़लत है; यह कम व्यापक रूप से प्रत्याभूत है, जो एक अलग गुण है।

सार्वजनिक CA अपना शुल्क कहाँ कमाता है

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

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

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

निजी CA VPN में कहाँ फ़िट होता है

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

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

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

CA की निजी कुंजी तय करती है कि बाद में आप क्या कर सकते हैं

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

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

पूरी टीम के लिए एक साझा क्लाइंट प्रमाणपत्र के बजाय हर डिवाइस के लिए एक प्रमाणपत्र जारी करें। तब खोया लैपटॉप आपको सभी के लिए पुनः जारी करने के बजाय एक ही निरस्तीकरण का ख़र्च देता है।

जाँचें कि आपको विरासत में क्या मिला

कोई भी बदलाव योजना बनाने से पहले, वह प्रमाणपत्र पढ़ें जो आपके पास पहले से है:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

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

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

संबंधित लेख