सर्टिफ़िकेट चेन चेकर

सर्वर सहायता नया वेबसाइट और HTTP डायग्नोस्टिक्स

सर्वर TLS हैंडशेक में जो चेन देता है (Mutqan सर्वर Cloudflare नेटवर्क से जुड़ता है) या जो PEM बंडल आप पेस्ट करते हैं, उसे पढ़कर leaf से जारीकर्ता के नाम और key identifier के सहारे आगे बढ़ता है, और WebCrypto से जाँचता है कि हर सर्टिफ़िकेट का सिग्नेचर उसके बाद वाले सर्टिफ़िकेट की key से सत्यापित होता है। ग़ायब intermediate, ग़लत क्रम, फ़ालतू या एक्सपायर सर्टिफ़िकेट और CA की शर्तें बताता है; कोई root store इस्तेमाल नहीं होता, इसलिए यह चेन का वर्णन करता है, उसे भरोसेमंद घोषित नहीं करता।

गोपनीयता: Mutqan सर्वर इस पेज पर बताई गई छोटी, तय टेस्ट रिक्वेस्ट आपके बताए होस्ट को भेजता है, और कुछ भी स्टोर नहीं होता। इसे सिर्फ़ उन्हीं सिस्टम पर इस्तेमाल करें जिन्हें टेस्ट करने की आपको अनुमति है।

सर्वर को intermediate सर्टिफ़िकेट क्यों भेजने चाहिए?

क्लाइंट के पास सिर्फ़ root सर्टिफ़िकेट होते हैं, जबकि साइट का सर्टिफ़िकेट किसी intermediate CA से साइन होता है, इसलिए सर्वर को अपने सर्टिफ़िकेट के बाद उस root तक के सारे intermediate भेजने होते हैं (RFC 8446 §4.4.2)। फिर क्लाइंट हर कड़ी — issuer नाम, key identifier और सिग्नेचर (RFC 5280) — जाँचता है जब तक वह ऐसे root तक न पहुँचे जिस पर वह पहले से भरोसा करता है; कोई intermediate ग़ायब हो तो कई क्लाइंट यह रास्ता नहीं बना पाते और कनेक्शन ठुकरा देते हैं।

सर्टिफ़िकेट चेन चेकर कैसे इस्तेमाल करें

  1. होस्टनेम डालें (या IP एड्रेस और Server name (SNI) में साइट का नाम), या साइट के सर्टिफ़िकेट से शुरू होने वाला बंडल पेस्ट करें।
  2. «चेन जाँचें» दबाएँ।
  3. सारांश पढ़ें: «चेन पूरी» और «सिग्नेचर सत्यापित» दोनों ✓ होने चाहिए। फिर समस्याओं की सूची पढ़ें, अगर हो।
  4. सर्वर की सेटिंग ठीक करें — अक्सर सिर्फ़ सर्टिफ़िकेट की जगह पूरी चेन वाली फ़ाइल लगाना काफ़ी होता है — और फिर जाँचें।

सर्टिफ़िकेट चेन चेकर की खूबियाँ

  • सर्वर TLS हैंडशेक में जो सर्टिफ़िकेट भेजता है, ठीक उसी सूची और क्रम में पढ़ता है — उन TLS 1.3 सर्वरों में भी जहाँ Certificate मैसेज एन्क्रिप्टेड होता है
  • पेस्ट किया PEM बंडल (fullchain.pem, CA bundle, लोड बैलेंसर एक्सपोर्ट) डिप्लॉय करने से पहले पूरी तरह आपके ब्राउज़र में जाँचता है
  • leaf से जारीकर्ता के नाम और key identifier के सहारे चेन पर चढ़ता है और बताता है कि वह ऐसे CA तक पहुँचती है या नहीं जिसका root क्लाइंट के पास होना चाहिए
  • हर कड़ी WebCrypto से सत्यापित करता है: हर सर्टिफ़िकेट का सिग्नेचर उसके बताए जारीकर्ता की public key से जाँचा जाता है (RSA, RSA-PSS, ECDSA P-256/384/521, Ed25519)
  • ग़ायब intermediate, ग़लत क्रम, डुप्लिकेट, बेमतलब के अतिरिक्त सर्टिफ़िकेट, एक्सपायर या अभी लागू न हुए सदस्य, CA फ़्लैग या keyCertSign के बिना जारीकर्ता, और pathLen का उल्लंघन पकड़ता है
  • हर सर्टिफ़िकेट की भूमिका, subject, जारीकर्ता, एक्सपायरी, बचे दिन, key और उसे साइन करने वाले सर्टिफ़िकेट की तालिका
  • भेजी गई चेन PEM रूप में, कॉपी करने या chain.pem के नाम से डाउनलोड के लिए तैयार

