सवाल एसएसएल के संबंध में प्रमाणपत्र और कुंजी के बीच क्या अंतर है?


जब भी मैं एसएसएल के बारे में कुछ भी समझने की कोशिश करता हूं, मुझे हमेशा "कुंजी" और "प्रमाण पत्र" का संदर्भ रखने में कठिनाई होती है। मुझे डर है कि बहुत से लोग गलत तरीके से या एक दूसरे के रूप में उनका इस्तेमाल करते हैं। क्या कुंजी और प्रमाण पत्र के बीच कोई मानक अंतर है?


88
2017-07-15 17:55


मूल


एसएसएल के लिए इस्तेमाल किए जाने वाले कर्ट पीकेआई पर आधारित हैं en.wikipedia.org/wiki/Public-key_cryptography - Zoredache


जवाब:


एक प्रमाणपत्र में एक सार्वजनिक कुंजी होती है।

प्रमाणपत्र, सार्वजनिक कुंजी को जोड़ने के अलावा, अतिरिक्त जानकारी जैसे जारीकर्ता, प्रमाण पत्र का उपयोग किया जाना चाहिए, और अन्य प्रकार के मेटाडेटा शामिल हैं।

आम तौर पर, एक प्रमाण पत्र स्वयं एक निजी कुंजी के साथ हस्ताक्षरित होता है जो इसकी प्रामाणिकता को सत्यापित करता है।


80
2017-07-15 18:01



एक प्रमाण पत्र एक कुंजी का सार्वजनिक घटक है, न कि संपूर्ण कुंजी। - Zoredache
मैंने सुधार किया। :) - LawrenceC
@Zoredache यदि किसी प्रमाणपत्र में आम तौर पर केवल सार्वजनिक कुंजी होती है, तो क्या एक अच्छा नाम है .p12 या .pfx फ़ाइलों को जिनमें प्रमाणपत्र और निजी कुंजी एक साथ होती हैं? - drs
यह अतिरिक्त जानकारी कहां दफन की जाती है? मैं कुछ प्रमाण पत्र देख रहा था और यह मेरे लिए सब कुछ है - CodyBugstein
आप जिस गड़बड़ी को देख रहे हैं वह बेस 64 एन्कोडिंग है। ऐसा संभवतः इसी तरह से किया गया है कि ईमेल संलग्नक उसमें परिवर्तित हो जाते हैं - मूल रूप से यह सुनिश्चित करने के लिए कि वे एएससीआईआई के लिए केवल आकस्मिक संशोधन के बिना और न्यूलाइन, ब्रैकेट इत्यादि जैसी चीजों के बारे में चिंता किए बिना प्रोटोकॉल और तंत्र के माध्यम से परिवहन कर सकते हैं। openssl आदेश इन्हें डीकोड और पार्स कर सकता है या आप इस तरह की ऑनलाइन उपयोगिता का उपयोग कर सकते हैं: lapo.it/asn1js - LawrenceC


इन दो चित्रों ने एक साथ मुझे सबकुछ समझाया:

स्रोत: linuxvoice

enter image description here

स्रोत: infosecinstitute

enter image description here


34
2018-04-05 11:16



प्रासंगिक xkcd - Blacksilver
अच्छा लगा। 1 स्पष्टीकरण: पहला चित्र मानक (1-तरफा) टीएलएस ऑथ है; दूसरा, पारस्परिक (2-रास्ता) लेखक। और पहले में 1 अतिरिक्त कॉल-आउट आगे की मदद करेगा कि ट्रस्ट वास्तव में कैसे स्थापित किया जाता है (सभी उस मित्रवत दिखने वाले चित्र में): क्लाइंट के सर्वर के सार्वजनिक कुंजी प्रमाण प्राप्त होने के बाद, ग्राहक सत्यापित करता है कि जिस सीए ने हस्ताक्षर किए सर्वर का प्रमाण ग्राहक की विश्वसनीय सीए की निजी सूची में निहित है (यह स्थापित करना कि अब यह उस सीए पर भी भरोसा करता है)। फिर, सर्वर को सत्र कुंजी भेजने के लिए सुरक्षित है, w / जो प्रत्येक अब एन्क्रिप्ट और बाद के संचार को डिक्रिप्ट कर सकता है। - user1172173


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

  • कंपनी ए को अपनी कुंजी जोड़ी के लिए प्रमाण पत्र प्राप्त करने के लिए प्रमाणन प्राधिकरण (सीए) को प्रमाण पत्र अनुरोध (सीआर) बनाना होगा।
  • कंपनी कुंजी की सार्वजनिक कुंजी, लेकिन निजी कुंजी नहीं, प्रमाणपत्र की अनुरोध के हिस्से के रूप में शामिल है।
  • सीए तब कंपनी ए की पहचान जानकारी का उपयोग यह निर्धारित करने के लिए करता है कि अनुरोध प्रमाण पत्र जारी करने के लिए सीए के मानदंडों को पूरा करता है या नहीं।
     यदि सीए अनुरोध को मंजूरी दे देता है, तो यह कंपनी ए को प्रमाण पत्र जारी करता है। संक्षेप में सीए कंपनी ए की सार्वजनिक कुंजी को (सीए) निजी कुंजी के साथ इंगित करता है, जो इसकी प्रामाणिकता को सत्यापित करता है।

