फक्त पासवर्ड असलेल्या OpenVPN प्रोफाइलमध्ये कोणती CA फाइल जाते?
CA फील्ड सर्व्हरची पडताळणी करते, वापरकर्त्याची नाही. प्रोफाइल आधीच काय धरते ते पहा, चार प्रकारची सामग्री वेगळी करा आणि पुढील त्रुटी वाचा.
चार प्रश्न क्रमाने पूर्ण करा आणि CA संवाद अस्पष्ट राहत नाही. ऑपरेटरने प्रत्यक्षात कोणती सामग्री जारी केली, प्रोफाइलमध्ये आधीच काय आहे, कोणते फील्ड विचारत आहे आणि फाइल लोड झाल्यावर काय होते? ऑपरेटरच्या स्वतःच्या सूचनांमधून उत्तर देता येत नाही अशा पहिल्या प्रश्नावर थांबा, कारण त्यापुढे अंदाज लावणे हाच मार्ग सार्वजनिक CA प्रमाणपत्र अशा खाजगी कीसोबत जोडले जाण्याचा आहे जी कधीही सर्व्हर सोडायला नको होती.
क्रम महत्त्वाचा आहे: शेवटचे दोन प्रश्न कोणती सामग्री असायला हवी हे कळल्यावरच अर्थपूर्ण ठरतात.
प्रोफाइल आधीच काय धरते यापासून सुरुवात करा
प्रोफाइल टेक्स्ट एडिटरमध्ये उघडा आणि फाइल शोधण्यापूर्वी ca ब्लॉक शोधा. ऑपरेटरचा सार्वजनिक CA धरलेला इनलाइन ca ब्लॉक म्हणजे प्रोफाइल स्वयंपूर्ण आहे, आणि अजूनही CA फाइल मागणारा क्लायंट कदाचित दुसरे प्रोफाइल किंवा अपूर्ण आयात वाचत असेल. प्रोफाइलमध्ये त्याऐवजी मार्गाकडे निर्देश करणारी ca ओळ असेल, तर तो मार्ग काही एकत्रीकरणांमध्ये क्लायंटच्या कार्यरत निर्देशिकेच्या सापेक्ष आहे आणि इतरांमध्ये निरपेक्ष. काहीही बदलण्यापूर्वी तुमच्याकडे कोणता प्रकार आहे ते नोंदवा.
ca /absolute/path/operator-ca.crt auth-user-pass remote-cert-tls server
प्रोफाइल ज्या फाइलींचा संदर्भ देते त्यासाठी दिलेले पॅकेज तपासा: एक CA प्रमाणपत्र, कधीकधी स्वतंत्र क्लायंट प्रमाणपत्र आणि की, आणि कदाचित tls-auth किंवा tls-crypt फाइल. चार फाइलींचा संदर्भ देणारे प्रोफाइल दोनसह आले तर अपूर्ण आहे, आणि फील्डकडे निर्देश करण्याच्या कोणत्याही प्रमाणात ते सुधारत नाही. योगायोगाने तुमच्याकडे असलेले प्रमाणपत्र बदलण्याऐवजी ऑपरेटरकडे गहाळ भाग मागा.
चार प्रकारची सामग्री वेगळी करा
CA प्रमाणपत्र ही सार्वजनिक सामग्री आहे जी सर्व्हरची ओळख पडताळण्यासाठी वापरली जाते. क्लायंट प्रमाणपत्र वापरकर्त्याची किंवा उपकरणाची ओळख सर्व्हरसमोर करते. खाजगी की ही त्या क्लायंट प्रमाणपत्राची गुप्त अर्धी आहे, आणि ती कधीही CAची स्वाक्षरी की किंवा सर्व्हर की नसावी. tls-auth किंवा tls-crypt सामग्री हे नियंत्रण चॅनेलचे रक्षण करणारे वेगळे सामायिक रहस्य आहे. हे चारही अदलाबदल करण्यायोग्य नाहीत, आणि CA फील्ड क्लायंट प्रमाणपत्राकडे वळवल्यास विश्वासाच्या समस्येसारखी दिसणारी पडताळणी अयशस्वी होते.
फक्त पासवर्डने प्रमाणीकरण चारपैकी कोणती गोष्ट तुम्हाला हवी आहे ते बदलते, त्यांचा अर्थ नाही. auth-user-pass आणि remote-cert-tls server सह क्लायंट अजूनही CA विरुद्ध सर्व्हरची पडताळणी करतो, म्हणून क्लायंट प्रमाणपत्र नसतानाही CA फील्ड दिसते. क्लायंट प्रमाणपत्रही आवश्यक आहे का हे ऑपरेटरचे धोरण ठरवते, आणि कोणताही संवाद तुम्हाला ते सांगू शकत नाही.
क्लायंटला विश्वास फाइलकडे निर्देश करा
CA प्रमाणपत्र फाइलच स्वतः निवडा, ती धरलेले फोल्डर नाही आणि क्लायंट ओळख धरलेले .p12 बंडल नाही. Windows वर मार्गाची रचना आणि फाइल निवडक बहुतेक मार्गदर्शकांतील Linux उदाहरणांपेक्षा वेगळे वागतात, म्हणून स्थापित क्लायंट स्वीकारतो ते वापरा आणि ती चालवणाऱ्या खात्याला फाइल वाचता येते याची खात्री करा. परवानगीची समस्या आणि गहाळ फाइल संवादात सारखी दिसते पण वेगळ्या लॉग ओळी तयार करते. निवडीनंतर क्लायंटने निवड ठेवली याची खात्री करण्यासाठी प्रोफाइल सेटिंग्ज पुन्हा उघडा.
<ca> -----BEGIN CERTIFICATE----- ...operator-provided public CA... -----END CERTIFICATE----- </ca>
क्लायंट इनलाइन ब्लॉकना समर्थन देत असेल, तर हाताने जोडलेल्या प्रोफाइलऐवजी ऑपरेटरच्या इनलाइन प्रोफाइलला प्राधान्य द्या. इनलाइन सामग्री प्रोफाइलसोबत प्रवास करते आणि पुन्हा आयात करताना टिकते, तर निरपेक्ष मार्ग प्रोफाइल दुसऱ्या मशीनवर गेल्या क्षणी तुटतो.
तीच त्रुटी नाही, पुढील त्रुटी वाचा
योग्य CA देण्याचा उद्देश त्रुटी बदलणे हा आहे, ती अदृश्य करणे नाही. CA लोड झाल्यानंतरची सर्व्हर-ओळख अयशस्वीता म्हणजे प्रमाणपत्र अपेक्षित नावाशी किंवा remote-cert-tls अपेक्षेशी जुळले नाही, हे पासवर्ड नाकारण्यापेक्षा वेगळे दुरुस्ती आहे. पासवर्ड नाकारणे म्हणजे TLS स्तर यशस्वी झाला आणि क्रेडेन्शियल चुकीचे आहे. पहिला नवीन संदेश ठेवा; तोच उपयुक्त आहे.
जोडला जातो पण कुठेही पोहोचत नाही असा क्लायंट विश्वास पूर्णपणे ओलांडून आता राउटिंग किंवा DNS प्रश्नाला तोंड देत आहे.
तो संवाद पार करण्यासाठी कधीही पडताळणी बंद करू नका. कोणतेही प्रमाणपत्र स्वीकारणाऱ्या क्लायंटला CA मागण्याचे कारण नाही, आणि तो जो बोगदा बांधतो तो ऑपरेटरचा इरादा असलेला बोगदा नाही.