कैसे जांचें कि एक वेबसाइट के पास मान्य SSL प्रमाणपत्र है

जिस सटीक होस्ट की आप पुष्टि करना चाहते हैं, उसे सुनिश्चित करें

सटीक पते से शुरू करें, अपने दिमाग में ब्रांड नाम से नहीं। www.example.com के लिए एक प्रमाणपत्र example.com के लिए एक प्रमाणपत्र के समान नहीं है, और shop.example.com जैसे उपडोमेन के पास अपना स्वयं का प्रमाणपत्र, अपना स्वयं का जारीकर्ता और अपनी स्वयं की समस्याएँ हो सकती हैं।

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

पूर्ण URL को ध्यान से टाइप करें। यदि साइट www और non-www दोनों का उपयोग करती है, तो दोनों का परीक्षण करें। यदि आप एक लॉगिन क्षेत्र या एक API होस्ट की जांच कर रहे हैं, तो उस सटीक होस्टनेम की भी पुष्टि करें, क्योंकि एक होस्ट ठीक हो सकता है जबकि दूसरा विफल हो सकता है।

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

एक त्वरित नोट: एक पृष्ठ पर सुरक्षित दिखने वाला ताला यह साबित नहीं करता कि पूरा डोमेन परिवार सुरक्षित है। यह केवल यह साबित करता है कि एक होस्ट पर एक प्रतिक्रिया ने कुछ प्रमाणपत्र प्रस्तुत किया।

सिर्फ पैडलक नहीं, प्रमाणपत्र श्रृंखला की जांच करें

ताला केवल पहला संकेत है। एक ब्राउज़र HTTPS दिखा सकता है जबकि प्रमाणपत्र श्रृंखला अधूरी, गलत क्रम में, या एक ऐसे जारीकर्ता से जुड़ी हो जिसे ब्राउज़र विश्वास नहीं करता।

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

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

व्यवहार में, एक अधूरी श्रृंखला अक्सर नवीनीकरण या सर्वर माइग्रेशन के बाद प्रकट होती है। प्रमाणपत्र स्वयं वर्तमान हो सकता है, फिर भी सर्वर द्वारा भेजी गई श्रृंखला गलत है, इसलिए उपयोगकर्ताओं को फिर भी चेतावनियाँ मिलती हैं।

यदि आपके पास पहुंच है तो ब्राउज़र प्रमाणपत्र विवरण, एक SSL चेकर्स, या एक कमांड-लाइन टूल का उपयोग करें। एक ब्राउज़र में काम करने वाली साइट दूसरे में विफल हो सकती है यदि सर्वर एक मध्यवर्ती प्रमाणपत्र को छोड़ देता है।

एक वास्तविक दुनिया का मामला: एक CDN के पीछे एक साइट किनारे पर एक मान्य पत्ते के प्रमाणपत्र को प्रस्तुत कर सकती है लेकिन एक विरासती मूल पथ पर एक टूटी हुई श्रृंखला। आगंतुक केवल कम सामान्य मार्ग पर समस्या देखता है।

जांचें कि प्रमाणपत्र होस्टनाम से मेल खाता है

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

जांचें कि क्या SAN प्रविष्टियाँ उस सटीक डोमेन और उपडोमेन को शामिल करती हैं जिसे आपने परीक्षण किया। यदि प्रमाणपत्र example.com और www.example.com को सूचीबद्ध करता है, तो यह दोनों के लिए ठीक हो सकता है। यदि यह केवल example.com को सूचीबद्ध करता है, तो www.example.com अभी भी विफल हो सकता है।

यह मानने की गलती न करें कि वाइल्डकार्ड सब कुछ हल कर देते हैं। एक वाइल्डकार्ड जैसे *.example.com आमतौर पर एक लेबल गहरा कवर करता है, इसलिए shop.example.com कवर किया जा सकता है, जबकि api.shop.example.com नहीं है।

उपनाम एक सामान्य जाल हैं। मार्केटिंग टीम go.example.com को बढ़ावा दे सकती है, लेकिन प्रमाणपत्र केवल example.com और www.example.com को कवर करता है। पृष्ठ लोड होता है, ताले का प्रतीक एक क्षण के लिए दिखाई देता है, और फिर ब्राउज़र नाम त्रुटि फेंकता है।

यहाँ एक उपयोगी आदत है: जो उपयोगकर्ता टाइप करते हैं, जो क्या रीडायरेक्ट करता है, और प्रमाणपत्र के नाम वास्तव में क्या हैं, उन्हें मिलाना। तीन स्ट्रिंग। एक जांच।

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

समाप्ति और नवीनीकरण स्थिति की पुष्टि करें

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

