SSL त्रुटियाँ: ये क्या हैं और इन्हें कैसे ठीक करें

SSL एरर वह होता है जो ब्राउज़र तब दिखाता है जब वह किसी वेबसाइट से भरोसेमंद एन्क्रिप्टेड कनेक्शन नहीं खोल पाता। आपके द्वारा माँगे गए पेज के बजाय आपको एक चेतावनी स्क्रीन और छोटे बड़े अक्षरों में एक कोड दिखाई देता है, जैसे NET::ERR_CERT_AUTHORITY_INVALID या SSL_ERROR_NO_CYPHER_OVERLAP।

वह कोड ही उपयोगी हिस्सा है, और ज़्यादातर गाइड इसे नज़रअंदाज़ कर देती हैं। “SSL एरर” कोई तकनीकी शब्द नहीं है, और कोई मानक इसे परिभाषित नहीं करता। यह अलग-अलग तरह की विफलताओं के एक पूरे समूह का सामान्य नाम है, यही कारण है कि कैश साफ़ करने जैसी सामान्य सलाह कुछ मामलों में काम करती है और बाकी के लिए बिलकुल बेकार साबित होती है।

SSL एरर वास्तव में क्या है

जब आप https:// से शुरू होने वाला कोई एड्रेस लोड करते हैं, तो आपका ब्राउज़र और सर्वर, किसी भी पेज सामग्री को स्थानांतरित करने से पहले TLS हैंडशेक नाम की एक छोटी सी बातचीत करते हैं। यह हैंडशेक एक प्रोटोकॉल वर्शन और एन्क्रिप्शन एल्गोरिथम के सेट पर सहमति बनाता है, और सर्वर एक सर्टिफिकेट के माध्यम से अपनी पहचान साबित करता है। यदि इसमें से कोई भी हिस्सा विफल होता है, तो ब्राउज़र आगे बढ़ने से इनकार कर देता है और पेज के बजाय एक एरर दिखाता है।

यहाँ SSL और TLS को अलग समझना ज़रूरी है, क्योंकि नामकरण से वाकई भ्रम होता है। SSL मूल प्रोटोकॉल है, और इसका हर वर्शन वर्षों से डिप्रिकेटेड है। आपका ब्राउज़र वास्तव में जो बोलता है वह TLS है। “SSL” शब्द उत्पाद नामों, कॉन्फिगरेशन निर्देशों, और एरर कोड्स में बचा हुआ है, इसीलिए आप इसे अब भी हर जगह देखते हैं। जब कोई पेज या ब्राउज़र SSL कहता है, तो उसका लगभग हमेशा मतलब TLS होता है।

ट्रबलशूटिंग के लिए यह महत्वपूर्ण है क्योंकि SSL एरर की लोकप्रिय परिभाषा बहुत सीमित है। आप अक्सर पढ़ेंगे कि SSL एरर का मतलब है कि ब्राउज़र साइट के सर्टिफिकेट को सत्यापित नहीं कर सका। यह इन एरर्स के एक समूह के लिए सच है और बाकी के लिए झूठ। HTTPS पोर्ट पर प्लेन अनएन्क्रिप्टेड टेक्स्ट के साथ जवाब देने वाला सर्वर एक SSL एरर उत्पन्न करता है और कभी कोई सर्टिफिकेट भेजता ही नहीं। दो मशीनें जो किसी सिफर सूट पर सहमत नहीं हो पाती हैं, वे सर्टिफिकेट देखे जाने से पहले ही एक एरर उत्पन्न करती हैं। जब सर्टिफिकेट कभी समस्या ही नहीं थी, तब सर्टिफिकेट से शुरुआत करना ही सबसे सामान्य कारण है जिसकी वजह से लोग पाँच मिनट के फिक्स पर घंटों बर्बाद करते हैं।

कनेक्शन की कौन-सी अवस्था विफल हुई

