प्रमाणपत्र और कुंजी मैचर

प्रमाणपत्रों, निजी कुंजियों और CSR का कोई भी मिश्रण डालें — PEM या DER — और यह वर्कबेंच साबित करता है कि कौन-सी कुंजी किस प्रमाणपत्र से मेल खाती है, प्रमाणपत्रों को एक श्रृंखला में क्रमबद्ध करता है, प्रारूप बदलता है और CSR बनाता है। निजी कुंजियाँ आपके ब्राउज़र को कभी नहीं छोड़तीं: सब कुछ इस टैब में स्थानीय रूप से पार्स होता है, कुंजियाँ केवल स्मृति में रखी जाती हैं और कभी अपलोड, लॉग या संग्रहीत नहीं होतीं, और यह पेज कोई नेटवर्क अनुरोध नहीं करता। किसी एक प्रमाणपत्र को गहराई से डीकोड करने के लिए, SSL प्रमाणपत्र पार्सर का उपयोग करें; एक त्वरित स्व-हस्ताक्षरित प्रमाणपत्र के लिए, स्व-हस्ताक्षरित प्रमाणपत्र जनरेटर का उपयोग करें।

प्रमाणपत्र, कुंजियाँ और CSR जोड़ें

मिलान का निर्णय

एक प्रमाणपत्र और एक निजी कुंजी जोड़ें और निर्णय यहाँ दिखाई देगा: कौन-सी कुंजी किस प्रमाणपत्र से मेल खाती है, एक समान सार्वजनिक कुंजी से साबित — फ़ाइल नामों से कभी अनुमान नहीं लगाया जाता।

श्रृंखला निर्माता

दो या अधिक प्रमाणपत्र लोड होने पर, निर्माता उन्हें जारीकर्ता और विषय नामों का मिलान करके क्रमबद्ध करता है — पत्ता पहले, फिर मध्यवर्ती, फिर जड़ — और फिर, जहाँ ब्राउज़र की क्रिप्टोग्राफ़ी अनुमति देती है, नामों पर भरोसा करने के बजाय हर कड़ी पर वास्तविक हस्ताक्षर की जाँच करता है।

CSR बनाएँ

यहाँ, आपके ब्राउज़र में बनी एक कुंजी के लिए एक प्रमाणपत्र हस्ताक्षर अनुरोध: विषय भरें, कुंजी का प्रकार चुनें, और CSR डाउनलोड करके अपने CA को भेजें — साथ ही निजी कुंजी भी, जिसे आपको स्वयं सुरक्षित रखना होगा। कुंजी केवल यहाँ दिखाई जाती है; यह पेज उसे नहीं रखता।

मिलान वास्तव में कैसे काम करता है

एक प्रमाणपत्र और एक निजी कुंजी एक ही फ़ाइल के दो आधे हिस्से नहीं हैं; वे दो फ़ाइलें हैं जो एक ही गणितीय वस्तु को साझा करती हैं। जब एक कुंजी जोड़ी बनाई जाती है, तो सार्वजनिक आधा हिस्सा प्रमाणपत्र के अंदर (और उस कुंजी से बने किसी भी CSR के अंदर) रखा जाता है, जबकि निजी आधा हिस्सा कुंजी फ़ाइल में रहता है। दो आइटम ठीक तब मेल खाते हैं जब वे एक ही सार्वजनिक कुंजी रखते हैं — RSA के लिए, वही मापांक और घातांक; EC के लिए, उसी वक्र पर वही बिंदु। यह पेज उस सार्वजनिक कुंजी को उसके मानक आवरण (SubjectPublicKeyInfo) में एन्कोड करता है, एन्कोडिंग पर SHA-256 लागू करता है, और हर लोड किए गए आइटम को उस हैश के आधार पर समूहित करता है। इसलिए हर कार्ड पर दिखाया गया हैश सारांश नहीं, सबूत है: समान हैश संयोग से नहीं हो सकते, और बेमेल होना उतना ही निश्चित है, इसीलिए निर्णय स्पष्ट रूप से कहा जा सकता है — यह कुंजी इस प्रमाणपत्र से मेल खाती है, या कोई लोड की गई कुंजी नहीं खाती। यह जाँच जिस क्लासिक विफलता को पकड़ती है वह जब आपकी कुंजी आपके प्रमाणपत्र से मेल नहीं खाती में लिखी है: रात 2 बजे का रीलोड जहाँ डिस्क पर नवीनीकृत प्रमाणपत्र उस कुंजी से अलग कुंजी का था जो सर्वर ने लोड की थी।

