VPN क्लाइंट कुंजी कैसे बनाएं और हस्ताक्षर के लिए CSR कैसे जमा करें

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

चरण 1: कुंजी वहीं बनाएं जहाँ वह रहेगी

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

सॉफ़्टवेयर प्रवाह ऐसा दिखता है, कुंजी और अनुरोध एक ही सत्र में बनाए जाते हैं:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

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

चरण 2: पहचान अनुरोध में रखें, ईमेल में नहीं

अनुरोध बनने से पहले तय करें कि VPN वास्तव में किसका प्रमाणीकरण करता है, क्योंकि वह उत्तर CSR के भीतर आता है। OpenVPN पारंपरिक रूप से क्लाइंट पहचान को प्रमाणपत्र के सामान्य नाम से जोड़ता है, और strongSwan जैसे उपकरण पहचान स्ट्रिंग को विषय या विषय के वैकल्पिक नाम से मिलाते हैं। जो ईमेल कहता है कि मेरा नाम alice है वह प्रमाण नहीं है, और जिस अनुरोध का विषय वही कहता है वह केवल थोड़ा बेहतर है।

जब आपका सत्यापनकर्ता एक की जाँच करे तो विषय का वैकल्पिक नाम जोड़ें, क्योंकि आधुनिक मिलान अक्सर पुराने CN को अनदेखा करता है:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN को छोटा, स्थिर और लैपटॉप मॉडल के बजाय खाते से बंधा रखें। जिस नाम में उपयोगकर्ता के डिवाइस का क्रमांक हो वह पहले हार्डवेयर प्रतिस्थापन की प्रतीक्षा करती सहायता समस्या है।

चरण 3: हस्ताक्षर से पहले अनुरोध सत्यापित करें

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

यांत्रिक भाग एक आदेश है, और उसे विषय के साथ सत्यापन परिणाम प्रिंट करना चाहिए:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

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

चरण 4: अधिकृत करें, फिर स्पष्ट एक्सटेंशन के साथ हस्ताक्षर करें

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

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

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

दर्ज करें कि क्या जारी हुआ: क्रमांक, विषय, माँगी गई पहचान, स्वीकृत करने वाला व्यक्ति और समाप्ति। वही रिकॉर्ड है जिस पर बाद में निरसन निर्णय निर्भर करता है, और यदि नामांकन का निशान केवल मेलबॉक्स में रहता है तो उसे केवल प्रमाणपत्र से फिर से नहीं बनाया जा सकता।

चरण 5: इसे मेल खाती कुंजी के पास स्थापित करें और जोड़ी सिद्ध करें

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

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

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