इनपुट और आउटपुट

इनपुट

  • होस्टनेम या URL, पोर्ट और Server name (SNI): चेन कहाँ से पढ़नी है, SSL सर्टिफ़िकेट चेकर की तरह।
  • या पेस्ट किया बंडल: PEM सर्टिफ़िकेट उसी क्रम में जिसमें सर्वर भेजता, पहले साइट का सर्टिफ़िकेट। बंडल हो तो कुछ फ़ेच नहीं होता; होस्टनेम दिया हो तो सिर्फ़ पहले सर्टिफ़िकेट से मिलाया जाता है।

आउटपुट

  • सारांश: सर्टिफ़िकेट की संख्या, चेन पूरी है या नहीं, leaf से root का क्रम, हर कड़ी का सिग्नेचर सत्यापित हुआ या नहीं, root शामिल है या नहीं, और leaf होस्ट को कवर करता है या नहीं।
  • चेन: हर सर्टिफ़िकेट की एक पंक्ति — भूमिका (leaf, intermediate, root या चेन से बाहर), subject, जारीकर्ता, एक्सपायरी, बचे दिन, key और वह सर्टिफ़िकेट जिसकी key से उसका सिग्नेचर सत्यापित हुआ।
  • समस्याएँ: हर समस्या एक वाक्य में, सर्टिफ़िकेट के नंबर और subject के साथ।
  • भेजी गई चेन (सिर्फ़ लाइव जाँच): सर्वर के क्रम में PEM सर्टिफ़िकेट।

सर्टिफ़िकेट चेन चेकर का उदाहरण

उदाहरण बंडल: साइट सर्टिफ़िकेट और उसका intermediate, पेस्ट करके (14 अक्टूबर 2026 को जाँचा गया)

इनपुट:

पेस्ट किया बंडल: www.example.com का सर्टिफ़िकेट, उसके बाद «Example Issuing CA R1» (पेज का उदाहरण)
होस्टनेम: www.example.com

आउटपुट:

सर्टिफ़िकेट 2 · चेन पूरी ✓ · leaf से root का क्रम ✓ · सिग्नेचर सत्यापित ✓ (हर कड़ी जाँची) · root शामिल ✗ (वैकल्पिक) · leaf इस होस्ट को कवर करता है ✓
#1 www.example.com · जारीकर्ता Example Issuing CA R1 · leaf · 2046-10-01 तक वैध · 7291 दिन · EC P-256 (256 bits) · साइन करने वाला ✓ (#2)
#2 Example Issuing CA R1 · जारीकर्ता Example Root CA X1 · intermediate · 2051-10-01 तक वैध · EC P-256 (256 bits) · साइन करने वाला — (root नहीं भेजा गया)

सर्टिफ़िकेट चेन चेकर के नतीजे कैसे पढ़ें

«चेन पूरी» ✓ का मतलब है चेन leaf से शामिल किए गए root तक जाती है, या ऐसे CA सर्टिफ़िकेट तक जिसका जारीकर्ता भेजा नहीं गया और जिसके क्लाइंट के store में होने की उम्मीद है (यह जाँचा नहीं जाता)। ✗ का मतलब अक्सर intermediate ग़ायब है: ब्राउज़र इसे ठीक कर सकते हैं, ज़्यादातर दूसरे क्लाइंट नहीं।