फ़ाइल नाम कुछ भी साबित नहीं करते। server.crt, server.key, final-v2.pem और पिछले साल के नवीनीकरण प्रयास का एक CSR से भरी निर्देशिका विरासत में मिले बुनियादी ढाँचे की सामान्य स्थिति है, और नाम पुरातत्व हैं, दस्तावेज़ नहीं। मेल खाता फ़ाइल एक्सटेंशन या मेल खाती तारीख़ भी कुछ साबित नहीं करती। और पारंपरिक openssl जाँच — प्रमाणपत्र के मापांक हैश की तुलना कुंजी के मापांक हैश से करना? वह ठीक इस पेज की जाँच है, RSA तक सीमित और एक बार में एक जोड़ी तक, और वह EC कुंजियों को पूरी तरह चूक जाती है क्योंकि EC कुंजियों का कोई मापांक नहीं होता। सार्वजनिक कुंजी फ़िंगरप्रिंट हर एल्गोरिदम को समान रूप से कवर करता है, इसीलिए वह यहाँ समूहन कुंजी है।

श्रृंखलाएँ, क्रम, और "सत्यापित" का अर्थ

सर्वरों से अपेक्षा की जाती है कि वे पहले पत्ता प्रमाणपत्र प्रस्तुत करें, फिर हर मध्यवर्ती को क्रम से, ताकि एक क्लाइंट जारीकर्ता-से-विषय कड़ियों के साथ उस जड़ तक चल सके जिस पर वह पहले से भरोसा करता है। उन्हीं प्रमाणपत्रों को गलत क्रम में प्रस्तुत करना — या किसी मध्यवर्ती के गायब होने के साथ — उन क्लाइंटों में क्लासिक "unable to get local issuer certificate" त्रुटियों का परिवार पैदा करता है जो गायब कड़ी को स्वयं नहीं ला सकते। ऊपर का निर्माता केवल नामों से क्रम का पुनर्निर्माण करता है, जो हमेशा संभव है, और फिर एक कदम आगे जाता है: RSA और ECDSA हस्ताक्षरों के लिए वह जारीकर्ता की सार्वजनिक कुंजी आयात करता है और प्रमाणपत्र के हस्ताक्षरित बाइट्स पर हस्ताक्षर की जाँच करता है। हस्ताक्षर सत्यापित लेबल वाली कड़ी क्रिप्टोग्राफ़िक रूप से साबित है। केवल नाम मिलान लेबल वाली कड़ी नहीं है — नाम जुड़ते हैं, लेकिन हस्ताक्षर एक ऐसे एल्गोरिदम का उपयोग करता है जिसे यह मंच जाँचता नहीं (RSA-PSS सामान्य मामला है), और पेज यह कहता है बजाय इसके कि नाम मिलान को सबूत के भेष में पेश करे। यदि कोई हस्ताक्षर जाँच विफल हो जाती है, तो नाम संयोग या जालसाज़ी थे, और निर्माता चुपचाप बंडल बनाने के बजाय विफलता को लाल रंग में दिखाता है।

प्रारूप: PEM, DER, और .pfx का सवाल

PEM, लेबल वाले शीर्षलेख के साथ Base64 में लिपटे DER बाइट्स हैं; DER कच्चा एन्कोडिंग है। उनके बीच बदलने से कुछ खोता नहीं और कुछ साबित नहीं होता — यह एक ही वस्तु एक अलग लिफ़ाफ़े में है — इसीलिए हर कार्ड दोनों डाउनलोड प्रदान करता है। Windows और कुछ Java उपकरण DER या PKCS#12 पसंद करते हैं; अधिकांश Unix उपकरण PEM चाहते हैं। PKCS#12 (.pfx/.p12) एक अलग बात है: यह अपने स्वयं के अखंडता MAC के साथ एक एन्क्रिप्टेड कंटेनर है, और ऐसा बनाना जिसे हर उपभोक्ता स्वीकार करे — उस नाम के योग्य सुरक्षा के साथ — वेब पेज में हाथ से बनाने वाली चीज़ नहीं है। यह उपकरण जानबूझकर उसे प्रदान नहीं करता। एक मिलान की गई जोड़ी को स्वयं पैकेज करने के लिए, openssl को वहाँ चलाएँ जहाँ फ़ाइलें रहती हैं: openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out bundle.pfx — इस पेज के यह बताने के बाद कि कौन-सी कुंजी, प्रमाणपत्र और श्रृंखला वास्तव में एक साथ हैं।

पार्सिंग और श्रृंखलन इस साइट के लिए हाथ से लिखा DER कोड है (BSD-शैली, कोई तृतीय-पक्ष पार्सर नहीं); हैशिंग, हस्ताक्षर सत्यापन और कुंजी निर्माण ब्राउज़र के WebCrypto का उपयोग करते हैं। इस उपकरण का कोई भी भाग नेटवर्क अनुरोध नहीं करता।

