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 श्रोता अजूनही जुने धरून असू शकतो, म्हणूनच तपासणीने ग्राहक प्रत्यक्षात पोहोचतात ते पोर्ट नामनिर्देशित केले पाहिजे। नूतनीकरण तारखेजवळ बोटांची छाप नोंदवा, जेणेकरून पुढील तुलना स्मरणाचे कृत्य नसून तपासणी असेल।

संबंधित लेख