IKEv2 प्रमाणपत्र SAN: पहचान जाँच क्यों विफल होती है

आपका प्रमाणपत्र किसी विश्वसनीय CA से श्रृंखलित है, तिथियाँ ठीक हैं, और सहकर्मी अभी भी पहचान त्रुटि के साथ चरण 1 पूरा करने से मना करता है। पहुँच और वैध हस्ताक्षर IKEv2 क्लाइंट जो जाँचता है उसका केवल आधा हिस्सा हैं। दूसरा आधा यह है कि जिस पहचान की वह अपेक्षा करता है वह प्रमाणपत्र में सही फ़ील्ड में दिखती है या नहीं, और वह अपेक्षा प्रोफ़ाइल से तय होती है, प्रमाणपत्र के फ़ाइल नाम से नहीं।

लक्षण हमेशा एक जैसा ही होता है

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

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

पहचानकर्ता का प्रकार मिलाएँ, केवल मान नहीं

dNSName SAN और iPAddress SAN भिन्न फ़ील्ड हैं जिनके भिन्न मिलान नियम हैं, इसलिए 203.0.113.10 को DNS स्ट्रिंग के रूप में रखने वाला प्रमाणपत्र उस क्लाइंट को संतुष्ट नहीं करता जो IP पहचान की अपेक्षा करता है। आधुनिक सत्यापनकर्ता सामान्य नाम को बड़े पैमाने पर नज़रअंदाज़ करते हैं, इसलिए प्रमाणपत्र विवरण में दिखने वाला मैत्रीपूर्ण लेबल यह साबित नहीं करता कि क्या मेल खाएगा। यदि समस्या निवारण के दौरान होस्टनाम को पते से बदला गया, तो जाँच करने तक मान लें कि अपेक्षित पहचान उसके साथ चली गई। प्रोफ़ाइल की स्ट्रिंग की तुलना SAN की स्ट्रिंग से अक्षर-दर-अक्षर करें, क्योंकि अंत में एक बिंदु या फालतू स्पेस भी काफ़ी है।

वाइल्डकार्ड केवल DNS की सुविधा हैं और अपने स्वयं के मिलान नियमों का पालन करते हैं, यह एक और कारण है कि IP-आधारित प्रोफ़ाइल को कभी भी उन पर निर्भर नहीं होना चाहिए।

पता लगाएँ कि प्रत्येक क्लाइंट अपेक्षा कहाँ रखता है

strongSwan में, प्रमाणपत्र से तुलना किया जाने वाला मान सहकर्मी पहचान सेटिंग से आता है: rightid पुराने कॉन्फ़िगरेशन में, या swanctl में रिमोट कनेक्शन अनुभाग के id से। इसका दस्तावेज़ Apple IKEv2 अंतरसंचालनीयता पर यहाँ उपयोगी है क्योंकि यह उन पहचान परंपराओं को स्पष्ट करता है जिनका उपयोग प्रोफ़ाइल-चालित क्लाइंट करता है, और वे परंपराएँ उस प्रकार की बेमेल को समझाती हैं जो तार पर यादृच्छिक लगती है।

Apple कॉन्फ़िगरेशन प्रोफ़ाइल में रिमोट पहचानकर्ता फ़ील्ड होता है, और वहाँ का मान ही क्लाइंट जाँचता है, कनेक्शन सेटिंग्स में सर्वर पता नहीं। Windows और उपकरण क्लाइंट में से प्रत्येक का अपना फ़ील्ड और अपना डिफ़ॉल्ट होता है, और डिफ़ॉल्ट अक्सर उस पते का अनुसरण करता है जो आपने टाइप किया। जहाँ दो फ़ील्ड असहमत हों, जिसे क्लाइंट वास्तव में पढ़ता है वही जीतता है, और वह शायद ही कभी वह होता है जिसे आपने संपादित किया।

प्रोफ़ाइल या प्रमाणपत्र की मरम्मत करें, जानबूझकर

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

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

प्रत्येक क्लाइंट प्लेटफ़ॉर्म के लिए अपेक्षित पहचान का दस्तावेज़ बनाएँ, क्योंकि जो मान एक क्लाइंट स्वचालित रूप से निकालता है, वह दूसरे पर स्पष्ट रूप से लिखना पड़ सकता है।

नवीनीकरण अनुरोध को चार तथ्य दें

अपेक्षित पहचानकर्ता और उसका प्रकार, वर्तमान प्रमाणपत्र में वास्तव में मौजूद SAN प्रविष्टियाँ, जाँच करने वाला क्लाइंट और संस्करण, और सटीक त्रुटि पाठ लिख लें। इन चार पंक्तियों से बना नवीनीकरण अनुरोध पहली बार में सही प्रमाणपत्र दिलाता है, न कि उसी परिचित फ़ाइल नाम वाला एक और प्रमाणपत्र।