हर HTTPS कनेक्शन एक ही क्रम से गुज़रता है, और SSL एरर बस वह बिंदु है जहाँ वह क्रम रुक गया। कौन-सी अवस्था विफल हुई यह जानते ही कारण तुरंत सीमित हो जाता है, क्योंकि हर अवस्था में स्पष्टीकरणों का पूरी तरह अलग सेट होता है।

1. कनेक्शन TLS में कभी बदला ही नहीं। आपके ब्राउज़र ने कनेक्शन खोला और जो जवाब मिला वह TLS नहीं था, या दूसरे सिरे ने हैंडशेक पूरा होने से पहले कनेक्शन बंद कर दिया। इसमें किसी सर्टिफिकेट का कोई हाथ नहीं है, और किसी सर्टिफिकेट को बदलने की ज़रूरत नहीं है।
2. हैंडशेक बातचीत के दौरान विफल हो गया। दोनों पक्ष TLS बोल रहे थे लेकिन किसी प्रोटोकॉल वर्शन, सिफर सूट, या किस साइट का अनुरोध किया जा रहा था, इस पर सहमत नहीं हो सके। हैंडशेक सर्टिफिकेट के वैलिडेट होने से पहले रुक जाता है, और अक्सर उसे भेजे जाने से भी पहले।
3. सर्टिफिकेट प्राप्त हुआ और रिजेक्ट कर दिया गया। यह वह समूह है जिसका मतलब लोग “SSL एरर” कहते समय समझते हैं। एक्सपायरी, होस्टनेम कवरेज, ट्रस्ट की चेन, रिवोकेशन और सिग्नेचर स्ट्रेंथ – ये सब यहीं आते हैं।
4. हैंडशेक सफल हुआ और उसके बाद कुछ विफल हो गया। एन्क्रिप्टेड कनेक्शन सही तरीके से स्थापित हो गया, फिर बाद की कोई लेयर टूट गई। इस बिंदु तक सर्टिफिकेट अच्छा साबित हो चुका है, इसलिए उसे बदलने से कुछ नहीं बदलता।

आपको यह अंदाज़ा लगाने की ज़रूरत नहीं है कि आप किस अवस्था में हैं। एरर कोड आपको बता देता है, और अगला भाग हर कोड को उसकी अवस्था से जोड़ता है।

अपना एरर खोजें

चेतावनी संदेश के नीचे छपा हुआ कोड पढ़ें। Chrome और Edge में यह “Your connection is not private” के नीचे छोटे बड़े अक्षरों में बैठा होता है। Firefox में आपको चेतावनी पेज पर एडवांस्ड डिटेल्स खोलने की ज़रूरत हो सकती है। फिर उसे नीचे खोजें।

अवस्था 1: कनेक्शन TLS में कभी बदला ही नहीं

• SSL_ERROR_RX_RECORD_TOO_LONG Firefox में यह दिखाता है कि सर्वर ने HTTPS अनुरोध का जवाब ऐसी चीज़ से दिया जो TLS नहीं है, लगभग हमेशा पोर्ट 443 पर सर्व किया गया प्लेन HTTP। यह एक सर्वर कॉन्फिगरेशन समस्या है।
• PR_END_OF_FILE_ERROR Firefox में यह दिखाता है कि दूसरे सिरे ने हैंडशेक पूरा होने से पहले कनेक्शन बंद कर दिया। कारण अक्सर आपके और सर्वर के बीच में होता है, न कि किसी एक सिरे पर।

अवस्था 2: हैंडशेक बातचीत के दौरान विफल हो गया

