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 बदलणे ही पहिली प्रतिक्रिया नाही.