SoftEther ServerCertSet: vpncmd बाट नवीकृत शृंखला आयात गर्नुहोस्

Certbot ले सफल नवीकरण रिपोर्ट गर्छ, डिस्कमा रहेका फाइलहरूमा नयाँ मितिहरू छन्, र ग्राहकहरू अझै पुरानो पहिचानसँग भेट्छन्। SoftEther ले आफ्नो SSL सर्भर प्रमाणपत्र आफ्नै सर्भर-स्तरीय कन्फिगरेसनमा राख्छ, त्यसैले डिस्कमा नयाँ फाइलले पात र त्यसको कुञ्जी आयात नभएसम्म केही पनि बदल्दैन। तलको क्रमले एउटा हातले गरिएको आयात, प्रत्येक नवीकरणपछि चल्ने आवरण, र श्रोताले वास्तवमा के प्रस्तुत गर्छ भनी पढ्ने जाँच समेट्छ। प्रत्येक चरणले अर्को नवीकरणपछि तुलना गर्न सकिने प्रमाण छोड्छ।

नवीकृत फाइलले सर्भरको पहिचान बदल्दैन

जारी गर्नु र तैनाथ गर्नु अलग-अलग घटनाहरू हुन्, असफलताका तरिका पनि अलग छन्। ACME ग्राहकले फाइलहरू वंश निर्देशिकामा लेख्छ र सफलता अभिलेख गर्छ; SoftEther ले भने आफ्नो कन्फिगरेसनमा अन्तिम पटक लोड भएको प्रमाणपत्र नै प्रयोग गरिरहन्छ। त्यसैले शून्य निकास स्थितिले फाइलहरूको वर्णन गर्छ, सेवाको होइन, र कोही नहेरेसम्म यी दुई फरक रहन सक्छन्। आयातलाई तैनाथी चरण र नवीकरणलाई त्यसको इनपुट मान्नुहोस्।

त्यो भिन्नताले भ्रमित आधा-असफलताको पनि व्याख्या गर्छ: पुरानो प्रमाणपत्र यसको म्याद सकिएसम्म काम गरिरहन्छ, त्यसैले सुरुमा केही पनि बिग्रेको देखिँदैन। म्याद सकिएपछि सबै ग्राहक एकैचोटि असफल हुन्छन्, जुन छुटेको तैनाथी चरणभन्दा बाधा जस्तो देखिन्छ। प्रत्येक नवीकरणपछि प्रस्तुत पहिचान जाँच्दा त्यो आश्चर्य नियमित अवलोकनमा परिणत हुन्छ।

श्रोतालाई मिल्ने चुनौती छान्नुहोस्

प्रमाणपत्रले ग्राहकहरूले प्रमाणित गर्ने होस्टको नाम राख्नुपर्छ, त्यसैले आन्तरिक लेबल वा ठेगानाको सट्टा सार्वजनिक DNS नाम प्रयोग गर्नुहोस्। HTTP-01 का लागि चुनौतीको जवाफ क्षणभर पोर्ट 80 मा दिनुपर्छ, त्यो अस्थायी श्रोता हो र SoftEther को आफ्नै पोर्ट सार्ने कारण कहिल्यै होइन। DNS-01 ले रेकर्डमार्फत नियन्त्रण प्रमाणित गर्छ र आउने HTTP पटक्कै आवश्यक हुँदैन।

निगरानीविहीन नवीकरण भन्नाले एउटै जोनमा सीमित प्रमाणहरूसहितको स्वचालित DNS एकीकरण हो, हरेक दुई महिनामा हातले टाइप गरिने TXT रेकर्ड होइन। वाइल्डकार्डले चुनौतीको प्रकार बदल्छ, त्यो स्वचालनको आवश्यकता होइन। पहिलो प्रमाणपत्र अस्तित्वमा आउनुअघि नै यो निर्णय गर्नुहोस्, किनकि पछि चुनौतीको प्रकार बदल्नु भनेको ग्राहक कन्फिगरेसन र फायरवाल दुवैलाई एकैचोटि छुनु हो।

