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

TLS सर्टिफ़िकेट क्या साबित करता है?

TLS सर्टिफ़िकेट एक X.509 दस्तावेज़ (RFC 5280) है जो एक public key को उसके subjectAltName में लिखे नामों से एक तय अवधि के लिए बाँधता है, और जिस पर जारी करने वाली CA के हस्ताक्षर होते हैं। ब्राउज़र उसे तभी मानता है जब तारीख़ें चालू हों, माँगा गया नाम SAN में हो (RFC 9525) और हस्ताक्षर ऐसे root तक पहुँचें जो उसके पास पहले से है; यह चेन और ये नाम जाँचे बिना अकेला सर्टिफ़िकेट कुछ साबित नहीं करता।

सुरक्षा नोट: सर्टिफ़िकेट सार्वजनिक होता है, पर उससे जुड़ी private key कभी सर्वर से बाहर नहीं जानी चाहिए: किसी वेब पेज में private key कभी पेस्ट न करें, और जिस सर्टिफ़िकेट की key उजागर हुई हो उसे बदल दें।

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

1. होस्टनेम (www.example.com), IP एड्रेस या पूरा URL डालें। सेवा 443 पर न हो तो पोर्ट बदलें, या host:port लिखें।
2. IP एड्रेस डालने पर Server name (SNI) में साइट का होस्टनेम लिखें, ताकि सर्वर अपना डिफ़ॉल्ट सर्टिफ़िकेट नहीं बल्कि उसी साइट का सर्टिफ़िकेट लौटाए।
3. «सर्टिफ़िकेट जाँचें» दबाएँ। साइट Cloudflare से होकर चलती हो तो पेज तुरंत बता देगा; तब सर्टिफ़िकेट पेस्ट करें (ब्राउज़र के ताले वाले मेन्यू से PEM में एक्सपोर्ट करके)।
4. पहले सारांश और नतीजे पढ़ें, फिर सर्टिफ़िकेट की फ़ील्ड। जारी करने वाले सर्टिफ़िकेट देखने हों तो सर्टिफ़िकेट चेन चेकर खोलें।

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

• सर्वर जो सर्टिफ़िकेट असल में देता है वही पढ़ता है: Mutqan सर्वर होस्ट और पोर्ट से TLS हैंडशेक खोलकर Certificate मैसेज ख़ुद डिकोड करता है — TLS 1.3 में भी और TLS 1.2 में भी
• पेस्ट किया गया PEM सर्टिफ़िकेट पूरी तरह आपके ब्राउज़र में डिकोड होता है, कुछ भी नहीं भेजा जाता — उन साइटों के लिए जिन तक सर्वर नहीं पहुँचता और उन सर्टिफ़िकेट के लिए जो अभी लगे नहीं हैं
• बचे दिन, वैधता अवधि, जारीकर्ता, Subject Alternative Names, public key, सिग्नेचर एल्गोरिद्म, सीरियल नंबर और SHA-256 व SHA-1 फ़िंगरप्रिंट एक ही जगह
• होस्टनेम को SAN एंट्री से वैसे ही मिलाता है जैसे ब्राउज़र मिलाते हैं (RFC 9525): wildcard सिर्फ़ एक लेवल कवर करता है, Common Name तभी देखा जाता है जब SAN हो ही नहीं
• Server name (SNI) फ़ील्ड से किसी IP एड्रेस से किसी ख़ास साइट का सर्टिफ़िकेट माँगा जा सकता है, ताकि CDN के पीछे का origin सर्वर सीधे जाँचा जा सके
• जिन बातों पर काम करना है उनके साफ़ नतीजे: एक्सपायर या अभी लागू नहीं, 30 या 7 दिन में रिन्यूअल, ऐसा नाम जो सर्टिफ़िकेट में नहीं, SHA-1, छोटी RSA key, serverAuth का न होना
• हैंडशेक की कनेक्शन डिटेल (एड्रेस, प्रोटोकॉल, cipher suite, ALPN, समय) और PEM रूप में सर्टिफ़िकेट, कॉपी या डाउनलोड के लिए तैयार

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

