वेबसाइट गलत प्रमाणपत्र दिखा रही है? श्रोता को खोजें

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

जब आप मामला तय करने वाले तथ्य जुटाते हैं, तब कुछ भी पुनः आरंभ, अनइंस्टॉल या अधिलिखित नहीं होता।

वह प्रमाणपत्र पढ़ें जो ब्राउज़र को वास्तव में मिला

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

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

openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltName

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

उस पोर्ट से जुड़ी प्रक्रिया की पहचान करें

जिस होस्ट को कनेक्शन प्राप्त करना चाहिए, उस पर श्रोताओं की सूची बनाएँ और बाइंड पता, पता परिवार और प्रक्रिया का स्वामी लिखें। लूपबैक पते से जुड़ी सेवा सभी इंटरफ़ेस से जुड़ी सेवा जैसी नहीं है, और कंटेनर प्रकाशन सार्वजनिक श्रोता को पूरी तरह कहीं और रख सकता है।

sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'

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

फ़ाइल से पहले वर्चुअल होस्ट का मिलान करें

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

sudo apachectl -S

Apache के SSL संबंधी सामान्य प्रश्न बताते हैं कि सर्वर नाम संकेत प्रमाणपत्र कैसे चुनता है। HTTP का Host हेडर हैंडशेक के बाद आता है और पहले प्रस्तुत किए जा चुके को पीछे जाकर नहीं बदल सकता, इसलिए बेमेल या अनुपस्थित नाम डिफ़ॉल्ट होस्ट पर लौट जाता है।

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

हर दावा किए गए मार्ग पर मरम्मत सत्यापित करें

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

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

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