• ERR_SSL_PROTOCOL_ERROR Chrome का सामान्य कोड है उस हैंडशेक के लिए जो किसी कारण से विफल हुआ जिसे वह ठीक से पहचान नहीं सका। यदि आपका कोड यही है, तो यहाँ से शुरू करें, क्योंकि पहला काम इसे और सीमित करना है।
• SSL_ERROR_NO_CYPHER_OVERLAP Firefox का समकक्ष है, और उतना ही व्यापक: यह किसी भी घातक हैंडशेक विफलता के लिए दिखाई देता है जिसकी रिपोर्ट सर्वर करता है, सर्वर का असली कारण जो भी रहा हो।
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH इस समान वर्ग की विफलता के लिए Chrome का कोड है, जो बातचीत की स्थितियों की एक छोटी और विशिष्ट सूची के लिए उठाया जाता है।
• ERR_SSL_UNRECOGNIZED_NAME_ALERT का मतलब है कि सर्वर ने जानबूझकर हैंडशेक समाप्त कर दिया क्योंकि अनुरोधित होस्टनेम उस पर कॉन्फिगर की गई किसी भी साइट से मेल नहीं खाता। कोई सर्टिफिकेट भेजा नहीं जाता, इसलिए दोष सर्टिफिकेट का नहीं है।
• ERR_BAD_SSL_CLIENT_AUTH_CERT यहाँ बताई गई हर दूसरी एरर के विपरीत दिशा में चलता है: साइट ने आपके ब्राउज़र से एक सर्टिफिकेट माँगा और उसे रिजेक्ट कर दिया जो उसे मिला, या कोई मिला ही नहीं। यह वाकई आपकी मशीन पर ठीक किया जाता है।
• Cloudflare एरर 525 यात्रा के अलग हिस्से पर हैंडशेक विफलता है: Cloudflare और उसके पीछे स्थित मूल सर्वर के बीच, न कि आपके ब्राउज़र और Cloudflare के बीच। विज़िटर्स इस पर कुछ नहीं कर सकते।

अवस्था 3: सर्टिफिकेट प्राप्त हुआ और रिजेक्ट कर दिया गया

Your connection is not private इस पूरे समूह के लिए Chrome की चेतावनी स्क्रीन है, अपने आप में कोई कारण नहीं, इसलिए यदि आपके पास सिर्फ इतना ही है, तो पहले इसके नीचे का कोड पढ़ें।

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

• NET::ERR_CERT_AUTHORITY_INVALID Chrome और Edge में।
• SEC_ERROR_UNKNOWN_ISSUER Firefox में, अलग नाम के तहत वही स्थिति।
• एक एक्सपायर हुआ इंटरमीडिएट सर्टिफिकेट, जहाँ चेन मौजूद है लेकिन आपके ऊपर का एक लिंक समय समाप्त हो गया है।
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, जहाँ कोई चेन नहीं है क्योंकि सर्टिफिकेट ने खुद को साइन किया।

तारीखें या नाम मेल नहीं खाते। सर्टिफिकेट भरोसेमंद है लेकिन यह इस पल या इस होस्टनेम पर लागू नहीं होता।

• NET::ERR_CERT_DATE_INVALID, जहाँ सर्टिफिकेट एक्सपायर हो गया है या अभी वैध नहीं है। यह जानना ज़रूरी है कि आपके अपने डिवाइस पर गलत क्लॉक भी यह पैदा करती है।
• NET::ERR_CERT_COMMON_NAME_INVALID, जहाँ होस्टनेम सर्टिफिकेट में सूचीबद्ध नहीं है।
• DLG_FLAGS_SEC_CERT_CN_INVALID, वही होस्टनेम समस्या जिसकी रिपोर्ट पुराने Windows वेब स्टैक पर बने सॉफ्टवेयर द्वारा की जाती है, मुख्यतः Edge में Internet Explorer मोड और लाइन-ऑफ-बिजनेस एप्लिकेशन।

सर्टिफिकेट भरोसेमंद और वर्तमान है लेकिन किसी अन्य कारण से अनुमति नहीं है।

