.cer और pfx फ़ाइल के बीच क्या अंतर है [बंद]

Question

लोग कहते थे -

cer - प्रमाणपत्र X.509 मानक प्रारूप में संग्रहीत। इस प्रमाण पत्र में सार्वजनिक और निजी कुंजी के साथ प्रमाणपत्र के मालिक के बारे में जानकारी शामिल है।

pfx - व्यक्तिगत विनिमय प्रारूप के लिए खड़ा है। यह एक फाइल में सार्वजनिक और निजी वस्तुओं का आदान-प्रदान करने के लिए उपयोग किया जाता है। Pfx फ़ाइल .cer फ़ाइल से बनाई जा सकती है। सॉफ्टवेयर प्रकाशक प्रमाणपत्र बनाने के लिए भी इस्तेमाल किया जा सकता है।

** इस लिंक से रेफरी मिला , एक सेर, pvk और pfx फ़ाइल में क्या अंतर है? **

लेकिन कोई नहीं कह रहा है कि हमें CERT फाइल का उपयोग कब करना चाहिए और कब हमें PFX फाइल का उपयोग करना चाहिए। यदि संभव हो तो कृपया उस स्थिति पर चर्चा करें जब हमें CERT फ़ाइल के लिए जाना चाहिए और जब हमें PFX फ़ाइल के लिए जाना चाहिए। धन्यवाद।

Comments

इसके अलावा [१] , [२] , [३]

— पेसियर

stackoverflow.com/a/45886431/1599699

— एंड्रयू

Answer 1

.Pfx में संबंधित प्रमाण पत्र के लिए सार्वजनिक और निजी कुंजी दोनों शामिल हैं (अपने संगठन के बाहर इसे साझा न करें); इसका उपयोग वेब साइट पर टीएलएस / एसएसएल के लिए, डिजिटल रूप से हस्ताक्षरित संदेशों या प्राधिकरण टोकन पर हस्ताक्षर करने के लिए, या एक साथी प्रणाली को प्रमाणित करने के लिए किया जा सकता है। A .cer फ़ाइल में केवल सार्वजनिक कुंजी है (यह वह है जो आप आमतौर पर एकीकरण भागीदारों के साथ विनिमय करते हैं); इसका उपयोग टोकन या ग्राहक प्रमाणीकरण अनुरोधों को सत्यापित करने के लिए किया जा सकता है, और यह वही है जो एसएसएल हैंडसेट में एक सर्वर से एक HTTP क्लाइंट द्वारा प्राप्त किया जाता है।

Comments

प्रमाणित फ़ाइल के मामले में, जहाँ निजी कुंजी संग्रहीत है? मैंने ज्यादातर बार देखा कि लोग wcf के साथ प्रमाणित फ़ाइल का उपयोग करते हैं ... क्यों? वे pfx फ़ाइल क्यों नहीं चुनते? कौन सा सबसे सुरक्षित है?

— थॉमस

u एक महत्वपूर्ण बात याद आती है कि जब लोग सर्टिफिकेट फ़ाइल का उपयोग करते हैं और जब pfx फ़ाइल ... यह सबसे महत्वपूर्ण है। उत्तर के लिए धन्यवाद।

— थॉमस

प्रमाणित फ़ाइल X.509 प्रमाणपत्र के लिए एक सामान्य शब्द है। विंडोज की दुनिया में, pfx पासवर्ड प्रोटेक्टेड है और इसे कभी ऑर्गन नहीं छोड़ना चाहिए। सार्वजनिक कुंजी के रूप में X फ़ाइल को प्रमाणपत्र से निर्यात किया जा सकता है। यदि आप संदेश पर हस्ताक्षर करने या प्रमाणीकरण के लिए WCF क्लाइंट से X.509 सेरट्स का उपयोग कर रहे हैं, तो आपको pfx फ़ाइल को स्थापित करना होगा (या किसी फ़ोल्डर में उपलब्ध है)। मुझे @Thomas की क्या याद आई?

— पीटरबी

मेरे दूसरे सवाल का जवाब दो।

— थॉमस

@ थोमस क्या आप इसे दोहरा सकते हैं? आपकी पोस्ट में कोई प्रश्नचिह्न नहीं है, इसलिए यह बताना कठिन है कि क्या उत्तर नहीं दिया गया है। BTW, एक निजी फ़ाइल में एक निजी कुंजी शामिल नहीं है। ;)

— पीटरबी

Answer 2

2 x परिदृश्य जो थोड़ा अलग तरीके से काम करते हैं:

SCENARIO 1:
SSL का उपयोग करके HTTPS से अधिक वेब ब्राउज़र (क्लाइंट) वेब पेज (सर्वर) तक पहुंच।

