के iPad लाई आफ्नै VPN क्लाइन्ट प्रमाणपत्र चाहिन्छ?
एउटा साझा क्लाइन्ट प्रमाणपत्रले प्रत्येक यन्त्रलाई एउटै रद्द गर्न सकिने पहिचानसँग जोड्छ। प्रत्येक यन्त्रको दर्ता थप व्यवस्थापन चरणको योग्य छ कि छैन निर्णय गर्नुहोस्।
नयाँ iPad टोलीमा सामेल हुन्छ, र सबैभन्दा छिटो बाटो भनेको विद्यमान क्लाइन्ट प्रमाणपत्र निर्यात गरी ट्याब्लेटमा स्थापना गर्नु हो। कसैले छाडे, यन्त्र हरायो वा कुन यन्त्र कहिले जोडियो भनी बताउने अडिट मागियो भनेसम्म यो काम गर्छ। निर्णय प्रमाणपत्र फाइलको बारेमा होइन, पहिचानको बारेमा हो: प्रत्येक यन्त्रलाई छुट्टै अधिकृत र रद्द गर्न सकिन्छ कि। लागत र व्यवस्थापन श्रमले उत्तर निर्धारण गर्छ, र दुवै देखिनेभन्दा साना छन्।
साझा जारीकर्ता, छुट्टाछुट्टै पहिचान
प्रत्येक यन्त्रले एउटै प्रमाणपत्र प्राधिकरणमाथि विश्वास गर्न र एउटै गेटवेमा जोडिन सक्छ, तर फरक क्लाइन्ट पहिचान राख्छ। जारीकर्ता विश्वासको आधार हो, जबकि पहिचान एउटा कुञ्जी-जोडी हो जसको विषय सर्भरले नीतिसँग जोड्छ। यी दुईलाई मिसाउनु नै साझा प्रमाणपत्रलाई हानिरहित देखाउने कुरा हो। कुन यन्त्रले सत्र खोल्यो भनी कसैले जान्नु नपरेसम्म मात्र यो हानिरहित रहन्छ।
जारीकर्ता साझा गर्दा कन्फिगरेसन काम बच्छ र प्रत्येक यन्त्रको जवाफदेहीमा केही फरक पर्दैन। पहिचान साझा गर्दा प्रत्येक यन्त्र एउटै रद्द गर्न सकिने इकाइमा सीमित हुन्छ: एउटा रद्द गर्दा सबै रद्द हुन्छन्, र प्रतिस्थापन अधिकृत गर्दा आजसम्म बनाइएको कुञ्जीको प्रत्येक प्रतिलिपि अधिकृत हुन्छ। यो साटासाट शुक्रबार दिउँसो छिटो हुने भएकाले फाइल प्रतिलिपि गर्नुको सट्टा स्पष्ट रूपमा गर्नु उपयुक्त हुन्छ।
जब दोस्रो प्रमाणपत्र धेरै महँगो पर्छ
प्रत्येक यन्त्रको दर्ताले एउटा चरण लिन्छ: व्यवस्थित पेलोड, SCEP अनुरोध वा एक-पटकको पासवर्डसहित निर्देशित आयात। क्रम संख्या र समाप्ति मिति ट्र्याक गर्न ठाउँ पनि चाहिन्छ, यो भाग धेरैजसो तैनाथीले पहिलो प्रमाणपत्र सकिनेसम्म बिर्सन्छन्। दुवै लागत एक-पटकको हो, र दर्ता प्रवाहले तिनलाई स्वचालित गरेपछि दुवै घट्छन्।
दुई ट्याब्लेट र एक प्रयोगकर्ता भएको परिवारका लागि लागत वास्तविक छ, जहाँ साझा पहिचान एक वाक्यमा अभिलेख गरिएको उचित निर्णय हो। तर प्रत्येक व्यक्ति वा प्रत्येक यन्त्रअनुसार पहुँच फिर्ता लिनुपर्ने सेवाका लागि यो उचित छैन, किनकि रद्दीकरणको कथा नै पासवर्डको सट्टा प्रमाणपत्र प्रयोग गर्ने सम्पूर्ण कारण हो। तैनाथीलाई आज कति यन्त्र छन् भन्नेले होइन, यन्त्र कति पटक हात बदल्छन् भन्नेले मूल्याङ्कन गर्नुहोस्।
यन्त्र दर्ता गर्नुहोस्, कुञ्जी प्रतिलिपि नगर्नुहोस्
आधुनिक प्लेटफर्महरूले निजी कुञ्जी सुरक्षित भण्डारमा राख्छन्, र केहीले तिनलाई डिजाइनअनुसार निर्यात-अयोग्य चिन्ह लगाउँछन्। यही गुणले सुरुदेखि नै प्रतिलिपि असम्भव बनाउँछ, र ल्यापटपबाट निर्यात गरिएको बन्डल कुनै पनि समर्थित तरिकाले ट्याब्लेटमा पुनः आयात गर्न नसकिनुको कारण पनि त्यही हो। तैपनि प्रयास गर्दा सफा रूपमा स्थापना हुने र त्यसपछि कहिल्यै प्रमाणीकरण नगर्ने प्रोफाइल बन्छ।
तैनाथीले पहिले नै समर्थन गर्ने दर्ता विधि प्रयोग गर्नुहोस्: व्यवस्थित पहिचान पेलोड, SCEP सेवा वा यन्त्रमा नयाँ कुञ्जी जारी गर्ने खाता-आधारित प्रवाह। हराएको पहिचान समाधान गर्न प्रमाणपत्र प्राधिकरणको निजी कुञ्जी वितरण गर्नु अर्को गल्ती हो, जसको प्रभाव दायरा निकै ठूलो हुन्छ। प्राधिकरणले प्रमाण-पत्र जारी गर्छ र कहिल्यै अन्तिम बिन्दुसम्म यात्रा गर्नु हुँदैन।
जवाफ दिनुअघि रद्दीकरण जाँच्नुहोस्
साझा विकल्प छनोट गर्नुअघि सबैभन्दा खराब दिनमा रद्दीकरण कस्तो देखिन्छ वर्णन गर्नुहोस्। यदि जवाफ धेरै यन्त्रमा असर पार्ने एउटै कार्य हो भने, डिजाइनले पहिले नै तपाईंविरुद्ध निर्णय गरिसकेको छ।
openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem
तपाईंसँग वास्तवमा भएको सामग्री जाँच्नुहोस्: निजी कुञ्जी छ कि छैन, विषयले के भन्छ र क्रम संख्या छुट्टै रद्द गर्न सकिन्छ कि। कुञ्जी नभएको प्रमाणपत्र फाइलले केही पनि प्रमाणित गर्न सक्दैन, र त्यसैले केही प्रतिलिपि गरिएका पहिचान पहिलो जडानमै असफल हुन्छन्।
ट्याब्लेटबाट एप हटाउनु रद्दीकरण होइन, र कसैले निष्क्रिय नगरेसम्म सर्भरले पहिचान स्वीकार गरिरहन्छ। पहिलो यन्त्र दर्ता गर्नुअघि त्यो वाक्य रनबुकमा लेख्नुहोस्।