• NET::ERR_CERT_REVOKED, जहाँ सर्टिफिकेट अथॉरिटी ने इसे इसकी एक्सपायरी तारीख से पहले रद्द कर दिया।
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, जहाँ सर्टिफिकेट जारी होने के पर्याप्त सार्वजनिक सबूत के साथ नहीं पहुँचा।
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, जहाँ चेन में कोई चीज़ SHA-1 से साइन की गई है। वर्तमान Chrome एक ही सर्टिफिकेट को अलग कोड के तहत रिपोर्ट कर सकता है, लेकिन स्थिति और फिक्स अपरिवर्तित हैं।
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, कनेक्शन में कोई दोष नहीं बल्कि Firefox के अपने सर्टिफिकेट स्टोर के अंदर एक टकराव।
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, जो ब्राउज़र में बने हुए डोमेन के बहुत छोटे सेट पर लागू होता है, इसलिए एक सामान्य वेबसाइट इसे उत्पन्न नहीं कर सकती।

सर्टिफिकेट फ़ाइल ही गलत है। ये दो सर्वर पर पाई जाती हैं, ब्राउज़र में नहीं, और ये आमतौर पर साइट को HTTPS सर्व करने से पूरी तरह रोक देती हैं।

• ERR_SSL_SERVER_CERT_BAD_FORMAT, जहाँ ब्राउज़र सर्वर द्वारा भेजे गए सर्टिफिकेट को डीकोड नहीं कर सका।
• एक मॉडुलस मिसमैच, जहाँ इंस्टॉल किया गया सर्टिफिकेट इंस्टॉल की गई प्राइवेट key का नहीं है।

अवस्था 4: हैंडशेक सफल हुआ और उसके बाद कुछ विफल हो गया

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

• ERR_SSL_BAD_RECORD_MAC_ALERT का मतलब है कि सर्वर को एन्क्रिप्टेड डेटा मिला जिसे वह सत्यापित नहीं कर सका, जो हैंडशेक के बाद सेशन keys के तहत होता है। पथ में कुछ ट्रैफिक को भ्रष्ट या फिर से लिख रहा है।
• ERR_QUIC_PROTOCOL_ERROR QUIC की एक विफलता है, जो HTTP/3 के नीचे का ट्रांसपोर्ट है। यह सर्टिफिकेट समस्या नहीं है, और सामान्य कारण एक फायरवॉल या VPN है जो UDP को फिल्टर कर रहा है।
• ERR_SPDY_PROTOCOL_ERROR HTTP/2 लेयर पर एक विफलता है, जो पूर्ण हुए TLS हैंडशेक के ऊपर बैठती है।
• मिक्स्ड कंटेंट अलग ही मामला है: पेज HTTPS पर पूरी तरह ठीक से लोड हुआ, फिर प्लेन HTTP पर एक रिसोर्स माँगा। यह कोई एरर पेज नहीं दिखाता, बस एक डाउनग्रेड किया गया पैडलॉक और गायब स्क्रिप्ट या इमेज दिखाता है।

डिवाइस के नाम पर रखी गई एरर, किसी अवस्था के बजाय

दो प्लेटफॉर्म अपनी खुद की इतनी विशेषताएँ उत्पन्न करते हैं कि उन्हें अलग से देखना उपयोगी है, क्योंकि वही अंतर्निहित स्थिति उनपर अलग तरह से व्यवहार करती है।

• iPhone और iPad पर SSL एरर, जिसमें संदेश “An SSL error has occurred and a secure connection to the server cannot be made” शामिल है। तारीख और समय की सेटिंग सबसे पहले जाँची जाने वाली चीज़ है।
• Android पर SSL कनेक्शन एरर, जहाँ Chrome और अन्य ऐप्स अलग-अलग ट्रस्ट स्टोर से सलाह लेते हैं, और एक गायब इंटरमीडिएट सर्टिफिकेट डेस्कटॉप की तुलना में ज़्यादा परेशानी पैदा करता है।

वे कोड जो अब दिखाई नहीं देते

