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 लेगसी प्रदाता लोड केल्याशिवाय नाकारते। उपकरणातून 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 हवे असेल, तर की आणि साखळी काढा, आणि नंतर मध्यस्थ फाइल्स तुमचा संघ आधीच वापरत असलेल्या क्रेडेन्शियल हाताळणी प्रक्रियेद्वारे काढून टाका।
आयातीनंतर संवाद नाही, ओळख तपासा: विषय, जारीकर्ता, कालबाह्यता आणि क्लायंट सादर करणारे नाव। यादीतील मैत्रीपूर्ण नाव हे लेबल आहे, तपासलेली ओळख नाही। नंतर टनेल अयशस्वी झाल्यास, तुम्ही पॅकिंगऐवजी प्रमाणीकरण किंवा राउटिंग डीबग करत आहात, जे खूप लहान संभाषण आहे।