चार सवाल क्रम से पूरे करें और 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 माँगने का कोई कारण नहीं, और वह जो सुरंग बनाता है वह ऑपरेटर का इच्छित सुरंग नहीं है।

संबंधित लेख