P12 मधून खाजगी कीशिवाय प्रमाणपत्रे निर्यात करा

सहाय्य तिकीट विचारते की VPN बंडलमध्ये कोणते प्रमाणपत्र आहे, आणि पहिली प्रवृत्ती सर्व काही निर्यात करून जोडण्याची असते. P12 फाइल प्रमाणपत्रे आणि खाजगी कीची सामग्री एकाच कंटेनरमध्ये पॅक करते, म्हणून सर्व काही निर्यात करणे म्हणजे तंतोतंत जे तुम्ही पाठवू नये. प्रश्नाचे उत्तर देणारा आदेश निवडीची समस्या आहे, रूपांतरणाची नाही. चार फ्लॅग ठरवतात की कंटेनरचा कोणता अर्धा भाग तुम्हाला मिळेल, आणि त्यापैकी दोन प्रत्यक्षात असल्यापेक्षा अधिक सुरक्षित वाटतात.

कंटेनर रिकामा करण्याऐवजी वाचण्यापासून सुरुवात करा.

PKCS12 फाइल प्रत्यक्षात काय ठेवते

PKCS12 कंटेनरमध्ये एक किंवा अधिक प्रमाणपत्रे, कदाचित खाजगी की, आणि सामग्रीवर message authentication code असतो. प्रमाणपत्रांमध्ये तुमच्या क्लायंट ओळखीचे लीफ प्रमाणपत्र आणि ते CA शी जोडणारी मध्यस्थ प्रमाणपत्रे असू शकतात. की, जेव्हा असते, तीच फाइलला दस्तऐवजाऐवजी रहस्य बनवते.

हाच फरक -nokeys असण्याचे आणि हेच ते फ्लॅग असण्याचे कारण आहे ज्याची या कामाला गरज आहे.

की न लिहिता बंडल वाचा

तपासणीचा प्रकार रचना आणि अल्गोरिदमचे तपशील छापतो आणि काहीही लिहीत नाही: openssl pkcs12 -in client.p12 -info -noout. तो आयात पासवर्ड मागतो, जो त्या मूल्यासाठी योग्य जागा आहे, आणि फाइलमध्ये की आहे की नाही हे सांगतो. पासवर्ड टाइप करता येत नसेल तेव्हा -passin env:PKCS12_PASS वापरा, कारण shell आदेशातील पासवर्ड प्रक्रिया सूचीतील पासवर्ड असतो. हे पाऊल काहीही निर्यात करत नाही, आणि हाच संपूर्ण मुद्दा आहे.

आउटपुट तीन गोष्टींसाठी वाचा: किती प्रमाणपत्रे, की आहे की नाही, आणि कोणते अल्गोरिदम त्याचे रक्षण करतात.

-nokeys वापरा आणि ते -nocerts सोबत मिसळू नका

-nokeys खाजगी की वगळतो आणि प्रमाणपत्रे ठेवतो. -clcerts ते क्लायंट प्रमाणपत्रांपर्यंत मर्यादित करतो, -cacerts ते CA प्रमाणपत्रांपर्यंत मर्यादित करतो, आणि हे दोन फिल्टर आहेत, पर्याय नाहीत. -nocerts त्याच कल्पनेचे सुरक्षित स्पेलिंगसारखे वाचले जाते आणि उलट अर्थ देतो: प्रमाणपत्रे नाहीत, जे फक्त की ठेवते. ते प्रमाणपत्र निर्यातीत मिसळणे म्हणजे खाजगी की डिस्कवर पोहोचण्याचा मार्ग.

प्रमाणपत्र फाइल आणि CA फाइल बनवणारा, आणि दुसरे काहीही नाही, दोन ओळींचा प्रकार असा आहे:

openssl pkcs12 -in client.p12 -nokeys -clcerts -out client-certificates.pem
openssl pkcs12 -in client.p12 -nokeys -cacerts -out ca-certificates.pem

जुन्या बंडलांना OpenSSL 3 वर -legacy लागतो जेणेकरून ते त्यांचे जुने एन्क्रिप्शन वाचू शकतील, आणि हा फ्लॅग parser काय स्वीकारतो ते बदलतो, तो काय उत्सर्जित करतो ते नाही. विश्लेषण असमर्थित अल्गोरिदमच्या त्रुटीने अयशस्वी झाल्यास, -legacy जोडणे योग्य पहिले पाऊल आहे आणि MAC तपासणी वगळणे नाही.

आउटपुट तपासा, निर्गम कोड नाही

शून्य निर्गम स्थिती सांगते की आदेश चालला, हे नाही की फाइलमध्ये तुमच्या अपेक्षेप्रमाणे आहे. आउटपुटमधील प्रमाणपत्रे मोजा आणि subject आणि तारखा वाचा: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint. फिंगरप्रिंटची तुलना सहाय्य संघ ज्याची अपेक्षा करतो त्याच्याशी करा, कारण दोन क्लायंट प्रमाणपत्रे असलेला बंडल दोन ब्लॉकची फाइल बनवतो आणि बहुतेक साधने फक्त पहिला वाचतात. उद्देश, विश्वास आणि की जुळणी पुन्हा स्वतंत्र चाचण्या आहेत.

जे प्रमाणपत्र पार्स होऊ शकते ते प्रमाणपत्र पार्स होऊ शकते. ते असे प्रमाणपत्र नाही जे VPN स्वीकारते.

तुम्हाला फाइलींची गरज आहे का हे ठरवा

जर प्राप्त करणारा क्लायंट PKCS12 थेट आयात करत असेल, तर मूळ बंडल मंजूर चॅनेलमधून पाठवणे आणि पासवर्ड वेगळा ठेवणे सोपे आहे आणि संरक्षण टिकवते. उत्कर्ष तपासणीसाठी, PEM आवश्यक असलेल्या क्लायंटसाठी, किंवा विशिष्ट आर्टिफॅक्ट मागणाऱ्या सहाय्य प्रकरणासाठी आहे. प्रत्येक उत्कर्ष एक थर काढतो आणि त्याला कारण असले पाहिजे.

सार्वजनिक प्रमाणपत्रांमध्ये खाजगी की नसते, पण त्यात नावे आणि संस्थेचे तपशील असतात. फाइलऐवजी तिकिटाने मागितलेली फील्ड शेअर करा, जोपर्यंत फाइलच मागितली गेली नाही.