इनपुट

• होस्टनेम या URL: नाम, IPv4 या IPv6 एड्रेस, host:port, [IPv6]:port या पूरा URL (उसका होस्ट और स्पष्ट पोर्ट लिया जाता है, पाथ नहीं)।
• पोर्ट: 443, जब तक सेवा कहीं और न हो (8443, IMAPS के लिए 993, SMTPS के लिए 465…); पोर्ट 25 से कभी कनेक्ट नहीं किया जाता।
• Server name (SNI), वैकल्पिक: होस्ट IP एड्रेस हो तो जिस साइट का सर्टिफ़िकेट चाहिए उसका नाम, या शेयर्ड सर्वर की किसी एक साइट को जाँचने के लिए।
• या पेस्ट किया PEM सर्टिफ़िकेट (अधिकतम 256 KB टेक्स्ट): यह हो तो कुछ फ़ेच नहीं होता; पहला CERTIFICATE ब्लॉक जो डिकोड हो जाए वही पढ़ा जाता है, और होस्ट फ़ील्ड भरी हो तो उसका नाम सिर्फ़ इससे मिलाया जाता है।

आउटपुट

• सारांश: बचे दिन, एक्सपायरी तारीख़, सर्टिफ़िकेट होस्ट को कवर करता है या नहीं (और कैसे), जारीकर्ता और key।
• नतीजे: जिन समस्याओं पर काम करना है वे साफ़ वाक्यों में, या एक पंक्ति कि इन जाँचों में कुछ नहीं मिला।
• सर्टिफ़िकेट: subject, SAN सूची, जारीकर्ता, UTC में वैधता, key, सिग्नेचर एल्गोरिद्म, सीरियल, फ़िंगरप्रिंट, key usage, OCSP, CA issuers और CRL के पते, और embedded SCT की गिनती।
• कनेक्शन (सिर्फ़ लाइव जाँच): जिस एड्रेस से जुड़े, पोर्ट, भेजा गया SNI, तय हुआ प्रोटोकॉल और cipher suite, ALPN, हैंडशेक और DNS का समय, भेजे गए सर्टिफ़िकेट की संख्या; साथ में PEM रूप में सर्टिफ़िकेट।

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

होस्टनेम: www.example.com
पेस्ट किया सर्टिफ़िकेट: -----BEGIN CERTIFICATE----- MIICmzCCAkGgAwIBAgIUOw09… -----END CERTIFICATE----- (पेज का उदाहरण, «Example Issuing CA R1» से जारी)

बचे दिन 7291 · वैध 2046-10-01 तक · यह होस्ट कवर है ✓ (SAN में दर्ज) · जारीकर्ता Example Issuing CA R1 · Public key EC P-256 (256 bits)
नतीजे: ऊपर की किसी जाँच में कोई समस्या नहीं मिली। ब्राउज़र जारीकर्ता पर भरोसा करता है या नहीं, और सर्टिफ़िकेट रद्द हुआ या नहीं — यह यहाँ नहीं जाँचा जाता।
Subject Alternative Names: www.example.com, example.com · सिग्नेचर एल्गोरिद्म ecdsa-with-SHA256 · Extended key usage serverAuth
नोट: सर्टिफ़िकेट आपके ब्राउज़र में डिकोड हुआ; कुछ नहीं भेजा गया।

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

बचे दिन UTC में notAfter तक पूरे दिन गिनता है। 30 से कम हो तो देखें कि रिन्यूअल तय है; 7 से कम हो तो अभी रिन्यू करें; ऋणात्मक संख्या का मतलब है कि ब्राउज़र इसे पहले से ही ठुकरा रहे हैं।

