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