सर्वर में .PFX फ़ाइल होती है जिसमें दोनों कीज़ होती हैं। क्लाइंट सर्वर पर एक वेबसाइट से जोड़ता है, और सर्वर एसएसएल हैंडशेक के हिस्से के रूप में क्लाइंट को अपनी सार्वजनिक-कुंजी (.CER फ़ाइल) की एक प्रति भेजता है। क्लाइंट तब एक "सत्र-कुंजी" उत्पन्न करता है और सर्वर से प्राप्त सार्वजनिक-कुंजी का उपयोग करके इसे एन्क्रिप्ट करता है। सत्र-कुंजी को सर्वर पर वापस भेजा जाता है और इसकी सत्यता की पुष्टि करने के लिए डिक्रिप्ट किया जाता है। यदि सफलतापूर्वक, क्लाइंट और सर्वर दोनों अब "सत्र-कुंजी" साझा करते हैं, तो सममित एन्क्रिप्शन (अर्थात क्लाइंट और सर्वर दोनों, अब दोनों को एन्क्रिप्ट करने के लिए संचार करते हैं) और एक ही सत्र-कुंजी का उपयोग करके एक दूसरे के बीच सभी संदेशों को एन्क्रिप्ट और डिक्रिप्ट करते हैं। यह सब किया जा रहा है। वेब ब्राउज़र की पृष्ठभूमि में पर्दे के पीछे किया जाता है, जब आप एड्रेस बार में URL दर्ज करते हैं, और वेब पेज दिखाई देता है।

SCENARIO 2:
एप्लिकेशन (क्लाइंट) SSH का उपयोग करते हुए एक FTP साइट (सर्वर)
या
रिमोट डेस्कटॉप (क्लाइंट से सर्वर) से जुड़ता है
(दोनों उदाहरण लागू होंगे)

इस परिदृश्य में, दोनों क्लाइंट और सर्वर होगा अपने निजी और सार्वजनिक कुंजी जोड़े होते हैं
(इस थ्रेड में उल्लिखित अन्य उदाहरण के विपरीत, यह है कि केवल समझाने जब एक सर्वर दोनों कुंजी है, और ग्राहक केवल सार्वजनिक कुंजी है)

अब, स्पष्टीकरण प्रयोजनों के लिए - कुछ जोड़े जैसे:
A1 और A2 को लेबल करें = सर्वर के रूप में सर्वर निजी और सार्वजनिक कुंजी क्रमशः
B1 और B2 = ग्राहक निजी और सार्वजनिक कुंजी के रूप में क्रमशः

इस मॉडल का उपयोग करते हुए, इस थ्रेड के पिछले पोस्ट्स के बारे में बात कर रहे थे जब सर्वर में A1 और A2 हैं ( .PFX फ़ाइल ) है, और केवल ग्राहकों के साथ A2 ( .CER ) की एक प्रति साझा करता है।

जबकि पूरे क्लाइंट-सर्वर कम्युनिकेशन में A1 , A2 , B1 और B2 कीज़ से मिलकर FTP, या SSH कनेक्शन (वहां अन्य उदाहरण हैं) । उदाहरण के लिए,
- क्लाइंट एफ़टीपी सर्वर से जुड़ता है।
- सर्वर अपनी सार्वजनिक कुंजी (A2) की प्रति क्लाइंट को भेजता है।
- क्लाइंट अपनी खुद की सार्वजनिक कुंजी (बी 2) सर्वर पर भेजता है, हैंडशेक को पूरा करता है।
- यह अब असममित एन्क्रिप्शन का उपयोग करेगा

सर्वर में अब A1 , ( स्वयं का निजी ), A2 ( अपना स्वयं का सार्वजनिक ), और B2 ( क्लाइंट का सार्वजनिक )
क्लाइंट की प्रतिलिपि अब B1 , ( अपना निजी ), B2 ( अपना स्वयं का सार्वजनिक ) और A1 की प्रतिलिपि है ( सर्वर का) सार्वजनिक )

क्लाइंट-टू-सर्वर कॉम्स:
क्लाइंट सर्वर के लिए बाध्य संदेशों को एन्क्रिप्ट करने के लिए A2 (सर्वर सार्वजनिक कुंजी) का उपयोग करता है, सर्वर A1 (सर्वर निजी कुंजी) का उपयोग करके उन्हें डिक्रिप्ट करता है

सर्वर-टू-क्लाइंट कॉम्स:
क्लाइंट के लिए बाध्य संदेश को एन्क्रिप्ट करने के लिए सर्वर बी 2 (क्लाइंट पब्लिक की) का उपयोग करता है, क्लाइंट बी 1 (क्लाइंट निजी कुंजी) का उपयोग करके उन्हें कम कर देता है।

.CER और .PFX फ़ाइल प्रकारों के बारे में, सर्वर बीमार की अपनी .PFX है जिसे आपके संगठन के बाहर वितरित नहीं किया जाना चाहिए, इसके बजाय, आपको .CER फ़ाइल को ग्राहकों को वितरित करना चाहिए।

और अधिक जानकारी यहां पाई जा सकती है:
https://www.digicert.com/ssl-cryptography.htm

और यहाँ:
/server/107433/why-does-a-ssh-public-key-sit-on-the-server-and-not-with-the-client

Answer 3

