यह कैसे काम करता है
X.509 प्रमाणपत्र एक हस्ताक्षरित दस्तावेज़ है जो किसी सार्वजनिक कुंजी को एक नाम से जोड़ता है: किसी डोमेन, व्यक्ति या संगठन से। सर्वरों के बीच और फ़ाइलों में इसका बाइनरी रूप (DER) चलता है, और जिसे कॉपी-पेस्ट किया जाता है वह BEGIN CERTIFICATE और END CERTIFICATE पंक्तियों के बीच Base64 में वही संरचना है — यानी PEM फ़ॉर्मैट। इसके अंदर विषय, जारीकर्ता, वैधता अवधि, सार्वजनिक कुंजी और ऐसे एक्सटेंशन होते हैं जो बताते हैं कि यह किस काम के लिए है और कहाँ जाँचा जाए कि इसे निरस्त तो नहीं किया गया।
यह टूल प्रमाणपत्र, PKCS#10 हस्ताक्षर अनुरोध (CSR), PKCS#8, PKCS#1 और SEC1 निजी कुंजियाँ, सार्वजनिक कुंजियाँ, PKCS#7 पैकेज (.p7b) और PKCS#12 फ़ाइलें (.pfx, .p12) पहचानता है। यदि आप कई ब्लॉक एक साथ पेस्ट करते हैं, तो यह चेन को लीफ़ प्रमाणपत्र से रूट तक क्रम में लगाता है, हर हस्ताक्षर को जारीकर्ता की कुंजी से सत्यापित करता है और निजी कुंजी की तुलना हर प्रमाणपत्र और हर CSR से करके बताता है कि कौन किससे मेल खाता है।
यह फ़ॉर्मैट के बीच कन्वर्ट भी करता है, प्रमाणपत्र और कुंजी से वह .pfx बनाता है जो IIS और Azure माँगते हैं, और निजी कुंजी के साथ नया CSR या परीक्षण के लिए सेल्फ़-साइन्ड प्रमाणपत्र जनरेट करता है। सब कुछ आपके ब्राउज़र के क्रिप्टोग्राफ़ी API से होता है: न प्रमाणपत्र और न ही कुंजियाँ किसी सर्वर पर भेजी जाती हैं।
उदाहरण
ISRG Root X1 · SHA-25696:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6Let's Encrypt के रूट प्रमाणपत्र का SHA-256 फ़िंगरप्रिंट। यही वह मान है जिसे प्राधिकरण और ट्रस्ट स्टोर प्रकाशित करते हैं: यदि आपकी फ़ाइल का फ़िंगरप्रिंट इससे मेल खाता है, तो वह ठीक वही प्रमाणपत्र है।ISRG Root X1 · pin SPKIC5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=Base64 में सार्वजनिक कुंजी का SHA-256। यही मान Android की नेटवर्क सुरक्षा कॉन्फ़िगरेशन के pin-sha256 में या किसी ऐप के certificate pinning में डाला जाता है, और यदि कुंजी दोबारा उपयोग की जाए तो प्रमाणपत्र नवीनीकृत करने पर यह नहीं बदलता।root.crt + intermediate.crt + server.crtserver.crt + intermediate.crt + root.crtnginx और HAProxy फ़ाइल के पहले प्रमाणपत्र को सर्वर का प्रमाणपत्र मानते हैं। यदि चेन उल्टी है, तो nginx key values mismatch त्रुटि देता है, क्योंकि वह निजी कुंजी की तुलना रूट प्रमाणपत्र से करता है।openssl pkcs12 -in viejo.pfx -legacy -nodes | openssl pkcs12 -export -out nuevo.pfxPBES2 · AES-256-CBC · MAC SHA-256पुराने Windows या OpenSSL 1.x द्वारा एक्सपोर्ट की गई .pfx फ़ाइलें RC2 और 3DES से एन्क्रिप्ट होती हैं, जिन्हें ब्राउज़र लागू नहीं करते। यह कमांड उन्हें AES से दोबारा एन्क्रिप्ट करती है, जो OpenSSL 3 का डिफ़ॉल्ट फ़ॉर्मैट है।उपयोग के मामले
- इंस्टॉल करने से पहले जाँचना कि प्राधिकरण द्वारा भेजा गया प्रमाणपत्र सभी डोमेन (SAN) को कवर करता है और उसकी समाप्ति तिथि अपेक्षित है।
- OpenSSL से मॉड्यूलस की तुलना किए बिना पता लगाना कि सर्वर पर बची निजी कुंजियों में से कौन-सी किस प्रमाणपत्र से मेल खाती है।
- यह पता लगाना कि कोई क्लाइंट आपकी साइट पर भरोसा क्यों नहीं करता: कोई गायब इंटरमीडिएट, गलत क्रम वाली चेन या SHA-1 से हस्ताक्षरित प्रमाणपत्र।
- प्रमाणपत्र ख़रीदने या नवीनीकृत करने के लिए CSR जनरेट करना, जिसकी कुंजी आपके अपने कंप्यूटर पर बनती है, साथ ही समतुल्य OpenSSL कमांड भी, यदि आप यह काम सर्वर पर करना पसंद करें।
- किसी .crt और उसकी .key को IIS, Azure App Service या Java keystore के लिए .pfx में बदलना, या nginx के लिए किसी .pfx से प्रमाणपत्र और कुंजी निकालना।
- किसी मोबाइल ऐप में certificate pinning कॉन्फ़िगर करने या क्लाइंट प्रमाणपत्र सत्यापित करने के लिए प्रमाणपत्र का फ़िंगरप्रिंट या SPKI पिन प्राप्त करना।
अक्सर पूछे जाने वाले प्रश्न
क्या यहाँ अपनी निजी कुंजी पेस्ट करना सुरक्षित है?
कुंजी को आपके ब्राउज़र के अंदर Web Crypto API से प्रोसेस किया जाता है और किसी सर्वर पर नहीं भेजा जाता; आप इसे डेवलपर टूल्स के Network टैब में जाँच सकते हैं। फिर भी, अच्छा अभ्यास यही है कि किसी भी प्रोडक्शन कुंजी को एक सीक्रेट की तरह रखें: इसे केवल उन्हीं टूल्स में पेस्ट करें जिन पर आपको भरोसा है और काम पूरा होने पर टैब बंद कर दें।
PEM, DER, CRT, CER, P7B और PFX में क्या अंतर है?
DER बाइनरी रूप में प्रमाणपत्र है और PEM वही बाइनरी डेटा है जो BEGIN और END पंक्तियों के बीच Base64 में होता है। .crt और .cer एक्सटेंशन फ़ॉर्मैट नहीं बताते: इनमें दोनों में से कोई भी हो सकता है। .p7b एक PKCS#7 पैकेज है जिसमें कई प्रमाणपत्र होते हैं और कोई कुंजी नहीं होती। .pfx या .p12 एक PKCS#12 है: यह प्रमाणपत्र, इंटरमीडिएट और निजी कुंजी को एक साथ, पासवर्ड से एन्क्रिप्ट करके रखता है।
मुझे कैसे पता चले कि मेरे सर्वर पर इंटरमीडिएट प्रमाणपत्र गायब है?
सर्वर पर जो कॉन्फ़िगर है उसे पेस्ट करें। यदि चेन ऐसे प्रमाणपत्र पर ख़त्म होती है जो सेल्फ़-साइन्ड नहीं है, तो एक कड़ी गायब है: उस प्रमाणपत्र के Authority Information Access एक्सटेंशन में CA Issuers के अंतर्गत आमतौर पर जारीकर्ता को डाउनलोड करने का पता होता है। डेस्कटॉप ब्राउज़र कभी-कभी इसे ख़ुद ढूँढ लेते हैं, लेकिन Android, curl और ज़्यादातर लाइब्रेरी नहीं, इसलिए त्रुटि केवल कुछ क्लाइंट में दिखाई देती है।
एक सार्वजनिक TLS प्रमाणपत्र अधिकतम कितने समय तक वैध रह सकता है?
सितंबर 2020 से ब्राउज़र 398 दिनों से अधिक अवधि वाले प्रमाणपत्र अस्वीकार करते हैं। CA/Browser Forum ने 2025 में अधिकतम अवधि को चरणों में घटाने को मंज़ूरी दी: 15 मार्च 2026 से जारी प्रमाणपत्रों के लिए 200 दिन, मार्च 2027 से 100 दिन और मार्च 2029 से 47 दिन। इसलिए ACME से नवीनीकरण को स्वचालित करना बेहतर है। कंपनियों के आंतरिक CA पर यह सीमा लागू नहीं होती।
CSR के लिए RSA या ECDSA?
ECDSA P-256 बहुत छोटी कुंजियों और हस्ताक्षरों के साथ 3072-बिट RSA के बराबर सुरक्षा देता है, और सर्वर हैंडशेक तेज़ी से करता है। सभी मौजूदा ब्राउज़र और सिस्टम इसका समर्थन करते हैं। यदि आपके क्लाइंट बहुत पुराने हैं, एम्बेडेड डिवाइस हैं या कोई सिस्टम केवल RSA स्वीकार करता है, तो RSA 2048 अब भी सुरक्षित विकल्प है।
क्या डोमेन को कॉमन नेम (CN) में डालना काफ़ी है?
नहीं। 2017 में Chrome 58 से ब्राउज़र केवल वैकल्पिक नामों (SAN) को देखते हैं और CN को अनदेखा किया जाता है। प्रमाणपत्र जिस भी डोमेन के लिए इस्तेमाल होगा, CN वाले डोमेन सहित, वह SAN सूची में होना चाहिए। *.example.com जैसा वाइल्डकार्ड केवल एक स्तर को कवर करता है: यह www.example.com के लिए काम करता है, लेकिन example.com या a.b.example.com के लिए नहीं।