CA को दोबारा बनाए बिना VPN क्लाइंट जोड़ना

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

दोबारा निर्माण वास्तव में क्या नष्ट करता है

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

सबसे शांत नुकसान बहीखाता है। निरसन इस पर निर्भर है कि आप जानें कौन से क्रमिक नंबर किसे जारी किए. सूची मिटा दें तो अब भी हस्ताक्षर कर सकते हैं, पर यह निश्चित रूप से नहीं कह सकते कि कौन से जारी प्रमाणपत्र रद्द करने थे। जारीकर्ता की स्थिति के बिना प्रमाणपत्र रखने वाली CA निर्देशिका ऐसा बैकअप है जो सिस्टम का गलत आधा हिस्सा बहाल करता है।

CA की निजी कुंजी को चल रहे सर्वर के पास कॉपी करना दूसरा ऐसा शॉर्टकट है जिसे ठुकराना चाहिए: यह ऑफ़लाइन रहने वाले हस्ताक्षर प्राधिकार को अविश्वसनीय ट्रैफ़िक वाले होस्ट पर एक और फ़ाइल बना देता है।

पहली शर्त: क्या जारीकर्ता की स्थिति अब भी उपलब्ध है?

तय करने से पहले वह निर्देशिका खोजें जिस पर सर्वर वास्तव में भरोसा करता है। सर्वर जिस प्रमाणपत्र को CA के रूप में प्रस्तुत करता है, उसकी तुलना PKI निर्देशिका वाले से फ़िंगरप्रिंट से करें, फ़ाइल नाम से नहीं:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

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

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

दूसरी शर्त: नई निजी कुंजी किसके पास है?

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

मौजूदा CA के सामने Easy-RSA 3 के साथ अनुरोध आयात करना और हस्ताक्षर करना दो आदेश हैं:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

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

तीसरी शर्त: क्या सर्वर को प्रमाणपत्र से अधिक चाहिए?

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

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

वृद्धिशील प्रक्रिया और कब दोबारा निर्माण सही है

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

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

उद्देश्य पंक्ति में SSL client दिखना चाहिए। जारीकरण के बाद CA बैकअप अद्यतन करके समाप्त करें, क्योंकि नए क्रमिक नंबर के दर्ज होने से पहले लिया गया बैकअप उस डिवाइस के बिना स्थिति बहाल करता है जो आपने अभी जोड़ा है।

दोबारा निर्माण तीन स्थितियों में सही है: CA कुंजी से समझौता हुआ हो, जारीकरण स्थिति अपूरणीय रूप से खो गई हो, या आप जानबूझकर कुंजी एल्गोरिद्म या प्रमाणपत्र नीति बदल रहे हों। तीनों ऐसी परियोजनाएँ हैं जिनमें हर क्लाइंट के लिए पुनः पंजीकरण योजना चाहिए, एक डिवाइस के अनुरोध के चरण नहीं। कोई भी लागू न हो तो वृद्धिशील पंजीकरण करें।