«सिग्नेचर सत्यापित» ✓ का मतलब है जाँची जा सकने वाली हर कड़ी सत्यापित हुई। ✗ का मतलब है कोई सर्टिफ़िकेट उस सर्टिफ़िकेट से साइन नहीं है जिसे उसका जारीकर्ता बताया गया — आमतौर पर किसी दूसरे CA का intermediate, या CA के intermediate बदलने के बाद पुराना वाला। ? का मतलब ऐसा एल्गोरिद्म जिसे WebCrypto सत्यापित नहीं कर सकता। — का मतलब कोई कड़ी जाँचने को नहीं थी: सिर्फ़ leaf भेजा गया।

«root शामिल» ✗ सामान्य है, ग़लती नहीं। «चेन से बाहर» वाली पंक्ति ऐसा सर्टिफ़िकेट है जिसे सर्वर बेवजह भेजता है: बाइट बचाने और क्लाइंट को उलझन से बचाने के लिए उसे हटा दें।

साफ़ नतीजा सर्वर की भेजी चेन का वर्णन है; कोई ब्राउज़र या डिवाइस उसके root पर भरोसा करता है या नहीं, यह उस क्लाइंट का root store तय करता है, जो इस पेज के पास नहीं है।

सर्टिफ़िकेट चेन चेकर कब इस्तेमाल करें

  • पता करें कि API क्लाइंट, मोबाइल ऐप या curl उस साइट को क्यों ठुकराता है जो डेस्कटॉप ब्राउज़र में ठीक खुलती है।
  • लोड बैलेंसर, मेल सर्वर या किसी appliance पर लगाने से पहले fullchain.pem या CA bundle जाँचें।
  • रिन्यूअल के बाद पक्का करें कि सर्वर CA का नया intermediate भेज रहा है और पुराना नहीं।
  • लंबी चेन में कौन-सा सर्टिफ़िकेट एक्सपायर है या उसमें CA फ़्लैग नहीं, यह दिखाएँ।

समस्या निवारण

  • «सर्वर ने सिर्फ़ leaf सर्टिफ़िकेट भेजा»: पूरी चेन लगाएँ — nginx में ssl_certificate को fullchain फ़ाइल की ओर इशारा करना चाहिए, Apache में intermediates वाली सर्टिफ़िकेट फ़ाइल इस्तेमाल करें, लोड बैलेंसर पर CA bundle अपलोड करें।
  • «से साइन नहीं है»: intermediate इस leaf का नहीं है। आपका CA अभी जिस intermediate से जारी करता है उसे डाउनलोड करके पुराना बदलें।
  • «leaf से शुरू होने वाली चेन का हिस्सा नहीं है»: कोई अतिरिक्त सर्टिफ़िकेट (अक्सर पुराना intermediate या अब ग़ैरज़रूरी cross-sign) भेजा जा रहा है। उसे बंडल से हटाएँ।
  • «सर्टिफ़िकेट leaf से root के क्रम में नहीं हैं»: बंडल का क्रम बदलें ताकि साइट का सर्टिफ़िकेट पहले हो और हर सर्टिफ़िकेट के बाद उसका जारीकर्ता।
  • Cloudflare से होकर: चेन पेस्ट करें। ज़्यादातर ब्राउज़रों का सर्टिफ़िकेट व्यूअर चेन को PEM में एक्सपोर्ट कर सकता है; सर्वर पर वह fullchain फ़ाइल लें जो आपके CA क्लाइंट ने लिखी।

सर्टिफ़िकेट चेन चेकर के बारे में अक्सर पूछे जाने वाले सवाल

मेरी साइट ब्राउज़र में खुलती है, पर मोबाइल ऐप या curl में SSL एरर क्यों आता है?