यहाँ रहेसम्म कलाकृतिहरू व्यवस्थित राख्नुहोस्। पात र मध्यवर्ती प्रमाणपत्रहरू अलग फाइलका रूपमा र एउटा संयुक्त शृंखला फाइलका रूपमा आउँछन्, निजी कुञ्जी फेरि अलग हुन्छ, र आयातलाई त्यससँग मिल्ने कुञ्जीसहितको शृंखला चाहिन्छ, एक्लै सार्वजनिक प्रमाणपत्र होइन।

शृंखला सर्भर स्तरमा आयात गर्नुहोस्

प्रमाणपत्र छुनुअघि सर्भर कन्फिगरेसनको ब्याकअप लिनुहोस् र व्यवस्थापन इन्टरफेसमा अझै पुग्न सकिन्छ भनी पुष्टि गर्नुहोस्। Virtual Hub प्रशासकको रूपमा होइन, सर्भर प्रशासकको रूपमा जडान हुनुहोस्, किनकि प्रमाणपत्र सर्भर वस्तुको हो। त्यसपछि शृंखला र कुञ्जी निरपेक्ष मार्गमा लोड गर्नुहोस्, आदेश चलाउने खाताले पढ्न सक्ने फाइलहरूबाट। मार्गहरू निरपेक्ष छन् किनकि आदेशले तिनलाई vpncmd चलाएको प्रक्रियाको कार्य निर्देशिकाबाट समाधान गर्छ:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

सफलता मान्नुको सट्टा आदेशको आउटपुट पढ्नुहोस्, र त्यसपछि दिएको फाइलमा भरोसा गर्नुको सट्टा शृंखला फेरि पढ्नुहोस्। पूरा PEM बन्डल आयात गर्ने बिल्ड र पहिलो प्रमाणपत्र मात्र लिने बिल्डबीचको सीमा एकै ठाउँमा अभिलेख गरिएको छैन, त्यसैले तपाईंको अगाडिको बिल्डका लागि जाँचले नै निर्णय गर्छ। श्रोताले प्रस्तुत गर्ने प्रमाणपत्रहरू गन्नुहोस्; मध्यवर्ती बिनाको पात पहिलो ब्लक मात्र प्रयोग गर्ने आयातकर्ताको हस्ताक्षर हो।

आयात गरिएको कुञ्जी सर्भर चलाउने खातालाई मात्र पढ्न योग्य राख्नुहोस्, र व्यवस्थापन पासवर्ड शेल इतिहासबाहिर राख्नुहोस्। यो पहिलो आयातमा पासवर्ड आदेश आर्गुमेन्टका रूपमा दिनुको सट्टा प्रम्प्टमा टाइप गर्नुहोस्। यी दुई बानीले केही खर्च गर्दैनन् र प्रमाणपत्र तैनाथीले जोगाउनुपर्ने कुरा चुहाउने सबैभन्दा सामान्य बाटो हटाउँछन्। यो पहिलो आयातअघि गर्नुहोस्, पछि होइन।

तैनाथीलाई हुक गर्नुहोस्, नवीकरणलाई होइन

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

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

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

प्रस्तुत शृंखलाको फाइलसँग तुलना गर्नुहोस्

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

त्यसपछि नयाँ ग्राहक जडान बनाउनुहोस्, किनकि आयातअघि स्थापित सत्रहरू अघिल्लो पहिचानविरुद्ध प्रमाणित भएका थिए र नयाँबारे केही प्रमाणित गर्दैनन्। यदि ग्राहकहरूले पुरानो पात पिन गर्छन्, सार्वजनिक शृंखला मान्य भए पनि उनीहरूलाई समन्वित अद्यावधिक चाहिन्छ, र त्यो काम नवीकरणकै उही रनबुकमा पर्छ। सेवाअगाडिको रिभर्स प्रोक्सीले राम्रो प्रमाणपत्र प्रस्तुत गर्न सक्छ तर VPN श्रोताले अझै पुरानो राखिरहेको हुन सक्छ, त्यसैले जाँचले ग्राहकहरू वास्तवमा पुग्ने पोर्टको नाम दिनुपर्छ। नवीकरण मितिको छेउमा औंलाको छाप लेख्नुहोस्, ताकि अर्को तुलना स्मरणको कार्य नभई जाँच होस्।