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