Apache या संभावित रूप से किसी अन्य समान वेब होस्टिंग तकनीक को चलाने के लिए डिज़ाइन किए गए सर्वर पर SSL कॉन्फ़िगर करते समय, आपको एक त्रुटि मिल सकती है जो बताती है कि सर्वर सर्टिफिकेट में सर्वर नाम से मेल खाने वाली ID शामिल नहीं है। तकनीकी रूप से यह सिर्फ एक चेतावनी है और आप सैद्धांतिक रूप से इसके चारों ओर काम कर सकते हैं।
चीजों को फिर से सामान्य रूप से काम करने के लिए थोड़ा समस्या निवारण करना बेहतर है। एक बार जब आपका सर्वर नाम और सर्टिफिकेट मेल खा जाते हैं, तो आपको अगली बार सिस्टम अपडेट करने पर इनमें से किसी भी चरण को दोहराने की आवश्यकता नहीं होनी चाहिए। यदि एक साधारण फ़ाइल संपादन चीजों को ठीक नहीं करता है तो आपको कुछ चीजों को पुनर्जीवित करने की आवश्यकता हो सकती है, लेकिन एक बार ऐसा करने के बाद आपको फ़ाइलों को आगे कॉन्फ़िगर करने की आवश्यकता नहीं होगी।
विधि 1: httpd.conf फ़ाइल संपादित करना
फ़ाइल को देखकर शुरू करें, जो थोड़ी अलग जगह पर हो सकती है यदि आप Fedora, Red Hat या CentOS पर Apache चला रहे हैं। Debian और Ubuntu सर्वरों में यह पहले पते पर स्थित होना चाहिए। उस टेक्स्ट को देखें जो "सर्वर सर्टिफिकेट में सर्वर नाम से मेल खाने वाली ID शामिल नहीं है" चेतावनी संदेश को दर्शाता है।
आप पा सकते हैं कि यह IP पते के प्रत्येक भाग के बाद 443 या कोई अन्य नंबर फेंक रहा है लेकिन कोई अन्य SSL समस्या नहीं है। इस मामले में, हो सकता है कि आपने Apache को यह नहीं बताया हो कि किन पोर्ट्स पर सुनना है। चलाएं
और एक लाइन ढूंढें जिसमें Listen 80 लिखा हो। इसके नीचे, Listen 443 या जो भी अन्य पोर्ट नंबर आपको चाहिए, जोड़ें। एक बार जब आप फ़ाइल को सेव और बंद कर देते हैं, तो httpd प्रक्रिया को पुनरारंभ करने के लिए 
का उपयोग कर सकते हैं।
जो लोग Ubuntu या Debian सर्वर चला रहे हैं, उनके पास यह फ़ाइल नहीं हो सकती या वे इसे पूरी तरह से खाली पा सकते हैं, उन लोगों के विपरीत जो Fedora या Red Hat Enterprise Linux के कुछ संस्करणों का उपयोग कर रहे हैं। उस स्थिति में, पोर्ट्स सुनने के लिए जोड़ने के लिए आवश्यक टेक्स्ट फ़ाइल को संपादित करने के लिए
का उपयोग करें।
कई मामलों में, इससे समस्या ठीक हो जानी चाहिए। यदि नहीं, तो प्रमाणपत्र स्थिति का निरीक्षण करने के लिए आगे बढ़ने से पहले सभी प्रासंगिक नेटवर्किंग मुद्दों की जांच करें।
विधि 2: नए प्रमाणपत्र पुनर्जीवित करना
यदि आपने स्वयं-हस्ताक्षरित समाप्त हो चुके प्रमाणपत्रों के साथ काम किया है तो ये चेतावनी संदेश भी आ सकते हैं। यदि आपको उन्हें पुनर्जीवित करने की आवश्यकता है, तो कोशिश करें
और File और KeyFile चिह्नित दो लाइनों को देखें। ये आपको बताएंगे कि SSL प्रमाणपत्र बनाते समय प्रमाणपत्र कुंजी फ़ाइल का स्थान क्या है।
यदि आप आधिकारिक वर्ल्ड वाइड वेब प्रमाणपत्र प्रदान करने वाली एक पेशेवर हस्ताक्षरकर्ता फर्म के साथ काम कर रहे हैं, तो आपको अपने लाइसेंसिंग संगठन द्वारा प्रदान किए गए विशिष्ट निर्देशों का पालन करना चाहिए। अन्यथा, आपको sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout KeyFile -out File चलाना होगा, जिसमें KeyFile और File को पिछले cat कमांड से प्राप्त टेक्स्ट से बदल दें। आपको दो अलग-अलग फ़ाइलों का स्थान मिलना चाहिए, जो प्रमाणपत्रों के लिए इनपुट और आउटपुट के रूप में काम करती हैं।
यह मानते हुए कि वे पुराने थे, बस ऐसा करना त्रुटि को ठीक करने के लिए पर्याप्त होना चाहिए, लेकिन सेवा को पुनरारंभ करने से पहले यह आपको चेतावनी देना बंद कर दे, ऐसा करना पड़ सकता है।
आप वर्तमान में इंस्टॉल किए गए प्रमाणपत्रों के बारे में थोड़ा और पता लगा सकते हैं ताकि समस्या निवारण प्रक्रिया में आपकी सहायता हो सके। यह देखने के लिए कि आपके प्रमाणपत्र पर वर्तमान में कौन सा नाम है यह सुनिश्चित करने के लिए कि यह मेल खाता है, आप openssl s_client -showcerts -connect ${HOSTNAME}:443 चला सकते हैं, हालांकि आपको ब्रैकेट के बीच अपना वास्तविक होस्टनाम डालना होगा। यदि आपको किसी भिन्न पोर्ट के साथ समस्या हो रही है तो 443 अंक को बदलें।
यदि आपके पास एक ही डिवाइस पर एक ही IP पते से सेवा किए गए कई प्रमाणपत्र स्थापित हैं, तो आपको openssl s_client -showcerts -connect ${IP}:443 -servername ${HOSTNAME} चलाने की आवश्यकता होगी, जिसमें IP को अपने वास्तविक IP से बदलें और होस्टनाम भरें। एक बार फिर, आपको अपने विशिष्ट उपयोग के मामले से मेल खाने के लिए 443 को एक अलग अंक से बदलना पड़ सकता है।
ध्यान रखें कि आपको यह सुनिश्चित करना होगा कि CSR बनाते समय सही होस्टनाम को उपनाम या सामान्य नाम के रूप में निर्दिष्ट किया गया हो।