✓ के साथ «SAN में दर्ज» ही वह नतीजा है जिसे ब्राउज़र मानते हैं। «सिर्फ़ Common Name» का मतलब है सर्टिफ़िकेट में SAN नहीं है, और आज के ब्राउज़र इसे ठुकरा देते हैं भले नाम सही दिखे। ✗ का मतलब है जो नाम आपने जाँचा वह कवर नहीं है — wildcard बिना www वाले डोमेन या दो लेवल नीचे के नाम को कवर नहीं करता।

«जारीकर्ता का नाम = subject» में ✓ का मतलब है सर्टिफ़िकेट self-issued है (नामों की तुलना, सिग्नेचर की जाँच नहीं)। root CA में यह सामान्य है, पब्लिक वेबसाइट में ग़लत।

नतीजों में कोई समस्या न होने का मतलब है कि तारीख़ें, नाम, key का आकार, सिग्नेचर का हैश और उद्देश्य ठीक हैं। इसका मतलब यह नहीं कि सर्टिफ़िकेट भरोसेमंद है या रद्द नहीं हुआ: यहाँ न root store है, न OCSP या CRL की पूछताछ।

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

• डिप्लॉयमेंट के बाद नई एक्सपायरी तारीख़ और फ़िंगरप्रिंट मिलाकर पक्का करें कि सर्वर सच में रिन्यू हुआ सर्टिफ़िकेट ही दे रहा है।
• पता करें कि कुछ विज़िटर को नाम वाली चेतावनी क्यों दिखती है: www चलता है पर बिना www वाला डोमेन नहीं, या नया सबडोमेन SAN सूची में नहीं है।
• CDN के पीछे के origin सर्वर का सर्टिफ़िकेट उसका IP और SNI में साइट का नाम डालकर जाँचें।
• किसी का भेजा सर्टिफ़िकेट फ़ाइल (CA ऑर्डर या लोड बैलेंसर से एक्सपोर्ट) लगाने से पहले डिकोड करें, कहीं अपलोड किए बिना।
• दूसरे पोर्ट की सेवाएँ जाँचें — 993 पर IMAPS, 8443 पर स्टेजिंग साइट — जो ब्राउज़र वाले टूल नहीं दिखा पाते।

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

• «Cloudflare से होकर»: जाँच Cloudflare Worker पर चलती है और प्लेटफ़ॉर्म Cloudflare के एड्रेस पर सीधे कनेक्शन रोकता है। सर्टिफ़िकेट पेस्ट करें, या origin सर्वर को IP और SNI में साइट के नाम से जाँचें।
• «No TLS service answered» या «did not answer with TLS»: पोर्ट बंद है, फ़िल्टर है, या सादा टेक्स्ट बोलता है (पोर्ट 80, या 25 और 587 जैसे मेल पोर्ट जिन्हें पहले STARTTLS चाहिए)। सीधे TLS वाला पोर्ट (443, 465, 993, 995) लें या TCP पोर्ट चेकर से पोर्ट जाँचें।
• «refused the TLS handshake (alert: handshake_failure)»: सर्वर और प्रोब में कोई साझा cipher suite या प्रोटोकॉल वर्ज़न नहीं, या सर्वर क्लाइंट सर्टिफ़िकेट माँगता है। वह कौन-से वर्ज़न मानता है, यह TLS कॉन्फ़िगरेशन चेकर से देखें।
• ग़लत सर्टिफ़िकेट लौटता है: SNI सर्वर की किसी साइट से मेल नहीं खाया, इसलिए उसने डिफ़ॉल्ट सर्टिफ़िकेट दिया। होस्टनेम की स्पेलिंग जाँचें या Server name (SNI) भरें।
• पेस्ट करने पर «कोई सर्टिफ़िकेट नहीं मिला»: BEGIN और END वाली लाइनों समेत पूरा ब्लॉक कॉपी करें। बाइनरी .cer या .der फ़ाइल को पहले PEM (Base64 टेक्स्ट) में बदलना होगा।

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

तकनीकी नोट्स

