वेबसाइटले गलत प्रमाणपत्र देखाउँदै छ? स्रोता खोज्नुहोस्

वेब होस्टमा 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 मा टाइपिङ त्रुटि भएको नामित भर्चुअल होस्टले ठ्याक्कै यही लक्षण उत्पन्न गर्छ, र सबै कुरा पक्रने होस्ट पहिले लोड गर्ने दोस्रो कन्फिगरेसन फाइलले पनि त्यही गर्छ। दुवै त्यो लेआउट सूचीमा देखिन्छन्।

दाबी गरिएको हरेक बाटोमा मर्मत प्रमाणित गर्नुहोस्

स्वीकृत परिवर्तनपछि प्रत्येक ठेगाना परिवारका लागि होस्टनाम-विशिष्ट जाँच दोहोर्याउनुहोस् र बाइपास झन्डाको सट्टा ब्राउजरको सामान्य प्रमाणीकरणसँग अन्त्य गर्नुहोस्। साझा स्रोता सेटिङमा छुनुअघि छुट्टै प्रशासनिक बाटो जोगाउनुहोस्, किनकि त्यहाँको गल्तीले त्यसलाई पूर्ववत् गर्न प्रयोग गर्ने पहुँच हटाउँछ। त्यसपछि लेख्नुहोस् कुन स्रोताले जवाफ दियो, कुन भर्चुअल होस्ट मिल्यो र पहिले तथा पछि कुन प्रमाणपत्र दिइयो।

प्याकेज हटाउँदा लेआउट परिवर्तन हुन सक्छ र मूल अमेल व्याख्याबिना रहन सक्छ, त्यसैले त्यो रेकर्ड मर्मतभन्दा लामो टिक्छ।

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