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 श्रोता अब भी पुराना रखता है, इसलिए जाँच को वह पोर्ट नामित करना चाहिए जहाँ ग्राहक वास्तव में पहुँचते हैं। नवीनीकरण तिथि के बगल में फ़िंगरप्रिंट लिखें, ताकि अगली तुलना स्मृति का कार्य नहीं बल्कि जाँच हो।