VPN सर्टिफ़िकेट की कॉपी करने से कुंजी की कॉपी नहीं होती

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

दो क्लिक, दो बिल्कुल अलग कलाकृतियाँ।

फ़ाइल एक्सटेंशन नहीं, निर्यात संवाद पढ़ें

DER या PEM सर्टिफ़िकेट निर्यात में एक सार्वजनिक कुंजी और हस्ताक्षरित पहचान दावे रहते हैं, जो सर्वर को आप पर भरोसा करने के लिए और क्लाइंट को सर्वर सत्यापित करने के लिए चाहिए। PKCS#12 बंडल एक कंटेनर है जो सर्टिफ़िकेट, उसकी श्रृंखला और उससे मेल खाती निजी कुंजी रख सकता है, पासवर्ड से सुरक्षित, हालाँकि इसे कुंजी के बिना भी बनाया जा सकता है।

PEM केवल एक टेक्स्ट एन्कोडिंग है, सामग्री के बारे में वादा नहीं। वही एक्सटेंशन एक अकेले सर्टिफ़िकेट या कई लेबल वाले ब्लॉकों वाली फ़ाइल का वर्णन कर सकता है, और निर्यात विकल्प तय करते हैं कि कौन-सा।

इसलिए उपयोगी प्रश्न कभी यह नहीं है कि आपको कौन-सा एक्सटेंशन मिला, बल्कि यह है कि फ़ाइल में कौन-से ब्लॉक हैं। कुंजी के बिना निर्यात किया गया बंडल भी बंडल ही रहता है। प्रारूप की लोकप्रियता नहीं, सामग्री जाँचें।

जाँचें कि आपको वास्तव में क्या मिला

कुछ भी आयात करने से पहले लेबल खोजें, फिर सर्टिफ़िकेट के फ़ील्ड पढ़कर पुष्टि करें कि आपके पास कौन-सी पहचान है। जाँच उसी फ़ाइल पर चलाएँ जो वास्तव में आयात होगी। किसी भी पुनः निर्यात के बाद उन्हें दोहराएँ, क्योंकि विकल्प अलग हो सकते हैं।

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

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

निजी कुंजी वाली फ़ाइल कभी सहायता थ्रेड, इश्यू ट्रैकर या चैट में न चिपकाएँ, तब भी जब वह उस सर्टिफ़िकेट जैसी दिखे जिसे आप पहले साझा कर रहे थे। कुंजी पैनल के स्क्रीनशॉट भी उतनी ही सावधानी चाहते हैं।

कुंजी ऐसी जगह रह सकती है जहाँ से आप कॉपी नहीं कर सकते

प्रबंधित डिवाइसों पर निजी कुंजी ऑपरेटिंग सिस्टम के कीचेन, हार्डवेयर टोकन या सुरक्षित एन्क्लेव में रह सकती है, और कोई नीति उसे अ-निर्यात्य चिह्नित करती है। तब सर्टिफ़िकेट प्रबंधक सार्वजनिक वस्तु दिखाता है जबकि रहस्य अपनी जगह रहता है, और कोई निर्यात आदेश पोर्टेबल कॉपी नहीं बनाएगा। मोबाइल डिवाइस प्रबंधन से नामांकन अक्सर डिज़ाइन से ही इसी तरह काम करता है।

यह एक नियंत्रण है, टालने योग्य बाधा नहीं। सार्वजनिक सर्टिफ़िकेट से निजी कुंजी फिर से बनाना संभव नहीं है, और ऐसा दावा करने वाला कोई भी उपकरण कुछ और कर रहा है।

कॉपी करने के बजाय नई पहचान नामांकित करें

समर्थित रास्ता आम तौर पर यह है कि नए डिवाइस के लिए अलग पहचान नामांकित करें और पुरानी को सेवानिवृत्त होने पर निरस्त करें, ताकि हर डिवाइस को स्वतंत्र रूप से वापस लिया जा सके। जहाँ कुंजी के साथ निर्यात वास्तव में स्वीकृत है, वहाँ परिणामी फ़ाइल और उसके पासवर्ड को क्रेडेंशियल मानें: आराम की स्थिति में एन्क्रिप्टेड, विश्वसनीय चैनल से स्थानांतरित, और नामांकन पूरा होने पर हटाए गए।

आयात की गई पहचान से प्रमाणीकरण करके सत्यापित करें, आयात की सफलता देखकर नहीं। जो क्लाइंट अपने स्टोर में सार्वजनिक सर्टिफ़िकेट स्वीकार करता है, उसने कुंजी के बारे में कुछ साबित नहीं किया।

यह पुष्टि करके समाप्त करें कि सर्वर नई पहचान स्वीकार करता है और पुरानी अब भी नीति के अनुसार व्यवहार करती है। इस तरह यात्रा साक्ष्य के साथ पूरी होती है, सही दिखने वाली फ़ाइल से नहीं।