IKEv2 प्रमाणपत्र SAN: पहिचान जाँच किन असफल हुन्छ

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

लक्षण सधैं एउटै आकारको हुन्छ

जडान प्रोफाइल होस्टनामबाट IP ठेगानामा परिवर्तन गरिन्छ, वा DNS नाम बोकेको प्रमाणपत्रबाट केवल ठेगाना बोकेको प्रमाणपत्रमा नवीकरण गरिन्छ, रसुरुङले वार्ता गर्न छोड्छ। नेटवर्क मार्गमा केही पनि बदलिएको छैन। क्लाइन्ट सहकर्मीसम्म पुग्छ, प्रमाणपत्र प्राप्त गर्छ, र सहकर्मीको पहिचान अस्वीकार गर्छ किनभने अपेक्षा गर्न भनिएको पहिचानकर्ता यसले स्वीकार गर्ने फिल्डमा प्रतिनिधित्व गरिएको छैन। प्रतिस्थापन प्रमाणपत्र प्रायः यसले प्रतिस्थापन गर्नेभन्दा फरक टेम्प्लेटबाट आउने भएकाले नवीकरण सामान्य कारण हो।

त्यसपछि दुवै पक्षले केही उपयोगी नभएको लग गर्छन्, त्यसैले विफलता सामान्यतया प्रमाणपत्र समस्या भनी रिपोर्ट गरिन्छ। क्लाइन्ट लगले चाहेको पहिचानको नाम दिन सक्छ, र त्यो नाम नै तपाईंलाई चाहिने संकेत हो, म्याद सकिने मिति होइन।

पहिचानकर्ताको प्रकार मिलाउनुहोस्, मात्र मान होइन

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

वाइल्डकार्डहरू DNS का लागि मात्र सुविधा हुन् र आफ्नै मिलान नियमहरू पछ्याउँछन्, IP आधारित प्रोफाइलले कहिल्यै तिनीहरूमा भर पर्नु हुँदैन भन्ने अर्को कारण हो।

प्रत्येक क्लाइन्टले अपेक्षा कहाँ राख्छ पत्ता लगाउनुहोस्

strongSwan मा, प्रमाणपत्रसँग तुलना गरिने मान सहकर्मी पहिचान सेटिङबाट आउँछ: rightid क्लासिक कन्फिगरेसनमा, वा id swanctl मा रिमोट जडान खण्डको id बाट। Apple IKEv2 अन्तरसञ्चालनीयताबारे यसको कागजात यहाँ उपयोगी छ किनभने प्रोफाइल-चालित क्लाइन्टले प्रयोग गर्ने पहिचान परम्पराहरू यसले स्पष्ट पार्छ, र ती परम्पराहरूले तारमा अनियमित देखिने अमिलताको वर्ग व्याख्या गर्छन्।

Apple कन्फिगरेसन प्रोफाइलमा रिमोट पहिचानकर्ता फिल्ड हुन्छ, र त्यहाँको मान नै क्लाइन्टले जाँच्छ, जडान सेटिङमा भएको सर्भर ठेगाना होइन। Windows र उपकरण क्लाइन्टको प्रत्येकको आफ्नै फिल्ड र आफ्नै पूर्वनिर्धारित हुन्छ, र पूर्वनिर्धारित प्रायः तपाईंले टाइप गरेको ठेगाना पछ्याउँछ। दुई फिल्ड असहमत हुँदा, क्लाइन्टले वास्तवमा पढ्ने नै जित्छ, र त्यो तपाईंले सम्पादन गरेको हुनु विरलै हुन्छ।

प्रोफाइल वा प्रमाणपत्र जानाजानी मर्मत गर्नुहोस्

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

प्रमाणपत्र गलत भएमा, विशिष्ट अपेक्षित पहिचानकर्तासहित सुधारिएको प्रमाणपत्र अपरेटरसँग माग्नुहोस्। प्रोफाइल गलत भएमा, प्रोफाइल सुधार्नुहोस् र प्रमाणपत्रलाई छोड्नुहोस्। पहिचान प्रमाणीकरण बन्द गर्दा त्रुटि हराउँछ र सुरुङले तपाईंले चाहेको सहकर्मीसँग बोलिरहेको छ भन्ने जाँच पनि हट्छ।

प्रत्येक क्लाइन्ट प्लेटफर्मका लागि अपेक्षित पहिचान अभिलेख गर्नुहोस्, किनभने एउटा क्लाइन्टले स्वतः निकाल्ने मान अर्कोमा स्पष्ट रूपमा दिनुपर्ने हुन सक्छ।

नवीकरण अनुरोधलाई चार तथ्य दिनुहोस्

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