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

दोन्ही डायजेस्ट जुळले पाहिजेत. नंतर कनेक्ट करा आणि सर्व्हर नोंदवत असलेली ओळख तुम्ही अधिकृत केलेली आहे याची पुष्टी करा, फक्त बोगदा वर आला इतकेच नाही. की हरवली किंवा उपकरण बदलले तर उत्तर आहे रद्द करणे आणि नव्या उपकरणाकडून नवीन विनंती; प्रशासकाला दुसऱ्या ठिकाणाहून की परत पाठवण्यास सांगणे मूळ परत आणत नाही आणि विनंती सुरक्षित करणारे मॉडेल गुपचूप तोडते.