मेरे अनुभव में (यह उतना विशाल नहीं है जितना मैं चाहता हूं) मैं एक IIS सर्वर पर https बाइंडिंग को कॉन्फ़िगर करते समय एक pfx फ़ाइल का उपयोग करता हूं (क्योंकि इसमें सार्वजनिक और निजी कुंजी दोनों शामिल हैं, आप बस उस फ़ाइल के साथ ठीक हैं), एक सीर फ़ाइल मुख्य जोड़ी का अधिकांश हिस्सा है (ज्यादातर बार) और आपको इसे nkeyx या apache सर्वर पर ssl ट्रैफ़िक को कॉन्फ़िगर करते समय .key फ़ाइल के साथ संयोजन में उपयोग करने की आवश्यकता होती है।

जहां तक ​​मैं समझता हूं कि एक या दूसरे का उपयोग करने के लिए अधिक कठिन कारण नहीं हैं,

Answer 4

जैसा कि उल्लेख किया गया है, सवाल सेब और संतरे का एक सा है, क्योंकि सेर फ़ाइल सिर्फ सार्वजनिक कुंजी है लेकिन pfx फ़ाइल में सार्वजनिक और निजी दोनों कुंजियाँ हैं।

तो एक अधिक उचित प्रश्न यह होगा कि आप pfx फ़ाइल का उपयोग pem फ़ाइल के विपरीत कब करना चाहेंगे। यह देखते हुए कि pfx फ़ाइलों की अत्यधिक जटिल होने के लिए आलोचना की गई है, आपके दूसरे प्रश्न का एक उचित उत्तर हो सकता है: आप केवल कभी भी pfx फ़ाइल का उपयोग करना चाहेंगे यदि आप IIS चला रहे हैं और इसका कॉन्फ़िगरेशन बिल्कुल आपको किसी और चीज़ का उपयोग नहीं करने देगा ।

स्रोत: https://en.wikipedia.org/wiki/PKCS_12 (संदर्भित फुटनोट Gmanman का एक लेख है।)

Answer 5

एसएसएल अतुल्यकालिक एन्क्रिप्शन का उपयोग करता है, जिसका अर्थ है कि एक कुंजी (निजी कुंजी) सर्वर को दी जाती है जो कुंजी जोड़ी का "स्वामित्व" करती है, जबकि दूसरी कुंजी (सार्वजनिक कुंजी) स्वतंत्र रूप से वितरित की जाती है।
इसे अतुल्यकालिक कहा जाता है क्योंकि निजी कुंजी के साथ एन्क्रिप्ट किए गए डेटा को केवल सार्वजनिक कुंजी के साथ डिक्रिप्ट किया जा सकता है, जबकि सार्वजनिक कुंजी के साथ एन्क्रिप्ट किए गए डेटा को केवल निजी कुंजी के साथ डिक्रिप्ट किया जा सकता है। इसलिए यदि आप मालिक को सुरक्षित रूप से कुछ भेजना चाहते हैं, तो आप उसे उसकी निजी कुंजी के साथ एन्क्रिप्ट करते हैं और वह केवल वही होगा जो इसे डिक्रिप्ट कर सकता है। यदि मालिक साबित करना चाहता है कि उसने कुछ भेजा है, तो वह इसे निजी कुंजी के साथ एन्क्रिप्ट करता है और जिस किसी के पास सार्वजनिक कुंजी है वह इसे डिक्रिप्ट कर सकता है। (एक बार प्रमाणपत्र स्थापित हो जाने के बाद, यह आमतौर पर ब्राउज़र या ईमेल टूल द्वारा पर्दे के पीछे किया जाता है।)
चूंकि मालिक उस निजी कुंजी को निजी रखना चाहता है, यह पासवर्ड से सुरक्षित होगा और केवल स्वयं के सर्वर को दिया जाएगा (अक्सर एक PFX या P12 फ़ाइल में)। लेकिन सार्वजनिक कुंजी को स्वतंत्र रूप से वितरित किया जाएगा (अक्सर एक सीईआर फ़ाइल में)।

Comments

"आप इसे अपनी निजी कुंजी के साथ एन्क्रिप्ट करते हैं और वह केवल वही होगा जो इसे डिक्रिप्ट कर सकता है।" मुझे लगता है कि आपका मतलब है, आप इसे अपनी सार्वजनिक कुंजी के साथ एन्क्रिप्ट करते हैं।

— डेव सिम्स

मुझे लगता है कि आपका मतलब "असममित" है, न कि "एसिंक्रोनस"।

— नैट बारबेटिनी

आप आंशिक रूप से सही हैं - यह असममित और सममित एन्क्रिप्शन दोनों का उपयोग करता है। SSL क्लाइंट और सर्वर के बीच शुरू में असममित एन्क्रिप्शन का उपयोग करता है - लेकिन केवल इस बिंदु तक कि क्लाइंट विश्वास को सत्यापित कर सकता है और एक सममित कुंजी उत्पन्न कर सकता है, उस सर्वर को वापस भेज सकता है (असममित एन्क्रिप्शन का उपयोग करके), और फिर सभी वास्तविक डेटा होते हैं सममित एन्क्रिप्शन का उपयोग करना।

— हारून क्रूस