वेब होस्टवर 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 मध्ये टाइपिंग त्रुटी असलेला नामांकित आभासी होस्ट नेमके हेच लक्षण निर्माण करतो, आणि सर्व काही पकडणारा होस्ट प्रथम लोड करणारी दुसरी कॉन्फिगरेशन फाइलही तसेच करते। दोन्ही त्या मांडणी यादीत दिसतात।

प्रत्येक दावा केलेल्या मार्गावर दुरुस्ती सत्यापित करा

मंजूर बदलानंतर प्रत्येक पत्ता कुटुंबासाठी होस्टनाव-विशिष्ट तपासणी पुन्हा करा आणि बायपास फ्लॅगऐवजी ब्राउझरच्या नेहमीच्या पडताळणीसह समाप्त करा। सामायिक श्रोता सेटिंग्जला स्पर्श करण्यापूर्वी वेगळा प्रशासकीय मार्ग जतन करा, कारण तेथील चूक ती पूर्ववत करण्यासाठी वापरता तो प्रवेश काढून टाकते। नंतर लिहा की कोणत्या श्रोत्याने उत्तर दिले, कोणता आभासी होस्ट जुळला आणि पूर्वी व नंतर कोणते प्रमाणपत्र दिले गेले।

पॅकेज काढल्याने मांडणी बदलू शकते आणि मूळ विसंगती स्पष्टीकरणाशिवाय राहू शकते, म्हणूनच ती नोंद दुरुस्तीपेक्षा जास्त टिकते।

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

संबंधित लेख