VPN क्लाइन्ट कुञ्जी कसरी बनाउने र हस्ताक्षरका लागि CSR कसरी बुझाउने

निजी कुञ्जी क्लाइन्टमै राख्नुहोस् र अनुरोध मात्र पठाउनुहोस्। 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

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

सम्बन्धित लेखहरू