SSTP प्रमाणपत्र मेल नहीं खाता: वह नाम जो आपके सर्वर को दिखाना चाहिए

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

प्रोफ़ाइल का नाम तय करता है कि क्या जाँचा जाएगा

SSTP, TCP 443 पर TLS चलाता है, इसलिए क्लाइंट किसी भी अन्य TLS क्लाइंट की तरह व्यवहार करता है: वह प्रोफ़ाइल से होस्टनाम लेता है, उसी नाम का अनुरोध करता है और उससे प्रमाणपत्र की तुलना करता है। प्रोफ़ाइल में IP पता लिखें तो तुलना IP पते की तुलना बन जाती है, जिसे अधिकांश सर्वर प्रमाणपत्र पूरा नहीं करते।

इसलिए ब्राउज़र परीक्षण सफल हो सकता है जबकि VPN विफल रहता है, क्योंकि ब्राउज़र ने प्रोफ़ाइल से भिन्न नाम इस्तेमाल किया। यही विभाजन तब दिखता है जब split-horizon DNS VPN होस्टनाम को आंतरिक पते पर हल करता है जबकि ब्राउज़र किसी सार्वजनिक पते तक पहुँच गया। पहले प्रोफ़ाइल को दस्तावेज़ित होस्टनाम के साथ संरेखित करें, फिर प्रमाणपत्रों की तुलना करें। इससे पहले आप जो कुछ भी बदलते हैं वह अनुमान है।

सर्वर प्रमाणपत्र में क्या होना चाहिए

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

प्रमाणपत्र को सर्वर प्रमाणीकरण उद्देश्य भी चाहिए, माइक्रोसॉफ़्ट के SSTP विनिर्देश में उल्लिखित विस्तारित कुंजी उपयोग मान, अर्थात् ऑब्जेक्ट पहचानकर्ता 1.3.6.1.5.5.7.3.1 के साथ serverAuth। कुंजी उपयोग और वैध श्रृंखला समुच्चय पूरा करते हैं। सर्वर पर मौजूद, सही नाम के लिए जारी पर केवल क्लाइंट प्रमाणीकरण के लिए बना प्रमाणपत्र भी विफल होता है।

लॉगिन विवरण से पहले श्रृंखला और घड़ी जाँचें

समय और विश्वास की विफलताएँ नाम बेमेल जैसा ही दृश्य परिणाम देते हैं, और दोनों का निदान पासवर्ड समस्या से सस्ता है। सर्वर की घड़ी और क्लाइंट की घड़ी जाँचें, फिर श्रृंखला को वैसे पढ़ें जैसे क्लाइंट देखता है:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

पहला कमांड नाम, वैधता विंडो और वे वैकल्पिक नाम छापता है जिनसे क्लाइंट तुलना करेगा। दूसरा प्रस्तुत श्रृंखला के साथ सत्यापन त्रुटियाँ बताता है, और वहीं अनुपस्थित मध्यवर्ती प्रमाणपत्र दिखता है। Windows पर समय सेवा की क्वेरी बताती है कि घड़ी सुधारी जा रही है या केवल खिसक गई है।

आंतरिक CA एक और शर्त जोड़ता है: क्लाइंट को उस CA पर भरोसा होना चाहिए। संगठनात्मक रूट को उसके स्वीकृत वितरण चैनल से स्थापित करें, प्रतिस्थापन प्रमाणपत्र देने वाले पृष्ठ से नहीं, क्योंकि वह निर्णय ही पूरा भरोसा मॉडल लघु रूप में है।

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

नाम या प्रमाणपत्र ठीक करें और फिर परीक्षण करें

तीन शर्तें मरम्मत तय करती हैं। यदि प्रोफ़ाइल का नाम गलत है, प्रोफ़ाइल सुधारें या प्रमाणपत्र में अनुपस्थित नाम जोड़ें। यदि श्रृंखला अपूर्ण है, सर्वर पर मध्यवर्ती प्रमाणपत्र स्थापित करें। यदि उद्देश्य गलत है, उसके चारों ओर पैबंद लगाने के बजाय फिर से जारी करें।

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