प्रमाणपत्र दर्शक में वैधता विंडो को देखें। कुछ उपकरण “नहीं पहले” और “नहीं बाद” दिखाते हैं। ये दो पंक्तियाँ आपको बताती हैं कि क्या प्रमाणपत्र अब सक्रिय है और क्या नवीनीकरण पहले से ही समय पर नहीं है।

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

एक छोटा समाप्ति अवधि अपने आप में एक दोष नहीं है, लेकिन यह दांव को बढ़ा देता है। यदि एक स्वचालित नवीनीकरण कार्य एक बार विफल हो जाता है, तो साइट बहुत कम चेतावनी के साथ ठीक से अवरुद्ध हो सकती है।

जब आप एक संदिग्ध प्रमाणपत्र की जांच करते हैं, तो तारीख को ध्यान में रखें। एक प्रमाणपत्र जो 2 दिनों में समाप्त होता है, उसे महीनों बचे प्रमाणपत्र की तुलना में तेजी से ध्यान देने की आवश्यकता होती है, क्योंकि समाधान बस एक नवीनीकरण हो सकता है जो अभी तक फैल नहीं पाया है।

उन टीमों के लिए जो पहले से ही एक वेबसाइट विश्लेषण और निगरानी प्लेटफ़ॉर्म का उपयोग कर रही हैं, प्रमाणपत्र जांच को अपटाइम अलर्ट के साथ जोड़ना उपयोगकर्ताओं से पहले नवीनीकरण विफलता को पकड़ने में मदद करता है। यहाँ समयरेखा महत्वपूर्ण है, सिद्धांत नहीं।

जारीकर्ता प्राधिकरण से विश्वास मुद्दों की तलाश करें

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

जारीकर्ता की जानकारी खोलें और पुष्टि करें कि CA आधुनिक ब्राउज़रों और ऑपरेटिंग सिस्टम द्वारा मान्यता प्राप्त है। यदि जारीकर्ता अपरिचित लगता है, या प्रमाणपत्र स्व-हस्ताक्षरित था, तो ब्राउज़र विश्वास को अस्वीकार कर सकता है भले ही HTTPS पता बार में दिखाई दे।

स्व-हस्ताक्षरित प्रमाणपत्र आंतरिक उपकरणों, परीक्षण सर्वरों और निजी प्रशासनिक पृष्ठों पर सामान्य हैं। जब कोई वही सेटअप सार्वजनिक साइट पर कॉपी करता है, तो वे भ्रम का एक सामान्य स्रोत भी होते हैं।

ब्राउज़र चेतावनियों को पंक्ति दर पंक्ति पढ़ने के लायक हैं। एक चेतावनी एक अविश्वसनीय जारीकर्ता का उल्लेख कर सकती है। दूसरी एक श्रृंखला की समस्या का उल्लेख कर सकती है। तीसरी कह सकती है कि प्रमाणपत्र मेज़बान के लिए अभिप्रेत नहीं है।

वे संदेश अलग हैं। उन्हें अलग तरीके से संभालें।

यदि आप एक सार्वजनिक साइट की जांच कर रहे हैं जिसे डिफ़ॉल्ट रूप से विश्वसनीय होना चाहिए, तो एक ब्राउज़र चेतावनी का मतलब है कि विश्वास पथ कहीं टूट गया है। यह एक खराब तरीके से संभाले गए माइग्रेशन, एक खराब प्रॉक्सी कॉन्फ़िगरेशन, या गलत मध्यवर्ती पैकेज के साथ स्थापित प्रमाणपत्र के बाद हो सकता है।

विश्वसनीय प्राधिकरण का मतलब "सुरक्षित सामग्री" नहीं है, बेशक। इसका मतलब केवल यह है कि ब्राउज़र प्रमाणपत्र पथ को वैध मानता है। यह एक संकीर्ण दावा है, और यह एकमात्र दावा है जो प्रमाणपत्र कर सकता है।

पृष्ठ पर मिश्रित सामग्री के लिए परीक्षण करें

एक मान्य SSL प्रमाणपत्र उस पृष्ठ को सुरक्षित नहीं करता जो अभी भी असुरक्षित संसाधनों को लोड करता है। मिश्रित सामग्री तब होती है जब मुख्य पृष्ठ HTTPS का उपयोग करता है लेकिन चित्र, स्क्रिप्ट, फ़ॉन्ट, या फ़्रेम HTTP URLs से आते हैं।

डेवलपर टूल खोलें और पृष्ठ को रिफ्रेश करें। अवरुद्ध या अपग्रेड किए गए संसाधनों के बारे में चेतावनियों की तलाश करें। एक पृष्ठ दृश्य रूप से लोड हो सकता है जबकि एक स्क्रिप्ट चुपचाप विफल हो जाती है क्योंकि ब्राउज़र ने एक असुरक्षित फ़ाइल को अवरुद्ध कर दिया।