अक्सर पूछे जाने वाले प्रश्न

मैचर कैसे साबित करता है कि एक कुंजी और एक प्रमाणपत्र एक साथ हैं?

फ़ाइलों की नहीं, सार्वजनिक कुंजी की तुलना करके। हर प्रमाणपत्र, CSR और निजी कुंजी एक ही एन्कोड की गई सार्वजनिक कुंजी (SubjectPublicKeyInfo) देती है; यह पेज उस पर SHA-256 लागू करता है और उन आइटमों को समूहित करता है जिनके हैश मेल खाते हैं। एक समान सार्वजनिक कुंजी का अर्थ है कि निजी कुंजी गणितीय रूप से वही है जिसके लिए प्रमाणपत्र जारी किया गया था — वही जाँच जो openssl अपने मापांक तुलना से करता है, सभी फ़ाइलों के लिए एक साथ की गई और RSA के साथ-साथ EC कुंजियों के लिए भी।

क्या किसी वास्तविक निजी कुंजी को वेब पेज में लोड करना सुरक्षित है?

इस पेज पर, हाँ, इसके बनाए जाने के तरीके के कारण: सब कुछ आपके ब्राउज़र में स्थानीय रूप से पार्स होता है, कुंजियाँ केवल इस टैब की स्मृति में रखी जाती हैं, कुछ भी अपलोड, लॉग या किसी भंडारण में लिखा नहीं जाता, और पेज कोई नेटवर्क अनुरोध नहीं करता। रखने योग्य आदत यह है कि कुंजी चिपकाने से पहले किसी भी उपकरण पर उस दावे की जाँच करें — और कभी भी निजी कुंजी को चैट, टिकट या सर्वर-पक्षीय "चेकर" में न चिपकाएँ जो उसे दूरस्थ रूप से संसाधित करता है।

श्रृंखला निर्माता में "केवल नाम मिलान" का क्या अर्थ है?

श्रृंखला निर्माता हर प्रमाणपत्र के जारीकर्ता नाम को अगले प्रमाणपत्र के विषय नाम से मिलाकर प्रमाणपत्रों को क्रमबद्ध करता है, फिर जारीकर्ता की सार्वजनिक कुंजी से वास्तविक हस्ताक्षर को सत्यापित करने का प्रयास करता है। जहाँ हस्ताक्षर एल्गोरिदम वह है जिसे ब्राउज़र का WebCrypto जाँच सकता है (व्यवहार में RSA और ECDSA), कड़ी को "हस्ताक्षर सत्यापित" लेबल किया जाता है या, यदि जाँच विफल हो, "हस्ताक्षर विफल"। बाकी सब — RSA-PSS सामान्य मामला है — ईमानदारी से "केवल नाम मिलान" लेबल किया जाता है: नाम मेल खाते हैं, लेकिन इस पेज ने कड़ी को क्रिप्टोग्राफ़िक रूप से साबित नहीं किया।

PKCS#12 (.pfx) निर्यात क्यों नहीं है?

एक PKCS#12 फ़ाइल एक कुंजी और प्रमाणपत्र को MAC अखंडता के साथ पासवर्ड-आधारित एन्क्रिप्शन में लपेटती है — एक ऐसा प्रारूप जिसे सावधान, अच्छी तरह परीक्षित एन्कोडिंग की आवश्यकता होती है। हाथ से बना संस्करण देने के बजाय जो ऐसी फ़ाइलें बना सकता है जिन्हें अन्य सॉफ़्टवेयर अस्वीकार कर दे (या, और बुरा, कमज़ोर रूप से संरक्षित कुंजियाँ), यह पेज PEM और DER के बीच बदलता है और .pfx पैकेजिंग openssl पर छोड़ता है: कमांड पेज पर दिखाया गया है ताकि आप उसे वहाँ चला सकें जहाँ कुंजी पहले से रहती है।

क्या यह पेज एन्क्रिप्टेड निजी कुंजी पढ़ सकता है?

यह एक को पहचान सकता है और ऐसा कह सकता है, लेकिन उसका उपयोग नहीं कर सकता: एक एन्क्रिप्टेड (पासवर्ड-संरक्षित) कुंजी डिक्रिप्ट होने तक अपनी सार्वजनिक कुंजी प्रकट नहीं करती, और मिलान सार्वजनिक कुंजी पर किया जाता है। openssl से स्थानीय रूप से एक प्रति डिक्रिप्ट करें (pkcs8 -topk8 -nocrypt, या rsa/ec) और डिक्रिप्ट की गई प्रति लोड करें — एक ऐसी मशीन पर जिस पर आप भरोसा करते हैं, और प्रति को बाद में हटा दें।