IKEv2 मध्ये दोन स्वाक्षऱ्या आहेत: प्रमाणपत्र आणि 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 पद्धत जोडते, त्यामुळे नवीन हॅशला स्वतःचा पद्धत-क्रमांक लागत नाही। हे बोलणीने ठरते, गृहीत धरले जात नाही: पीअरची लायब्ररी तीच प्रमाणपत्रे पार्स करू शकते म्हणून त्याला विस्तार मिळत नाही, आणि जो पीअर फक्त मूळ पद्धती अमलात आणतो तो गेटवेला त्यापैकी एक ठेवण्यास भाग पाडतो। हा सुसंगततेच्या खर्चासह धोरणाचा व्यवहार आहे, दोष नाही।

समर्थन प्रत्येक दिशा आणि प्रत्येक जोडणीसाठी आहे, म्हणून कुटुंब-स्तरीय दाव्यावर विश्वास ठेवण्याऐवजी तुमच्यासमोरची बिल्ड तपासा। तीन वर्षांपूर्वी लिहिलेले क्षमता-मॅट्रिक्स तीन वर्षे जुन्या बिल्डचे वर्णन करते।

यादीत चार ओळी टाका

वाद संपवणाऱ्या नोंदीत चार ओळी असतात, प्रत्येक वेगळ्या ठिकाणाहून वाचलेली आणि प्रत्येक वेगळ्या व्यक्तीने बदललेली। काहीही ठरवण्यापूर्वी ती भरा, कारण चुकीची ओळच उपाय निवडते।

प्रत्येक ओळ आपला स्वतःचा सुसंगतता-परिणाम बाळगते। ESP सायफर बदलल्याने जारीकर्त्याची स्वाक्षरी निवडली जात नाही, आणि CA पडताळणी सैल केल्याने पीअरनी कधीही ठरवलेली नसलेली ऑनलाइन पद्धत जोडली जात नाही। तिकीट स्वाक्षरी-विसंगतीचा दावा करते तेव्हा खरोखर चुकीची ओळ जवळजवळ कधीही पहिली नसते।

PKI कमकुवत न करता जुना प्रसंग सोडवा

जुना पीअर तुमचे धोरण आता परवानगी देत नसलेली पद्धतच देऊ शकतो। पर्याय म्हणजे वेळेच्या मर्यादेसह सुसंगतता-अपवाद, क्लायंट अद्ययावत करणे, किंवा फक्त त्या पीअरसाठी वेगळी प्रमाणीकरण व्यवस्था। कमकुवत प्रमाणपत्र स्वाक्षरीभोवती PKI पुन्हा बांधल्याने ऑनलाइन देवाणघेवाणीतील मर्यादा दूर होत नाही आणि त्याच CA वर विश्वास ठेवणाऱ्या इतर प्रत्येक सेवेला कमकुवत करते। तुम्ही कोणती ओळ बदलली आणि अपवाद कधी संपेल ते नोंदवा।

नंतर दोन्ही वाचन वरून पुन्हा चालवा, कारण एका ओळीतील बदल दुसऱ्यात ठरलेले सरकवू शकतो। संपूर्ण यादी दोन आदेश आणि एक तक्ता आहे, आणि पीअर राउटर, लॅपटॉप किंवा उपकरण असो काम तेच आहे।