यह एक व्यावहारिक सुरक्षा मुद्दा है, न कि एक कॉस्मेटिक। एकल असुरक्षित स्क्रिप्ट उस सुरक्षा को कमजोर कर सकती है जो प्रमाणपत्र प्रदान करने वाला है।

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

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

मिश्रित सामग्री यह भी समझाने में मदद करती है कि उपयोगकर्ता कभी-कभी रिपोर्ट क्यों करते हैं "साइट मेरे लैपटॉप पर सुरक्षित है, लेकिन मेरे फोन पर नहीं।" प्रमाणपत्र ठीक हो सकता है; पृष्ठ संसाधन नहीं हैं।

डेस्कटॉप और मोबाइल व्यवहार की तुलना करें

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

यह अंतर महत्वपूर्ण है। एक प्रमाणपत्र श्रृंखला जो एक लैपटॉप पर क्रोम में स्वीकार्य लगती है, वह एक पुराने आईफोन पर सफारी में या एक ब्राउज़र में जो पुराने रूट प्रमाणपत्रों के साथ है, चेतावनी उत्पन्न कर सकती है।

मुख्य होस्ट और एक उपडोमेन का प्रयास करें। यदि साइट www से non-www पर रीडायरेक्ट होती है, तो रीडायरेक्ट के बाद परीक्षण दोहराएं। रीडायरेक्ट किए गए होस्ट पर विफलता अभी भी एक विफलता है।

डिवाइस जांचें भी कुकी और सत्र की अजीबताओं को प्रकट करती हैं। कभी-कभी ब्राउज़र की चेतावनी केवल लॉगिन के बाद दिखाई देती है, क्योंकि एक अलग होस्ट को कॉल किया जाता है जब उपयोगकर्ता एक सुरक्षित क्षेत्र में पहुंचता है।

यहां सरलता सबसे अच्छी है। साइट खोलें, लॉक की जांच करें, होस्टनेम की पुष्टि करें, और दोनों डिवाइसों पर प्रमाणपत्र विवरण की तुलना करें। पांच मिनट बाद में एक समर्थन टिकट बचा सकता है।

टीमें जो पहले से ही लॉन्च के बाद वेबसाइट समर्थन पर निर्भर करती हैं, आमतौर पर इस पैटर्न को अच्छी तरह जानती हैं: क्लाइंट से ब्राउज़र रिपोर्ट अक्सर डेवलपर की मशीन के परिणाम के समान नहीं होती है।

जानें कि साइट के मालिक या होस्टिंग प्रदाता के पास कब बढ़ाना है

जब प्रमाणपत्र समाप्त हो गया हो, होस्टनेम मेल नहीं खाता, श्रृंखला टूटी हुई है, या ब्राउज़र एक ट्रस्ट चेतावनी दिखाता है जिसे आप स्थानीय डिवाइस सेटिंग्स द्वारा समझा नहीं सकते। ये 'शायद बाद में' निष्कर्ष नहीं हैं।

जब आप समस्या की रिपोर्ट करें, तो सटीक होस्ट, टाइमस्टैम्प, ब्राउज़र का नाम, दृश्य त्रुटि, और प्रमाणपत्र विवरण का स्क्रीनशॉट शामिल करें। यदि संभव हो, तो SAN प्रविष्टियाँ, जारीकर्ता का नाम, और समाप्ति तिथि शामिल करें।

रिपोर्ट को ठोस रखें। कहें “shop.example.com iPhone Safari पर होस्टनाम असंगति के साथ विफल होता है” बजाय “SSL टूट गया है।” पहला वाक्य किसी को इसे ठीक करने का रास्ता देता है।

यदि आप किसी ग्राहक के लिए साइट का प्रबंधन करते हैं, तो उन्हें बताएं कि समस्या एक होस्ट पर है या कई पर। यह भेद यह तय कर सकता है कि सुधार DNS, लोड बैलेंसर, वेब सर्वर, या प्रमाणपत्र प्रदाता के साथ है या नहीं।

होस्टिंग प्रदाताओं को अक्सर तेजी से कार्रवाई करने के लिए सटीक सबूत की आवश्यकता होती है। एक अस्पष्ट शिकायत एक दिन के लिए टीमों के बीच घूम सकती है। एक सटीक शिकायत को नवीनीकरण, एक गायब मध्यवर्ती, या एक खराब तैनाती से मिनटों में मिलाया जा सकता है।

आंतरिक प्लेटफ़ॉर्म या सार्वजनिक उत्पाद पर काम कर रही टीमों के लिए, सबसे साफ़ हैंडऑफ़ वह है जिसमें होस्ट, विफलता प्रकार, और ब्राउज़र पथ शामिल हैं। यह एक प्रमाणपत्र समस्या को एक पृष्ठ समस्या से अलग करने के लिए पर्याप्त है, जो सभी को अनुमान लगाने से बचाता है।

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