सर्टिफ़िकेट RFC 5280 प्रोफ़ाइल वाले X.509 v3 होते हैं: वैधता notBefore से notAfter तक, नाम subjectAltName एक्सटेंशन में, और keyUsage, extendedKeyUsage, authorityInfoAccess (OCSP और CA issuers) व CRL distribution points बताते हैं कि सर्टिफ़िकेट किस काम का है और उसकी स्थिति कहाँ प्रकाशित होती है। पेज अपने ASN.1 रीडर से DER बाइट डिकोड करके ये फ़ील्ड जैसी लिखी हैं वैसी दिखाता है।

होस्टनेम का मिलान RFC 9525 (जिसने RFC 6125 की जगह ली) और ब्राउज़रों के नियम से होता है: SAN के DNS नाम case-insensitive मिलते हैं, wildcard सिर्फ़ पूरे बाएँ लेबल के रूप में और एक ही लेवल के लिए माना जाता है, IP एड्रेस को IP SAN में होना चाहिए, और Common Name तभी देखा जाता है जब सर्टिफ़िकेट में कोई SAN न हो।

लाइव जाँच में Mutqan सर्वर सीधे TCP सॉकेट पर अपना ClientHello भेजता है। TLS 1.2 में Certificate मैसेज खुला आता है; TLS 1.3 (RFC 8446) में वह एन्क्रिप्टेड होता है, इसलिए सर्वर अपना पेश किया X25519 या P-256 key exchange पूरा करके हैंडशेक keys बनाता है और उसे डिक्रिप्ट करता है। फिर हैंडशेक अधूरा छोड़ दिया जाता है — ClientHello के सिवा कुछ नहीं भेजा जाता।

फ़िंगरप्रिंट DER एन्कोडिंग के SHA-256 और SHA-1 डाइजेस्ट हैं, उसी कोलन वाले रूप में जैसा ब्राउज़र दिखाते हैं, ताकि आप ब्राउज़र या मॉनिटरिंग सिस्टम से मिला सकें।

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

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

जिन होस्ट के नाम Cloudflare नेटवर्क पर रिज़ॉल्व होते हैं — और ऐसी वेबसाइटें बहुत हैं — उन्हें लाइव बिल्कुल नहीं जाँचा जा सकता, क्योंकि प्लेटफ़ॉर्म उन एड्रेस पर सीधे सॉकेट नहीं खोलने देता।

न root store, न revocation जाँच: पेज कभी नहीं कहता कि सर्टिफ़िकेट भरोसेमंद है, और OCSP या CRL से रद्द होना नहीं दिखता। Certificate Transparency लॉग नहीं पूछे जाते; सिर्फ़ सर्टिफ़िकेट में embedded SCT की गिनती दिखती है।

हैंडशेक प्रोब की अपनी पेशकश से पढ़ा जाता है (AES-GCM के साथ TLS 1.3, या TLS 1.2 और उससे नीचे), इसलिए सिर्फ़ दूसरी suites मानने वाला सर्वर इसे ठुकरा सकता है, जबकि ब्राउज़र जुड़ जाते हैं।

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

पेस्ट किया सर्टिफ़िकेट आपके ब्राउज़र में डिकोड होता है और वहीं रहता है। लाइव जाँच में आपका दिया होस्ट, पोर्ट और server name Mutqan सर्वर तक जाता है, जो नाम रिज़ॉल्व करके उससे एक कनेक्शन खोलता है; टारगेट या नतीजे के बारे में कुछ भी स्टोर नहीं होता। सर्टिफ़िकेट सार्वजनिक डेटा है, पर 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 9525: Service Identity in TLSIETF · 2023क्लाइंट कैसे जाँचता है कि सर्टिफ़िकेट उसी सर्वर का नाम रखता है जिससे वह जुड़ना चाहता था: subjectAltName में DNS नाम, सिर्फ़ एक लेवल का wildcard, और Common Name पर वापसी नहीं। RFC 6125 की जगह लेता है।
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3IETF · 2018TLS 1.3 हैंडशेक और रिकॉर्ड प्रोटोकॉल जो HTTPS ट्रैफ़िक की रक्षा करते हैं।