क्या 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

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

टैबलेट से ऐप हटाना रद्दीकरण नहीं है, और सर्वर तब तक पहचान स्वीकार करता रहता है जब तक कोई उसे निष्क्रिय न कर दे। पहला डिवाइस नामांकित करने से पहले यह वाक्य रनबुक में लिखें।