तीन कोड अभी भी बड़े पैमाने पर लिखे जाते हैं लेकिन उन ब्राउज़रों से हटाए जा चुके हैं जो उन्हें उत्पन्न करते थे, इसलिए यदि आप उनमें से किसी एक के बारे में सलाह पढ़ रहे हैं, तो उसकी तारीख जाँच लें। इनमें से दो के पीछे की स्थितियाँ अभी भी अलग नामों के तहत मौजूद हैं।

• NET::ERR_CERT_SYMANTEC_LEGACY को Chrome 136 में हटा दिया गया था, जो अप्रैल 2025 में रिलीज़ हुआ।
• ERR_SSL_VERSION_INTERFERENCE को 2019 में Chrome 76 में हटा दिया गया था, हालाँकि जिस हस्तक्षेप का यह वर्णन करता था वह अभी भी होता है और अब अलग तरीके से सामने आता है।
• ERR_SPDY_PROTOCOL_ERROR का नाम बदलकर Chrome 77 में ERR_HTTP2_PROTOCOL_ERROR कर दिया गया, 2019 में ही। जिस विफलता का यह वर्णन करता है वह अभी भी मौजूद है, इसीलिए इसे ऊपर अवस्था चार के तहत सूचीबद्ध किया गया है।

यदि आप साइट पर विज़िट कर रहे हैं

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

• अपनी क्लॉक जाँचें। सर्टिफिकेट वैलिडेशन सर्टिफिकेट की तारीखों की तुलना आपके डिवाइस के अपने समय से करता है। महीनों या वर्षों से गलत क्लॉक हर सर्टिफिकेट को अमान्य बना देती है, और यह विज़िटर-साइड का सबसे सामान्य कारण है।
• दूसरा नेटवर्क आज़माएँ। Wi-Fi से मोबाइल डेटा पर या इसके विपरीत बदलना, आपको सेकंडों में बता देता है कि नेटवर्क पर कुछ ट्रैफिक को इंटरसेप्ट कर रहा है या नहीं। सार्वजनिक और होटल Wi-Fi इसके अक्सर दोषी होते हैं।
• HTTPS स्कैनिंग को अस्थायी रूप से बंद करें। एंटीवायरस उत्पाद और कॉर्पोरेट प्रॉक्सी अपने ही सर्टिफिकेट को प्रतिस्थापित करके एन्क्रिप्टेड ट्रैफिक की जाँच करते हैं। जब वे इसे बुरी तरह करते हैं, तो आपको उन साइटों पर SSL एरर मिलती है जो अन्यत्र ठीक काम करती हैं।
• एक प्राइवेट विंडो और दूसरा ब्राउज़र आज़माएँ। यदि एरर एक ब्राउज़र में दिखाई देती है और दूसरे में नहीं, तो कारण सामान्यतः स्थानीय होता है, किसी एक्सटेंशन में या स्टोर की गई डेटा में। यदि यह सभी में दिखाई देती है, तो यह साइट की समस्या है।

यदि उससे कुछ भी मदद नहीं करता, तो समस्या सर्वर पर है और स्पष्ट जवाब यह है कि आप इसे ठीक नहीं कर सकते। यह पूरी तरह Cloudflare एरर 525 पर लागू होता है, जहाँ विफलता उस कनेक्शन पर होती है जिसका आपका ब्राउज़र हिस्सा ही नहीं है।

ब्राउज़र ज़्यादातर सर्टिफिकेट चेतावनियों को पार करने का एक तरीका ज़रूर देते हैं, और यह स्पष्ट रहना उपयोगी है कि इसकी क़ीमत क्या है। आगे बढ़ने का मतलब है ब्राउज़र को उस कनेक्शन को स्वीकार करने के लिए कहना जिसकी पहचान वह सत्यापित नहीं कर सका, जिसका मतलब है कि आपको यह भरोसा नहीं है कि आप उसी साइट से बात कर रहे हैं जो आपने टाइप की, न कि बीच में मौजूद किसी और चीज़ से। यह एक ऐसे टेस्ट सर्वर पर स्वीकार्य लेन-देन है जिसे आप नियंत्रित करते हैं। यह किसी भी ऐसी चीज़ पर स्वीकार्य नहीं है जहाँ आप पासवर्ड या पेमेंट डिटेल डालेंगे। कुछ एरर आगे बढ़ने का कोई रास्ता ही नहीं देती, और यह जानबूझकर किया गया है, कोई गड़बड़ी नहीं।

