IKEv2 में दो हस्ताक्षर हैं: प्रमाणपत्र और IKE_AUTH
CA प्रमाणपत्र पर हस्ताक्षर करता है, और पीयर अपने IKE_AUTH विनिमय पर अपनी योजना से हस्ताक्षर करता है। हर एक को उसके अपने फ़ील्ड से पढ़ें, फिर दोनों दर्ज करें।
आपका टिकट कहता है कि प्रमाणपत्र SHA-256 है, जबकि गेटवे लॉग किसी दूसरे हस्ताक्षर एल्गोरिद्म का नाम लेता है, और किसी ने पहले ही CA को फिर से जारी करने का अनुरोध तैयार कर दिया है। उस अनुरोध के कहीं जाने से पहले दोनों हस्ताक्षर अलग करें: एक सार्वजनिक कुंजी पर जारीकर्ता की मुहर है, दूसरा है IKE_AUTH के दौरान पीयर का यह सिद्ध करना कि उसके पास मेल खाती निजी कुंजी है। अलग-अलग घटक इन्हें चुनते हैं, और इनका अलग होना मान्य है। हर एक को वहाँ से पढ़ने में, जहाँ वह रहता है, दो कमांड और एक तालिका लगती है।
प्रमाणपत्र से जारीकर्ता का हस्ताक्षर पढ़ें
CA अपना हस्ताक्षर पहचान और कुंजी के बीच के बंधन पर लगाता है। वह हस्ताक्षर यह दर्ज करता है कि जारी करते समय CA ने क्या किया, यह नहीं कि विषय जुड़ते समय क्या करेगा, इसलिए उसका एल्गोरिद्म CA के अपने हैश और कुंजी चयन का वर्णन करता है। एक प्रकार की विषय कुंजी किसी भी असंगति के बिना दूसरे प्रकार की CA कुंजी के नीचे रह सकती है, और CA कुंजी का घुमाव त्रुटि नहीं बल्कि नियमित कार्य है। दोनों फ़ील्ड पढ़ें और आपके पास आधी सूची आ जाएगी:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"दोनों लेबल अलग प्रविष्टियों के रूप में लिखें। पहला CA का वर्णन करता है, दूसरा विषय की कुंजी का, और इनमें से कोई भी ऑनलाइन हस्ताक्षर का अनुमान नहीं लगाता।
IKE विनिमय से ऑनलाइन हस्ताक्षर पढ़ें
प्रमाणीकरण के दौरान हर पीयर विनिमय के डेटा पर अपनी निजी कुंजी से हस्ताक्षर करता है, और दूसरा पक्ष उस प्रमाण को प्रमाणपत्र की पहचान, विश्वास-श्रृंखला और नीति के विरुद्ध जाँचता है। RSA में पैडिंग और हैश इसी ऑनलाइन योजना के हैं, इसलिए लंबी कुंजी या नया SHA-256 प्रमाणपत्र स्वयं प्रमाणीकरण हस्ताक्षर के लिए RSA-PSS नहीं चुन सकता। बातचीत से तय विधि डेमन लॉग या उसकी कनेक्शन सूची में दिखती है, प्रमाणपत्र में कभी नहीं। हर पक्ष से पूछें कि उसने क्या तय किया, क्योंकि दोनों दिशाएँ अलग हो सकती हैं।
ipsec statusall | grep -i "auth\|proposal"जब एक पक्ष ऐसी योजना बताता है जो दूसरा बना नहीं सकता, तब आपको वही असंगति मिल गई जिसके बारे में टिकट था। CA को फिर से जारी करना उसके लिए गलत मरम्मत है, क्योंकि विफल प्रमाणपत्र कभी नहीं था।
RFC 7427 क्या बदलता है और क्या नहीं
मूल विधियाँ RFC 7296 में हर एल्गोरिद्म संयोजन के अनुसार क्रमांकित हैं। बाद का RFC 7427 हस्ताक्षर विस्तार हस्ताक्षर-हैश समर्थन के संकेत के साथ एक सामान्य Digital Signature विधि जोड़ता है, इसलिए नए हैश को अपना विधि-क्रमांक नहीं चाहिए। यह बातचीत से तय होता है, मान लिया नहीं जाता: पीयर को विस्तार इसलिए नहीं मिलता कि उसकी लाइब्रेरी वही प्रमाणपत्र पढ़ सकती है, और जो पीयर केवल मूल विधियाँ लागू करता है वह गेटवे को उनमें से एक रखने पर मजबूर करता है। यह संगतता की कीमत वाला नीति-सौदा है, त्रुटि नहीं।
समर्थन हर दिशा और हर कनेक्शन के अनुसार है, इसलिए परिवार-स्तर के दावे पर भरोसा करने के बजाय अपने सामने का बिल्ड जाँचें। तीन साल पहले लिखा क्षमता-मैट्रिक्स तीन साल पुराने बिल्ड बताता है।
सूची में चार पंक्तियाँ डालें
बहस खत्म करने वाले रिकॉर्ड में चार पंक्तियाँ हैं, हर एक अलग जगह से पढ़ी गई और हर एक अलग व्यक्ति द्वारा बदली गई। कुछ भी तय करने से पहले इसे भरें, क्योंकि गलत पंक्ति ही मरम्मत चुनती है।
| वस्तु | कहाँ से पढ़ें | कौन बदलता है |
|---|---|---|
| प्रमाणपत्र जारीकर्ता का हस्ताक्षर | प्रमाणपत्र का Signature Algorithm फ़ील्ड | CA संचालक, जारी करते समय |
| विषय की सार्वजनिक कुंजी | प्रमाणपत्र का Public Key Algorithm फ़ील्ड | जो विषय कुंजी बनाता है |
| IKE प्रमाणीकरण योजना | डेमन लॉग या कनेक्शन सूची, auth और signature-hash सूचना | दोनों पीयर पर IKE प्रोफ़ाइल |
| IKE और ESP सुरक्षा एल्गोरिद्म | कनेक्शन की प्रस्ताव-सूची | IPsec प्रोफ़ाइल, दिशा के अनुसार |
हर पंक्ति अपना संगतता-परिणाम लेकर आती है। ESP सिफ़र बदलने से जारीकर्ता का हस्ताक्षर नहीं चुना जाता, और CA सत्यापन ढीला करने से ऐसी ऑनलाइन विधि नहीं जुड़ती जिस पर पीयर ने कभी बातचीत नहीं की। जब टिकट हस्ताक्षर-असंगति का दावा करता है, तब सचमुच गलत पंक्ति लगभग कभी पहली नहीं होती।
PKI को कमजोर किए बिना पुराना मामला तय करें
पुराना पीयर केवल वही योजना दे सकता है जिसकी आपकी नीति अब अनुमति नहीं देती। विकल्प हैं समय-सीमित संगतता अपवाद, क्लाइंट अपडेट, या केवल उसी पीयर के लिए अलग प्रमाणीकरण व्यवस्था। कमजोर प्रमाणपत्र हस्ताक्षर के इर्द-गिर्द PKI दोबारा बनाना ऑनलाइन विनिमय की सीमा नहीं सुधारता और उसी CA पर भरोसा करने वाली हर दूसरी सेवा को कमजोर करता है। दर्ज करें कि आपने कौन-सी पंक्ति बदली और अपवाद कब खत्म होगा।
फिर दोनों पठन ऊपर से दोबारा चलाएँ, क्योंकि एक पंक्ति में बदलाव दूसरी में तय होने वाली बात को खिसका सकता है। पूरी सूची दो कमांड और एक तालिका है, और पीयर राउटर, लैपटॉप या उपकरण हो, काम वही है।