SoftEther ServerCertSet: vpncmd দিয়ে নবায়িত চেইন আমদানি করুন

Certbot সফল নবায়নের কথা জানায়, ডিস্কের ফাইলগুলো নতুন তারিখ বহন করে, তবু ক্লায়েন্টরা এখনও পুরোনো পরিচয়ই পায়। SoftEther তার SSL সার্ভার সার্টিফিকেট নিজের সার্ভার-স্তরের কনফিগারেশনে রাখে, তাই ডিস্কে নতুন ফাইল থাকলেও লিফ সার্টিফিকেট ও তার কী আমদানি না হওয়া পর্যন্ত কিছুই বদলায় না। নিচের ক্রমে একটি হাতে করা আমদানি, প্রতিটি নবায়নের পরে চলা একটি ছোট স্ক্রিপ্ট, এবং লিসেনার আসলে কী উপস্থাপন করে তা পড়ার একটি পরীক্ষা আছে। প্রতিটি ধাপ এমন প্রমাণ রেখে যায় যা পরের নবায়নের পরে আপনি মিলিয়ে দেখতে পারেন।

নবায়িত ফাইল সার্ভারের পরিচয় বদলায় না

ইস্যু ও ডিপ্লয় আলাদা ঘটনা, তাদের ব্যর্থতার ধরনও আলাদা। ACME ক্লায়েন্ট ফাইলগুলো একটি lineage ডিরেক্টরিতে লেখে এবং সফলতা নথিভুক্ত করে; 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 সেট করে, তাই একাধিক সার্টিফিকেট চালানো মেশিনেও স্ক্রিপ্টটি একটি সার্টিফিকেটে কাজ করতে পারে। হোস্টের প্রতিটি নবায়নে সাড়া দেওয়ার বদলে lineage অনুযায়ী ফিল্টার করুন। স্ক্রিপ্টটি হলো সার্ভারের অধিকার নিয়ে চলা ডিপ্লয়মেন্ট কোড, তাই সেই জায়গার অন্য যেকোনো স্ক্রিপ্টের মতোই এটি পর্যালোচনা করুন।

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

মানুষ ছাড়া চলা হুকের নিজস্ব সুরক্ষিত ক্রেডেনশিয়াল স্টোর এবং মানুষের কাছে পৌঁছানো ব্যর্থতার সংকেত দরকার। ইস্যু সফল হয়ে আমদানি ব্যর্থ হলে আরেকটি সার্টিফিকেট না চেয়ে আমদানিটি আবার চেষ্টা করুন, কারণ দ্বিতীয় অনুরোধ নতুন ফাইলের আড়ালে ডিপ্লয়মেন্টের ত্রুটি ঢেকে দেয়। Certbot-এর নবায়ন ডকুমেন্টেশন স্পষ্ট করে বলে, কিছু না আপডেট করা রান স্বাভাবিক ফলাফল, তাই হুকই দুটোর পার্থক্য বলে দেয়।

উপস্থাপিত চেইনটি ফাইলের সঙ্গে মেলান

ডিস্ক নয়, লিসেনার পড়ুন। ক্লায়েন্টরা যে সার্ভার নাম ব্যবহার করে সেটি দিয়ে ক্লায়েন্টমুখী পোর্টে সংযুক্ত হন, তারপর ফিঙ্গারপ্রিন্ট ও সরবরাহ করা চেইন হুক যেই lineage ইনস্টল করেছে তার সঙ্গে মেলান। দুটি কমান্ড এতে ঢেকে দেয়, আর প্রথমটি ইন্টারমিডিয়েট আদৌ আসে কি না তাও দেখায়:

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 লিসেনার তখনও পুরোনোটি ধরে থাকে, তাই পরীক্ষাটি ক্লায়েন্টরা সত্যিই যে পোর্টে পৌঁছায় তার নাম বলতে হবে। নবায়নের তারিখের পাশে ফিঙ্গারপ্রিন্ট লিখে রাখুন, যাতে পরের মিলকরণ স্মৃতির কাজ নয়, একটি পরীক্ষা হয়।