इसलिए कंपनी ए की सार्वजनिक कुंजी को वैध सीए की निजी कुंजी के साथ हस्ताक्षरित किया जाता है जिसे कंपनी ए का प्रमाण पत्र कहा जाता है।


33
2017-12-16 06:40



क्या कंपनी ए कोई भी बिंदु (कंपनी ए) निजी कुंजी को अपने (कंपनी ए) प्रमाण पत्र के साथ जोड़ती है? - Tola Odejayi
नहीं। ए के लिए एक निजी कुंजी निजी है। - Mohsen Heydari
तो कंपनी ए की निजी कुंजी कहां उपयोग की जाती है? - sivann
औपचारिकताओं के बाद। कंपनी ए के पास अपनी वेबसाइट पर एक वैध SSL प्रमाणपत्र होगा। वेब साइट को संचारित करने वाला कोई भी आगंतुक (ब्राउज़र) अपने संदेश को एन्क्रिप्ट करने के लिए प्रमाणपत्र सार्वजनिक कुंजी का उपयोग करेगा। एसएसएल प्रमाण पत्र की निजी कुंजी रखने वाली कंपनी ए केवल एकमात्र है जो संदेश को डिक्रिप्ट कर सकता है। - Mohsen Heydari
मुझे लगता है कि कंपनी ए एक पुरुष है। - DimiDak


एक एसएसएल प्रमाणपत्र एक विश्वसनीय प्रमाणन प्राधिकरण से प्राप्त किया जाता है, जो वेबसाइट के सुरक्षित कनेक्शन के लिए वाउच करता है। एसएसएल प्रमाणपत्रों में आमतौर पर प्रमाणीकरण का लोगो होता है और कंप्यूटर पर भेजे जाने वाले डेटा को एन्क्रिप्ट और डिक्रिप्ट करने के लिए आवश्यक सार्वजनिक कुंजी भी होती है। एसएसएल कुंजी कार्य

कई एसएसएल चांबियाँ एक सत्र के दौरान उत्पन्न किया जा सकता है। उनका उपयोग कंप्यूटर से भेजी जाने वाली जानकारी को एन्क्रिप्ट और डिक्रिप्ट करने के लिए किया जाता है। चाबियों का उपयोग यह सत्यापित करने के लिए किया जाता है कि जानकारी को संशोधित या छेड़छाड़ नहीं किया गया है।

जीवन चक्र अंतर

सर्टिफिकेट एसएसएल कुंजी से अधिक समय तक चलते हैं। एसएसएल प्रमाण पत्र प्रमाणन प्राधिकरण से प्राप्त किए जाते हैं, जिन्हें नियमित रूप से बैंकों और व्यवसायों द्वारा नवीनीकृत किया जा सकता है। दूसरी ओर, एसएसएल कुंजी या सत्र कुंजी, सत्र के दौरान विशिष्ट रूप से जेनरेट की जाती हैं और सत्र समाप्त होने पर त्याग दिया जाता है।

यहां और पढ़ें


3
2017-07-15 18:02





मुझे एक उदाहरण के साथ समझाओ।

सामान्य कुंजी-जोड़ी आधारित पीकेआई में, निजी कुंजी और सार्वजनिक कुंजी होती है।

प्रमाणपत्र-आधारित प्रणाली में, निजी कुंजी और प्रमाणपत्र हैं। सर्टिफिकेट सार्वजनिक कुंजी की तुलना में अधिक जानकारी रखता है।

डेमो (आप एक प्रमाण पत्र और निजी कुंजी उत्पन्न कर सकते हैं): http://www.selfsignedcertificate.com/

आप निजी कुंजी फ़ाइल और प्रमाणपत्र फ़ाइल खोल सकते हैं, आप देखते हैं कि सर्टिफिकेट फ़ाइल में नीचे दिखाए गए अनुसार बहुत अधिक जानकारी है। enter image description here enter image description here

आप इस साइट से अपने जेनरेट किए गए प्रमाणपत्र (टेक्स्ट एडिटर द्वारा खोलना), और निजी कुंजी (टेक्स्ट एडिटर द्वारा खोलना) से मेल खा सकते हैं: https://www.sslshopper.com/certificate-key-matcher.html