जब सर्वर सिर्फ़ अपना सर्टिफ़िकेट भेजता है, तो कुछ ब्राउज़र चेन ख़ुद ठीक कर लेते हैं — सर्टिफ़िकेट में लिखे पते से intermediate डाउनलोड करके या पहले से रखी कॉपी इस्तेमाल करके — इसलिए आपके कंप्यूटर पर साइट ठीक दिखती है। curl, Java और Python प्रोग्राम, ज़्यादातर API क्लाइंट और मोबाइल ऐप ऐसा नहीं करते और फ़ेल हो जाते हैं। इलाज सर्वर पर है: leaf के बाद सारे intermediate भेजें (अक्सर fullchain.pem फ़ाइल)।

क्या root सर्टिफ़िकेट भी चेन में भेजना चाहिए?

ज़रूरत नहीं: क्लाइंट अपने store का root इस्तेमाल करता है, सर्वर की भेजी कॉपी नहीं, इसलिए उसे भेजना हर हैंडशेक में बस बाइट बढ़ाता है। नुकसान भी नहीं है, और चेकर इसे जानकारी की तरह बताता है, ग़लती की तरह नहीं।

«अगले सर्टिफ़िकेट से साइन» होने से क्या साबित होता है?

यह कि हर सर्टिफ़िकेट का सिग्नेचर उस सर्टिफ़िकेट की public key से सत्यापित होता है जिसे सर्वर उसका जारीकर्ता बताता है — यानी चेन क्रिप्टोग्राफ़िक रूप से सुसंगत है। इससे भरोसा साबित नहीं होता: हर कड़ी सत्यापित होने पर भी चेन ऐसे root पर ख़त्म हो सकती है जो किसी ब्राउज़र में नहीं। उस आख़िरी क़दम के लिए root store चाहिए, जो इस चेकर के पास नहीं है।

सर्टिफ़िकेट किस क्रम में भेजे जाने चाहिए?

पहले leaf, फिर उसे जारी करने वाला, फिर उसे जारी करने वाला, और इसी तरह। RFC 8446 में leaf का पहले आना ज़रूरी है और कहा गया है कि हर अगला सर्टिफ़िकेट पिछले वाले को प्रमाणित करे; कुछ क्लाइंट दूसरा क्रम सह लेते हैं और कुछ नहीं, इसलिए चेकर इसे बताता है।

Cloudflare वाली साइट की चेन कैसे जाँचें?

होस्टनेम से नहीं: Mutqan सर्वर Cloudflare Workers पर चलता है, जिसे Cloudflare के एड्रेस पर सीधे कनेक्शन खोलने की अनुमति नहीं है। ब्राउज़र के सर्टिफ़िकेट व्यूअर से चेन एक्सपोर्ट करें (या सर्वर की fullchain फ़ाइल लें) और पेस्ट करें, या origin सर्वर को IP और Server name (SNI) में साइट के नाम से जाँचें।

किसी कड़ी पर ✓ या ✗ की जगह ? क्यों दिखता है?

उसका सिग्नेचर ऐसे एल्गोरिद्म में है जिसे WebCrypto सत्यापित नहीं कर सकता — DSA, Ed448, MD5 या SHA-224 आधारित सिग्नेचर, या कोई असामान्य curve। कड़ी को «सत्यापित नहीं» बताया जाता है, «टूटी» नहीं; ज़रूरी हो तो OpenSSL से जाँचें।

तकनीकी नोट्स

TLS सर्वर अपनी certificate_list में पहले leaf भेजता है; RFC 8446 §4.4.2 (और TLS 1.2 के लिए RFC 5246) कहता है कि हर अगला सर्टिफ़िकेट पिछले वाले को प्रमाणित करे। root छोड़ा जा सकता है, क्योंकि क्लाइंट उसे अपने store से लेते हैं।

