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 سننے والا اب بھی پرانا رکھتا ہے، اسی لیے جانچ کو وہ پورٹ نامزد کرنا چاہیے جہاں کلائنٹ واقعی پہنچتے ہیں۔ تجدید تاریخ کے پاس فنگر پرنٹ درج کریں، تاکہ اگلا موازنہ یادداشت کا عمل نہیں بلکہ جانچ ہو۔