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 बदल्नु पहिलो प्रतिक्रिया होइन।