कड़ियाँ RFC 5280 के अनुसार जुड़ती हैं: सर्टिफ़िकेट का issuer नाम अगले सर्टिफ़िकेट के subject नाम के बराबर हो, और दोनों में हों तो Authority Key Identifier जारीकर्ता के Subject Key Identifier के बराबर हो। हर जारी करने वाला सर्टिफ़िकेट CA (basicConstraints) हो, सर्टिफ़िकेट साइन करने की अनुमति (keyCertSign) रखता हो, और अपने pathLenConstraint व वैधता की तारीख़ों के भीतर हो।

हर कड़ी WebCrypto से जारीकर्ता की public key के साथ TBSCertificate बाइट पर सिग्नेचर जाँचकर सत्यापित होती है: SHA-1 या SHA-2 के साथ RSASSA-PKCS1-v1_5 और RSA-PSS, P-256, P-384 और P-521 पर ECDSA (DER सिग्नेचर को raw r||s रूप में बदलकर), और Ed25519। जो एल्गोरिद्म WebCrypto में नहीं हैं वे «जाँच योग्य नहीं» बताए जाते हैं, कभी सही नहीं।

पेस्ट किया टेक्स्ट (अधिकतम 256 KB) RFC 7468 PEM की तरह पढ़ा जाता है: हर -----BEGIN CERTIFICATE----- ब्लॉक, अधिकतम 16, दिए गए क्रम में। जिस ब्लॉक का base64 या DER डिकोड न हो सके, उसे टेक्स्ट में उसकी जगह से बताया जाता है और विश्लेषण से बाहर रखा जाता है।

सीमाएँ और कार्यप्रणाली

कोई root store नहीं: चेकर बता सकता है कि चेन पूरी है और उसके सिग्नेचर सत्यापित हैं, यह नहीं कि ब्राउज़र उस पर भरोसा करता है। Revocation (OCSP, CRL) और Certificate Transparency नहीं जाँचे जाते।

लाइव जाँच उस Cloudflare डेटा सेंटर से जुड़ती है जो आपका अनुरोध संभालता है; Cloudflare पर रिज़ॉल्व होने वाले होस्ट तक उसका सीधा कनेक्शन पहुँच ही नहीं सकता, और क्षेत्र के हिसाब से जवाब देने वाला सर्वर आपके विज़िटर को दूसरी चेन भेज सकता है।

cross-signed रास्ते नहीं खोजे जाते: चेन असल में भेजे गए सर्टिफ़िकेट से होकर, key identifier मिलान को पहले रखते हुए, बनाई जाती है; क्लाइंट अपने पास के सर्टिफ़िकेट से जो दूसरे रास्ते बना सकता है वे नहीं देखे जाते।

सुरक्षा और गोपनीयता

पेस्ट किया बंडल आपके ब्राउज़र में डिकोड और सत्यापित होता है और वहीं रहता है। लाइव जाँच में होस्ट, पोर्ट और server name Mutqan सर्वर तक जाते हैं, जो एक TLS कनेक्शन खोलता है और टारगेट या नतीजे के बारे में कुछ स्टोर नहीं करता। private key कभी पेस्ट न करें; पेज ऐसा टेक्स्ट ठुकरा देता है।

संदर्भ

  • RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileIETF · 2008TLS में इस्तेमाल होने वाले सर्टिफ़िकेट की प्रोफ़ाइल: वैधता अवधि, subjectAltName, key usage और basic constraints एक्सटेंशन, और वह path validation एल्गोरिद्म जो सर्टिफ़िकेट को उसके जारीकर्ता से जोड़ता है।
  • RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3IETF · 2018TLS 1.3 हैंडशेक और रिकॉर्ड प्रोटोकॉल जो HTTPS ट्रैफ़िक की रक्षा करते हैं।
  • RFC 7468: Textual Encodings of PKIX, PKCS, and CMS StructuresIETF · 2015सर्टिफ़िकेट का PEM टेक्स्ट रूप: BEGIN और END लाइनें और Base64 बॉडी, जो सर्टिफ़िकेट फ़ाइलें और पेस्ट किए सर्टिफ़िकेट इस्तेमाल करते हैं।