यदि आप वेबसाइट चलाते हैं

कुछ भी बदलने से पहले निदान करें। जो सर्टिफिकेट कभी समस्या ही नहीं था उसे फिर से इंस्टॉल करना, एक घंटे के काम को एक पूरी दोपहर में बदलने का सामान्य तरीका है।

एक बाहरी जाँच से शुरू करें

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

आप कमांड लाइन से भी यही देख सकते हैं। यह हर वह सर्टिफिकेट प्रिंट करता है जो सर्वर पेश करता है, उसी क्रम में जिसमें वह उन्हें पेश करता है:

openssl s_client -connect example.com:443 -servername example.com -showcerts

उस आउटपुट में सर्टिफिकेट सूची पढ़ें, नीचे की Verify return code लाइन नहीं। वह लाइन दिखने से कहीं कम जानकारीपूर्ण है: यह केवल चेन पर OpenSSL के फैसले को रिपोर्ट करती है, यह होस्टनेम को नज़रअंदाज़ करती है जब तक आप स्पष्ट रूप से उस जाँच के लिए न कहें, और यह 0 (ok) प्रिंट करती है भले ही सर्वर ने कोई सर्टिफिकेट भेजा ही न हो क्योंकि हैंडशेक बीच में रोक दिया गया था। यदि आउटपुट subject= लाइन दिखाने के बजाय no peer certificate available कहता है, तो कुछ भी सत्यापित नहीं हुआ और विफलता उससे पहले हुई।

तारीखें और होस्टनेम जाँचें

यह दोनों सर्टिफिकेट रिजेक्शन के एक बड़े हिस्से का कारण बनते हैं। सर्वर जो सर्टिफिकेट सर्व कर रहा है उसकी वैलिडिटी विंडो पढ़ने के लिए:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

ब्राउज़र होस्टनेम को subjectAltName एक्सटेंशन के साथ मिलाते हैं और Common Name को पूरी तरह नज़रअंदाज़ कर देते हैं, इसलिए स्थानीय सर्टिफिकेट फ़ाइल पर जाँचने वाला फ़ील्ड यही है:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

OpenSSL से वही होस्टनेम जाँच लागू करवाने के लिए जो एक ब्राउज़र लागू करता है, एक साफ़ परिणाम को यह कवर करने का अनुमान लगाने के बजाय फ्लैग जोड़ें:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

macOS पर इन कमांड्स पर ध्यान देना ज़रूरी है। macOS के साथ आने वाला openssl, LibreSSL है, और यह -verify_hostname को साफ़ मना कर देता है और कुछ वाकई टूटी हुई चेन पर स्वस्थ परिणाम रिपोर्ट करता है। Homebrew के माध्यम से OpenSSL इंस्टॉल करें, फिर openssl version फिर से चलाकर पुष्टि करें कि आप वास्तव में किस बाइनरी को कॉल कर रहे हैं। यदि यह अभी भी LibreSSL रिपोर्ट करता है, तो आपका PATH पहले सिस्टम कॉपी को खोज रहा है, इसलिए /opt/homebrew/bin/openssl को उसके पूर्ण पथ से कॉल करें।

फिर फिक्स करें और सत्यापित करें

क्या बदलना है यह अवस्था के अनुसार तय होता है, और ऊपर लिंक की गई व्यक्तिगत गाइड्स प्लेटफॉर्म-विशिष्ट स्टेप्स ले जाती हैं। तीन फिक्स ज़्यादातर मामलों को कवर करते हैं:

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

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

SSL एरर को कैसे रोकें

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

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

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