यदि प्रमाणपत्र क्लाइंट की निजी कुंजी से मेल खाता है, तो ग्राहक निश्चित है कि वह प्रमाणपत्र ग्राहक द्वारा दिया जाता है या ग्राहक के विश्वसनीय एजेंट (सीए) द्वारा दिया जाता है।

हालांकि, केवल निजी कुंजी और प्रमाणपत्र-आधारित संचार में समस्याएं हैं

क्योंकि, कोई भी अपना स्वयं का प्रमाणपत्र और निजी कुंजी उत्पन्न कर सकता है, इसलिए एक सरल हैंडशेक सर्वर के बारे में कुछ भी साबित नहीं करता है, इसके अलावा सर्वर प्रमाण पत्र की सार्वजनिक कुंजी से मेल खाने वाली निजी कुंजी जानता है। इस समस्या को हल करने का एक तरीका क्लाइंट के पास है एक सेट एक या अधिक प्रमाणपत्रों पर यह विश्वास करता है। अगर प्रमाणपत्र सेट में नहीं है, तो सर्वर पर भरोसा नहीं किया जाना चाहिए

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

इन डाउनसाइड्स को संबोधित करने के लिए, सर्वर आमतौर पर प्रमाणपत्र प्राधिकरण (सीएएस) नामक जाने-माने जारीकर्ताओं के प्रमाणपत्रों के साथ कॉन्फ़िगर किए जाते हैं। वह होस्ट-प्लेटफ़ॉर्म (क्लाइंट) में आम तौर पर प्रसिद्ध सीए की एक सूची होती है जो इसे भरोसा करती है। एक सर्वर के समान, एक सीए में एक प्रमाण पत्र और एक निजी कुंजी है। किसी सर्वर के लिए प्रमाण पत्र जारी करते समय, CA अपनी निजी कुंजी का उपयोग कर सर्वर प्रमाणपत्र को इंगित करता है। क्लाइंट तब सत्यापित कर सकता है कि सर्वर के पास प्लेटफॉर्म को ज्ञात सीए द्वारा जारी प्रमाणपत्र है।

हालांकि, कुछ समस्याओं को हल करते समय, सीएएस का उपयोग करके दूसरा परिचय मिलता है। चूंकि सीए कई सर्वरों के लिए प्रमाण पत्र जारी करता है, इसलिए आपको यह सुनिश्चित करने के लिए अभी भी कुछ तरीका चाहिए कि आप जिस सर्वर से चाहते हैं उससे बात कर रहे हैं। इसे संबोधित करने के लिए, सीए द्वारा जारी प्रमाण पत्र सर्वर को या तो gmail.com या * .google.com जैसे होस्टों के वाइल्डकार्ड सेट जैसे विशिष्ट नाम के साथ पहचानता है।

निम्नलिखित उदाहरण इन अवधारणाओं को थोड़ा और ठोस बना देगा। कमांड लाइन से नीचे स्निपेट में, openssl टूल का s_client कमांड विकिपीडिया की सर्वर प्रमाणपत्र जानकारी को देखता है। यह पोर्ट 443 निर्दिष्ट करता है क्योंकि यह HTTPS के लिए डिफ़ॉल्ट है। आदेश openssl s_client के आउटपुट को openssl x509 पर भेजता है, जो X.50 9 मानक के अनुसार प्रमाणपत्रों के बारे में जानकारी स्वरूपित करता है। विशेष रूप से, आदेश विषय के लिए पूछता है, जिसमें सर्वर नाम की जानकारी होती है, और जारीकर्ता, जो CA को पहचानता है।

$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA

आप देख सकते हैं कि रैपिडएसएसएल सीए द्वारा * .wikipedia.org से मेल खाने वाले सर्वरों के लिए प्रमाण पत्र जारी किया गया था।

जैसा कि आप देख सकते हैं, सीए द्वारा सर्वर पर भेजे गए इस अतिरिक्त जानकारी के कारण, क्लाइंट आसानी से जान सकता है कि यह अपने सर्वर से संचार कर रहा है या नहीं।


2
2018-05-09 20:57





ठीक है, चलिए इसे तोड़ दें ताकि गैर तकनीकी लोग समझ सकें।

इसके बारे में इस तरह से सोचें। एक प्रमाणपत्र आपके बैंक में एक सुरक्षा जमा बॉक्स की तरह है। इसमें बहुत सारी महत्वपूर्ण चीजें हैं; आमतौर पर सामान जिसमें आपकी पहचान होती है। प्रमाणपत्र में एक सार्वजनिक कुंजी है और इसे खोलने के लिए एक निजी कुंजी की आवश्यकता है।

