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 नोंदी, तपासणी करणारा क्लायंट आणि आवृत्ती, आणि त्रुटीचा नेमका मजकूर लिहून ठेवा। या चार ओळींतून तयार केलेली नूतनीकरण विनंती पहिल्याच वेळी योग्य प्रमाणपत्र मिळवते, त्याच परिचित फाइलनावाचे दुसरे प्रमाणपत्र नाही।