योग्य VPN पासवर्ड गहाळ प्रमाणपत्राची जागा घेऊ शकत नाही

क्रेडेन्शियल्स बरोबर आहेत, प्रोफाइल स्वच्छपणे आयात होते, आणि प्रमाणीकरण पूर्ण होण्यापूर्वीच कनेक्शन अयशस्वी होते। Windows वर संदेश EAP पद्धतीसाठी न सापडलेल्या प्रमाणपत्राबद्दल त्रुटी 798 असू शकतो। OpenVPN वर क्लायंट लॉग सर्व्हरला कधीही समाधान देणारा नसलेला TLS हँडशेक दाखवतो। दोन्ही एकाच गहाळ वस्तूचे वर्णन करतात: क्लायंटने सादर करायचे असलेले क्लायंट प्रमाणपत्र।

पासवर्ड रहस्याचे ज्ञान सिद्ध करतो; प्रमाणपत्र कीच्या ताब्याचे सिद्ध करते, आणि एक दुसऱ्याची जागा घेत नाही।

पासवर्ड कधीही समस्या नव्हता

त्रुटी 798 प्रमाणपत्र शोधण्यातील अपयश आहे। क्लायंटला कॉन्फिगर केलेल्या प्रमाणीकरण पद्धतीशी जुळणारे प्रमाणपत्र मागितले गेले, त्याने आपले स्टोअर शोधले आणि वापरण्यायोग्य काहीही सापडले नाही। याचा अर्थ प्रमाणपत्र नाही, त्याच्या खाजगी कीशिवाय आहे, कालबाह्य झाले आहे, किंवा शोध पोहोचत नाही अशा ठिकाणी साठवले आहे असा असू शकतो। पासवर्ड पुन्हा प्रयत्न केल्याने यापैकी कोणतीही स्थिती बदलत नाही, म्हणूनच योग्य क्रेडेन्शियल्ससहही त्रुटी परत येते।

कृती करण्यापूर्वी संदेश वाचा। क्रेडेन्शियल नाकारणे, प्रमाणपत्र शोधण्यातील अपयश आणि TLS हँडशेक अपयश या तीन वेगळ्या निष्कर्ष आहेत, आणि त्यापैकी फक्त एक पासवर्डशी संबंधित आहे।

क्लायंट स्टोअरमध्ये काय असावे

दोन वस्तू सहभागी आहेत। क्लायंट प्रमाणपत्र VPN क्लायंट चालवणाऱ्या वापरकर्त्यासाठी त्याच्या खाजगी कीसह स्थापित असावे, आणि जारी करणारे रूट विश्वासार्ह असावे। .cer फाइलमध्ये फक्त सार्वजनिक प्रमाणपत्र असते, त्यामुळे ती एकटी काहीही प्रमाणित करू शकत नाही। Windows प्रमाणपत्र व्यवस्थापकात, क्लायंट ओळख सध्याच्या वापरकर्त्याच्या वैयक्तिक स्टोअरमध्ये असते, आणि रूट विश्वासार्ह रूट स्टोअरमध्ये असते।

ओळख मशीन स्टोअरमध्ये, किंवा फक्त रूट स्टोअरमध्ये स्थापित केल्याने वापरकर्त्याच्या वैयक्तिक स्टोअरला लक्ष्य करणारा शोध पूर्ण होत नाही। स्टोअर, खाजगी-की फ्लॅग आणि वैधता तारखा एकत्र तपासा, नंतर स्टोअर पुन्हा वाचण्यासाठी क्लायंट पुन्हा सुरू करा।

दोन उत्पादने, तेच गहाळ क्रेडेन्शियल

OpenVPN सर्व्हर डीफॉल्टनुसार क्लायंट प्रमाणपत्र मागतात। क्लायंटमध्ये auth-user-pass जोडल्यास वापरकर्तानाव आणि पासवर्ड पाठवला जातो, आणि TLS हँडशेक अजूनही प्रमाणपत्र मागतो, त्यामुळे फक्त पासवर्ड verify-client-cert require अंतर्गत कनेक्शन पूर्ण करू शकत नाही। सर्व्हरला काहीही न मागण्यासाठी सेट केले जाऊ शकते, ज्यामुळे पासवर्ड क्लायंटचे एकमेव क्रेडेन्शियल बनते आणि ही ताकदीतली खरी घट आहे। auth-user-pass-verify मागील shell स्क्रिप्ट क्रेडेन्शियल्सची पडताळणी करू शकते, आणि त्यासाठी स्क्रिप्ट अंमलबजावणी सक्षम असणे आवश्यक आहे, ज्यामुळे ते योग्य प्रमाणीकरण बॅकएंडपेक्षा अधिक धोकादायक रचना बनते।

फक्त पासवर्डवर आधारित प्रोफाइल ढकललेल्या पर्यायांवरही अवलंबून असते, जे पुन्हा ओढण्याची यंत्रणा सक्षम असण्यावर अवलंबून असतात।

तपासण्या बंद करून गहाळ प्रमाणपत्र दुरुस्त करू नका

संदेश नाहीसा व्हावा म्हणून पडताळणी सैल करण्याचा मोह होतो। त्यामुळे आपले काम करणारे नियंत्रण निघून जाते आणि आता आपला दावा सिद्ध न करणारे कनेक्शन शिल्लक राहते। गेटवेने नुकतेच आपले रूट बदलले असेल, तर प्रोफाइल संपादित करण्याऐवजी क्लायंट पॅकेज पुन्हा डाउनलोड करा, कारण जुन्या पॅकेजमध्ये मागील रूट अजूनही असू शकते। प्रोफाइल एडिटरमध्ये प्रमाणपत्र प्रमाणीकरणाचा पर्याय नसेल, तर स्थापित Windows आवृत्ती ती पद्धत दाखवत नसेल; XML हाताने संपादित करण्याऐवजी सिस्टम अपडेट करा।

प्रमाणपत्र कोणत्या स्टोअरमध्ये होते, कोणत्या वापरकर्त्याने क्लायंट चालवला आणि खाजगी की होती का हे नोंदवा। ती तीन जवळजवळ प्रत्येक प्रकरण समजावतात।

पासवर्ड ठीक होता। पद्धतीला खरोखर आवश्यक असलेले क्रेडेन्शियल दुसरीकडे होते।