PKCS12, PEM या DER: VPN क्लाइंट को वास्तव में क्या चाहिए
पैकेजिंग तय करती है कि आपका क्लाइंट पहचान आयात करेगा या नहीं, यह नहीं कि वह भरोसेमंद है। PKCS12, PEM और DER की तुलना करें, फिर सत्यापित करें।
प्रमाणपत्र चर्चाओं में दो दावे घूमते हैं। पहला यह कि .p12 मज़बूत विकल्प है और .pem ढीला; दूसरा यह कि टेक्स्ट फ़ाइल भेजना सुरक्षित होना चाहिए क्योंकि आप उसे पढ़ सकते हैं। दोनों में से कोई एक मिनट की जाँच भी नहीं झेलता।
PKCS12, PEM और DER बताते हैं कि प्रमाणपत्र ऑब्जेक्ट कैसे पैक और एन्कोड होते हैं। वे यह तय नहीं करते कि सामने वाला कौन है, जारीकर्ता पर भरोसा है या नहीं, या फ़ाइल को पासवर्ड चाहिए या नहीं।
क्लाइंट क्या स्वीकार करता है, यह संगतता का प्रश्न है। फ़ाइल में क्या है, यह पहचान का प्रश्न है। इन दोनों को अलग रखें और ज़्यादातर आयात त्रुटियाँ रहस्यमय होना बंद कर देंगी।
तीन कंटेनर, एक ऑब्जेक्ट मॉडल
जो वास्तव में आपके पास है, उससे शुरू करें। प्रमाणपत्र किसी सार्वजनिक कुंजी के बारे में हस्ताक्षरित कथन है। निजी कुंजी अलग सामग्री है जो सिद्ध करती है कि आप उस कुंजी को नियंत्रित करते हैं। श्रृंखला उन जारीकर्ताओं का समूह है जो आपके प्रमाणपत्र को उस रूट से जोड़ते हैं जिस पर क्लाइंट भरोसा करता है। तीनों पैकेजिंग से स्वतंत्र रूप से मौजूद हैं।
PKCS12 फ़ाइल, आमतौर पर .p12 या .pfx, RFC 7292 में परिभाषित कंटेनर है जो निजी कुंजी, एक या अधिक प्रमाणपत्र और श्रृंखला को एक ही पासवर्ड-सुरक्षित ब्लॉक में ले जा सकता है, साथ में पहचान का नाम बताने वाला उपनाम। PEM फ़ाइल RFC 7468 में परिभाषित टेक्स्ट फ़्रेमिंग है: BEGIN और END पंक्तियों के बीच base64 बॉडी, और एक फ़ाइल में क्रम से कई ब्लॉक हो सकते हैं। DER उन्हीं ASN.1 संरचनाओं का बाइनरी एन्कोडिंग है, और PEM बॉडी शब्दशः base64 में लिपटा DER है।
वह अंतिम वाक्य याद रखने योग्य है। PEM को DER में बदलना फ़्रेमिंग को फिर से लिखता है, सामग्री को नहीं, और वापस बदलने पर मूल बाइट मिलते हैं।
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
एन्कोडिंग एन्क्रिप्शन नहीं है
base64 परिवहन की वर्णमाला है। यह कुछ छिपाती नहीं, और कोई भी शेल में PEM ब्लॉक डिकोड कर सकता है। DER फ़ाइल बाइनरी और उतनी ही सार्वजनिक है। दोनों में से कोई गुण सुरक्षा नहीं है, और कोई भी पासवर्ड होने का संकेत नहीं देता।
असली सुरक्षा कुंजी सामग्री में है। PKCS12 बंडल अपनी सामग्री को पासवर्ड से व्युत्पन्न कुंजी के अंतर्गत एन्क्रिप्ट कर सकता है। PEM निजी कुंजी को पुराने हेडर ब्लॉक से एन्क्रिप्ट किया जा सकता है या PKCS#8 EncryptedPrivateKeyInfo में रखा जा सकता है। प्रमाणपत्र अकेला कोई गोपनीयता नहीं रखता, इसलिए जो निर्यात केवल प्रमाणपत्र देता है, वह क्लाइंट को प्रमाणीकरण करने में असमर्थ छोड़ देता है, चाहे आप उसे किसी भी रूप में लपेटें।
एक्सटेंशन संकेत है, अनुबंध नहीं। .cer और .crt पर ख़त्म होने वाली फ़ाइलें दोनों एन्कोडिंग में दिखती हैं, और उपकरण DER प्रमाणपत्र .pem नामों से इतने अधिक निर्यात करते हैं कि प्रत्यय से अंदाज़ा लगाना एक दोपहर बर्बाद करता है। इसके बजाय पहले बाइट पढ़ें: PEM फ़ाइल BEGIN पंक्ति से खुलती है, जबकि DER 0x30 से शुरू होती है क्योंकि बाहरी संरचना SEQUENCE है।
आयात असल में क्यों विफल होता है
क्लाइंट के त्रुटि संदेश कई अलग समस्याओं को अमान्य प्रमाणपत्र के बारे में एक वाक्य में दबा देते हैं, इसलिए उन्हें कारण के अनुसार अलग करें। सबसे आम एन्कोडिंग बेमेल है: PEM पार्स करने वाला क्लाइंट DER फ़ाइल पर पार्स त्रुटि देता है, और समाधान नया प्रमाणपत्र नहीं, रूपांतरण है। दूसरा गुम कुंजी है, जहाँ प्रमाणपत्र ठीक है और पहचान सिद्ध नहीं हो सकती। तीसरा श्रृंखला है, जहाँ बिना मध्यवर्ती प्रमाणपत्र वाला बंडल आयात संवाद में सही दिखता है और हैंडशेक के दौरान विफल होता है।
एन्क्रिप्शन पैरामीटर चौथी वजह हैं, और वह बिल्कुल गलत पासवर्ड जैसी दिखती है। पुराने उपकरण PKCS12 फ़ाइलें RC2-40 और 3DES के साथ निर्यात करते थे, जिन्हें OpenSSL 3 अस्वीकार करता है जब तक legacy प्रदाता लोड न हो। उपकरण से AES-256-CBC और PBKDF2 के साथ फिर से निर्यात टिकाऊ समाधान है। एक फ़ाइल के लिए क्लाइंट मशीन पर पुराने सिफ़र हमेशा चालू रखना खराब सौदा है।
पाँचवाँ अस्पष्टता है। दो कुंजियों और दो प्रमाणपत्रों वाला कंटेनर, या तीन CERTIFICATE ब्लॉक वाली PEM फ़ाइल, क्लाइंट को चुनने पर मजबूर करती है, और उसका चुनाव अक्सर बस पहला आइटम होता है। जब टनल गलत पहचान के साथ उठती है, तो आमतौर पर यही कारण होता है।
रूपांतरण से पहले निरीक्षण करें
रहस्य छापे बिना संरचना पढ़ें। openssl pkcs12 -in bundle.p12 -info -noout एन्क्रिप्शन एल्गोरिदम और उपनाम बताता है और कुंजी तथा प्रमाणपत्र का आउटपुट दबा देता है, और openssl-pkcs12 मैनुअल फ़्लैग का दस्तावेज़ीकरण करता है। -noout हटाना और -nodes जोड़ना उन फ़ाइलों के लिए है जिन्हें आप रखना चाहते हैं, झटपट नज़र के लिए नहीं, क्योंकि यह निजी कुंजी खुले में लिखता है।
प्रमाणपत्र के लिए, openssl x509 -in cert.pem -noout -subject -issuer -dates वह उत्तर देता है जो आयात संवाद नहीं देगा, और -ext subjectAltName जोड़ने पर वे नाम दिखते हैं जिनके लिए प्रमाणपत्र वास्तव में वैध है। यदि फ़ाइल DER है, तो -inform DER जोड़ें; वह अकेला फ़्लैग ज़्यादातर unable-to-load त्रुटियाँ हल करता है।
कुंजी को प्रमाणपत्र से मिलाना यांत्रिक है, और किसी भी आयात से पहले करने योग्य है:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
समान डाइजेस्ट का अर्थ है कि जोड़ी एक साथ है। भिन्न डाइजेस्ट का अर्थ है कि आपके पास गलत कुंजी है, और कोई भी प्रारूप रूपांतरण इसे नहीं बदलेगा।
प्रारूप जो कभी नहीं बदलता
भरोसे के निर्णय कंटेनर के ऊपर होते हैं। क्लाइंट अपने स्टोर में रूट तक श्रृंखला चलाता है, वैधता विंडो जाँचता है, क्लाइंट प्रमाणीकरण के लिए विस्तारित कुंजी उपयोग जाँचता है, और सर्वर पक्ष पर जाँचता है कि जिस नाम पर उसने डायल किया वह प्रमाणपत्र में है। इनमें से कोई भी चरण फ़ाइल एक्सटेंशन नहीं पढ़ता।
इसीलिए त्रुटि गायब होने तक फ़ाइल का नाम बदलना समय बर्बाद करने का इतना भरोसेमंद तरीका है। आयात सफल होता है, पहचान फिर भी गलत रहती है, और विफलता हैंडशेक के दौरान फिर आती है जहाँ संदेश कम मददगार होता है। इसीलिए दो साल पहले निर्यात किया गया बंडल साफ़ आयात होता है और फिर भी अस्वीकार होता है: समाप्ति तिथि फ़ाइल नाम में नहीं, प्रमाणपत्र के भीतर सफ़र करती थी।
फिर से काम से बचने वाला क्रम
क्लाइंट के दस्तावेज़ से पूछें कि कौन-सी एन्कोडिंग स्वीकार करता है और क्लाइंट पहचान के लिए कौन-सा कंटेनर अपेक्षित है, फिर देखें कि आपको क्या दिया गया। यदि क्लाइंट एक आयातयोग्य पहचान चाहता है और आपके पास अलग PEM फ़ाइलें हैं, तो अपने नियंत्रण वाले पासवर्ड से एक बार बंडल बनाएँ और स्रोत रखें। यदि PEM चाहिए, तो कुंजी और श्रृंखला निकालें, और फिर मध्यवर्ती फ़ाइलें उस क्रेडेंशियल प्रक्रिया से हटाएँ जो आपकी टीम पहले से उपयोग करती है।
आयात के बाद संवाद नहीं, पहचान सत्यापित करें: विषय, जारीकर्ता, समाप्ति और वह नाम जो क्लाइंट प्रस्तुत करेगा। सूची में मधुर नाम एक लेबल है, सत्यापित पहचान नहीं। यदि फिर टनल विफल हो, तो आप पैकेजिंग के बजाय प्रमाणीकरण या रूटिंग डीबग कर रहे हैं, जो बहुत छोटी बातचीत है।