strongSwan: कुंजी प्रकार, लोडर और गलत backend

फ़ाइल एक्सटेंशन कुंजी एल्गोरिदम की पहचान नहीं करते, और .pem लिफ़ाफ़े में RSA या ECDSA सामग्री हो सकती है। PEM बताता है कि बाइट्स कैसे लपेटे जाते हैं, जबकि RSA और ECDSA अलग-अलग एल्गोरिदम के नाम हैं, और PKCS12 फ़ाइल तीसरी चीज़ है। strongSwan प्लगइन और कॉन्फ़िगरेशन backend के ज़रिए क्रेडेंशियल लोड करता है, इसलिए प्रमाणपत्र सूची में दिख सकता है जबकि निजी कुंजी कभी उपयोगी नहीं बनती। किसी भी रहस्य को संपादित करने से पहले उन परतों को अलग करें।

एन्कोडिंग, एल्गोरिदम और पैकेजिंग तीन परतें हैं

कुंजी फ़ाइल में एन्कोडिंग, एल्गोरिदम और अक्सर एक कंटेनर होता है। PEM परिचित base64 लिफ़ाफ़ा है; DER उसका बाइनरी समकक्ष है; PKCS12 प्रमाणपत्र को उसकी कुंजी और श्रृंखला के साथ जोड़ता है। प्रमाणपत्र-श्रृंखला फ़ाइल एक और कंटेनर है, और इसमें आमतौर पर कोई निजी कुंजी नहीं होती। इनमें से कोई भी लेबल नहीं बताता कि अंदर की सामग्री RSA है या ECDSA।

एल्गोरिदम को स्वयं ऑब्जेक्ट से पढ़ें। प्रदाता का मार्केटिंग नाम या फ़ाइल एक्सटेंशन प्रमाण नहीं हैं, क्योंकि वही जारीकर्ता अलग-अलग कुंजी प्रकार दे सकता है।

लोडर को दोष देने से पहले सार्वजनिक कुंजियों की तुलना करें

जो प्रमाणपत्र लोड होता है वह सिद्ध करता है कि प्रमाणपत्र पार्स हुआ, यह नहीं कि उसकी निजी कुंजी मौजूद है या उपयोगी है। प्रमाणपत्र और प्रस्तावित निजी कुंजी से सार्वजनिक कुंजी निकालें, फिर दोनों डाइजेस्ट की तुलना करें। यदि कोई भी निष्कर्षण विफल हो, तो वहीं रुकें, क्योंकि खाली आउटपुट का डाइजेस्ट कुछ सिद्ध नहीं करता। मेल खाते डाइजेस्ट सिद्ध करते हैं कि युग्म एक साथ है, और इस बारे में कुछ नहीं कि प्रमाणपत्र काम के लिए उपयुक्त है।

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

दूसरा कमांड आपकी मशीन पर निजी सामग्री को छूता है लेकिन केवल सार्वजनिक आधा निकालता है। इसे वैसे ही रखें, और कभी भी टिकट में निजी कुंजी पेस्ट न करें। यदि कुंजी एन्क्रिप्टेड है, तो समर्थित टूल को पासफ़्रेज़ माँगने दें, न कि उसे कमांड लाइन पर रखें जहाँ प्रोसेस सूची उसे उजागर कर सकती है।

पुराना ipsec.secrets या swanctl क्रेडेंशियल

strongSwan में दो सामान्य क्रेडेंशियल पथ हैं। पुराना starter स्टैक प्रकार-विशिष्ट प्रविष्टियाँ इस फ़ाइल से पढ़ता है ipsec.secrets, और प्रत्येक प्रविष्टि को सामग्री के लिए सही प्रकार बताना चाहिए। swanctl और vici स्टैक अपनी क्रेडेंशियल निर्देशिका से अपने कॉन्फ़िगरेशन के ज़रिए कुंजियाँ लोड करता है। जिस फ़ाइल को चल रहा backend नहीं पढ़ता उसे संपादित करने से कुछ नहीं बदलता।

: ECDSA "/etc/ipsec.d/private/server-key.pem"

पता लगाएँ कि वास्तव में कौन सा backend चल रहा है, फिर कुंजी को वहाँ रखें जहाँ वह backend देखता है। strongSwan 5.9 पुराना मैनुअल प्रकार-विशिष्ट रहस्य प्रविष्टियाँ परिभाषित करता है, और यह swanctl दस्तावेज़ नहीं है। दोनों को मिलाने से ऐसा डेमन बनता है जो उस फ़ाइल को अनदेखा करता है जिसे व्यवस्थापक प्रामाणिक मानता है। बिना त्रुटि बताने वाला पुनः लोड केवल यह दर्शाता है कि कॉन्फ़िगरेशन पार्स हुआ।

लोड इवेंट और प्रमाणीकरण परिणाम पढ़ें

नियंत्रित पुनः लोड के बाद, विशिष्ट कुंजी के लिए डेमन का अपना लोडिंग आउटपुट पढ़ें। स्टेटस डंप में सूचीबद्ध प्रमाणपत्र यह नहीं दिखाता कि निजी कुंजी उससे मिलाई गई थी।

यदि क्लाइंट अब भी विफल हो, तो सर्वर इवेंट और क्लाइंट त्रुटि को अलग रखें। श्रृंखला सत्यापन, पहचान मिलान और विधि संगतता बाद के प्रश्न हैं जिनके अपने प्रमाण हैं। परिणाम को सटीक कुंजी पथ और उस डाइजेस्ट के साथ लिखें जिसकी आपने तुलना की, क्योंकि अगली पाली अन्यथा वही पुनः लोड दोहराएगी। लोडर बेमेल के लिए CA बदलना पहली प्रतिक्रिया नहीं है।