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 कुञ्जी भंग भएको, जारी अवस्था नफर्किने गरी हराएको, वा तपाईंले जानाजान कुञ्जी एल्गोरिदम वा प्रमाणपत्र नीति बदल्नुभएको। तीनवटै परियोजना हुन् जसलाई हरेक क्लाइन्टको पुनः दर्ता योजना चाहिन्छ, एउटा उपकरणको अनुरोधका चरणहरू होइनन्। कुनै लागू नभए थपिँदो रूपमा दर्ता गर्नुहोस्।