आपके सुरक्षा जमा बॉक्स में प्रमाण पत्र की तरह, दो खोलने के लिए भी दो चाबियाँ लगती हैं।
सुरक्षा जमा बॉक्स के साथ, बैंकर की कुंजी सार्वजनिक कुंजी की तरह होती है क्योंकि यह बैंक में रहती है और सार्वजनिक कुंजी प्रमाण पत्र के साथ रहती है। आपके पास निजी कुंजी है, जिसे "अपना प्रमाणपत्र प्राप्त करने" की आवश्यकता है और सुरक्षा जमा बॉक्स के उदाहरण में, सार्वजनिक कुंजी के अतिरिक्त आपकी निजी कुंजी की भी आवश्यकता है।

इससे पहले कि आप वास्तव में अपना सुरक्षा जमा बॉक्स खोल सकें, आपको पहले अपनी पहचान सत्यापित करनी होगी (जैसे प्रमाण पत्र अनुरोध); एक बार आपकी पहचान हो जाने के बाद, आप अपने सुरक्षा बॉक्स को खोलने के लिए सार्वजनिक कुंजी के साथ अपनी निजी कुंजी का उपयोग करें। यह आपके प्रमाण पत्र के अनुरोध की तरह थोड़ा सा है, और फिर प्रमाण पत्र प्राधिकरण से अपना प्रमाण पत्र प्राप्त कर रहा है (जब तक आपको पहचाना जा सके (भरोसेमंद) और आपके पास सही कुंजी हो)।


1
2018-05-12 01:49



<समुद्री डाकू ओफ द कैरिबियन> तो हम इस कुंजी के बाद जा रहे हैं! </ समुद्री डाकू ओफ द कैरिबियन> (पढ़ें: आप बिल्कुल कोई समझ नहीं ले रहे हैं ...) - Timo


ब्राउज़र और सर्वर संचार

हाथ मिलाना:

  • क्लाइंट समर्थित एन्क्रिप्शन के साथ एक यादृच्छिक संख्या भेजता है
  • सर्वर समर्थित एन्क्रिप्शन के साथ अपना प्रमाणपत्र भेजता है। और यादृच्छिक संख्या क्लाइंट को अपनी निजी कुंजी से एन्क्रिप्ट किया गया है और वापस भेज दिया गया है। प्रमाणपत्र में सार्वजनिक कुंजी है। सर्टिफिकेट जारीकर्ता या (सीए), समाप्ति आदि
  • ग्राहक सर्वर द्वारा प्रमाण पत्र प्रमाणित करता है।

सभी पीसी सीए की एक सूची के साथ आता है जिसे वे VeriSign या DigiCert की तरह भरोसा करते हैं। ये रूट सीए हैं। सभी रूट सीए स्वयं हस्ताक्षर किए गए हैं। समझ में। ऐसा लगता है कि अगर मैं सर्वर ए पर विश्वास करता हूं और सर्वर ए सर्वर बी जानता है तो सर्वर ए वोच कर सकता है कि यह सर्वर बी है जो वह कहता है। और जिस तरह से सर्वर ए वॉच सर्वर बी को सर्टिफिकेट प्रदान कर रहा है। यह प्रमाणपत्र वास्तव में हमारे मामले सर्वर ए में सीए की निजी कुंजी द्वारा गाया जाता है, जो सार्वजनिक हस्ताक्षर पहले से ही हमारे पीसी पर है जिसके साथ मैं प्रमाण पत्र की प्रामाणिकता को सत्यापित कर सकता हूं सर्वर बी

  • ग्राहक सार्वजनिक कुंजी (प्रमाणपत्र में प्राप्त) के साथ, पहले भेजे गए संदेश या यादृच्छिक संख्या को सत्यापित करता है।

  • अब ग्राहक जांच करता है कि प्रमाणपत्र ओसीएसपी अनुरोध भेजकर और सीआरएल डीबी में जांच कर वैध है या नहीं।

  • अब अगर सर्टिफिकेट को रद्द नहीं किया गया है तो एक सत्र कुंजी जोड़ी स्थापित की जाएगी जिसके साथ एक एन्क्रिप्शन सुरंग स्थापित की गई है, अब सभी ट्रैफिक एन्क्रिप्ट किए गए हैं।

इंटरमीडिएट सर्टिफिकेट्स द्वारा सभी सीएसआर अनुरोधों पर हस्ताक्षर किए जाते हैं, रूट सीए की रूट अखंडता को आरक्षित करने के लिए रूट सीए नहीं, ताकि वे समझौता नहीं कर सकें।


-2
2018-04-14 15:47



मैं समझता हूं कि यह सीधे सवाल का जवाब नहीं देता है लेकिन डाउनवॉटिंग के दौरान टिप्पणी करें। - Kid101