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 मा भरोसा गर्ने हरेक अर्को सेवा कमजोर हुन्छ। तपाईंले कुन पङ्क्ति बदल्नुभयो र अपवाद कहिले सकिन्छ अभिलेख गर्नुहोस्।
त्यसपछि दुवै पठन माथिबाट फेरि चलाउनुहोस्, किनकि एउटा पङ्क्तिको परिवर्तनले अर्कोमा वार्ता हुने कुरा सार्न सक्छ। पूरै सूची दुई आदेश र एक तालिका हो, र पियर राउटर, ल्यापटप वा उपकरण जे भए पनि काम उही हो।