CA کو دوبارہ بنائے بغیر VPN کلائنٹ شامل کرنا

آپ کو ایک اور لیپ ٹاپ کے لیے ایک اور سرٹیفکیٹ چاہیے، لیکن تلاش کے نتائج کا پہلا سبق ایسے حکم سے شروع ہوتا ہے جو PKI ڈائریکٹری مٹا دیتا ہے۔ وہ حکم پہلی ترتیب کا ہے، رجسٹریشن کا نہیں، اور اسے چلانے سے آپ CA، اجرا کی تاریخ اور ہر وہ کلائنٹ پروفائل کھو دیتے ہیں جس نے پرانے جاری کنندہ پر اعتماد کیا تھا۔ فیصلہ تنگ ہے: کیا جاری کنندہ کے پاس اب بھی قابل استعمال حالت ہے، اور کیا نئی ڈیوائس آپ کی رجسٹریشن پالیسی میں فٹ بیٹھتی ہے؟ تین شرطیں اس کا تعین کرتی ہیں، اور صرف ایک دوبارہ تعمیر کو جائز ٹھہراتی ہے۔

دوبارہ تعمیر واقعی کیا تباہ کرتی ہے

PKI کو دوبارہ شروع کرنا ڈائریکٹری کو خالی ڈھانچے سے بدل دیتا ہے: نئی CA کلید اور سرٹیفکیٹ، خالی اجرا ڈیٹا بیس اور نیا سلسلہ شمار کنندہ۔ کلائنٹ خود بخود پیچھے نہیں چلتے؛ ان کے پروفائل پرانی CA کو پن کرتے ہیں، اس لیے ہر ڈیوائس کو دوبارہ رجسٹر ہونا پڑتا ہے، اور جو قابل رسائی نہ ہوں وہ ہاتھ سے۔

زیادہ خاموش نقصان حساب کتاب ہے۔ منسوخی اس بات پر منحصر ہے کہ آپ جانیں کون سے سلسلہ نمبر کس کو جاری کیے۔ فہرست مٹا دیں تو اب بھی دستخط کر سکتے ہیں، لیکن یقین سے نہیں کہہ سکتے کہ باقی سرٹیفکیٹ میں سے کون سے منسوخ کرنے تھے۔ جاری کنندہ کی حالت کے بغیر سرٹیفکیٹ رکھنے والی CA ڈائریکٹری ایسا بیک اپ ہے جو نظام کا غلط نصف بحال کرتا ہے۔

CA کی نجی کلید کو چلتی سرور کے پاس کاپی کرنا دوسرا ایسا شارٹ کٹ ہے جسے رد کرنا چاہیے: یہ آف لائن رہنے والی دستخطی اتھارٹی کو غیر قابل اعتماد ٹریفک والے ہوسٹ پر ایک اور فائل بنا دیتا ہے۔

پہلی شرط: کیا جاری کنندہ کی حالت اب بھی قابل رسائی ہے

فیصلے سے پہلے وہ ڈائریکٹری تلاش کریں جس پر سرور واقعی بھروسہ کرتا ہے۔ سرور جو سرٹیفکیٹ CA کے طور پر پیش کرتا ہے اسے PKI ڈائریکٹری والے سے فنگر پرنٹ کے ذریعے موازنہ کریں، فائل کے نام سے نہیں:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

اگر فنگر پرنٹ مل جائیں تو رجسٹریشن اضافی ہے اور کچھ دوبارہ نہ بنائیں۔ اگر مختلف ہوں تو آپ ایسی CA سے دستخط کر رہے ہیں جس پر سرور بھروسہ نہیں کرتا: سرٹیفکیٹ صاف نصب ہوتا ہے مگر مصافحے میں ناکام ہوتا ہے، اور اس غلطی کو گھنٹوں کلائنٹ کی خرابی سمجھا جاتا ہے۔

پھر اجرا کی حالت دیکھیں: فہرست فائل، سلسلہ شمار کنندہ اور CRL نمبر فائل۔ فہرست نہ ہو مگر کلید ہو تو جاری کر سکتے ہیں، لیکن منسوخی درج کرنے کا مسئلہ ورثے میں ملتا ہے۔ اسے تبدیلی کے ریکارڈ میں لکھیں، کیونکہ اگلی منسوخی کی درخواست اسے بے نقاب کرے گی۔

دوسری شرط: نئی نجی کلید کس کے پاس ہے

یہ وہ فیصلہ ہے جو صارفین محسوس کرتے ہیں، اس لیے واضح طور پر کریں۔ کلائنٹ پر بنائی گئی اور درخواست کے طور پر بھیجی گئی کلید نجی حصہ پہلے حکم سے ڈیوائس پر رکھتی ہے، اور منتظم اسے کبھی نہیں چھوتا۔ سرور پر بنائی گئی کلید بغیر اوزار والی ڈیوائس کے لیے آسان ہے، لیکن منتظم کو ہر کلید کا محافظ بنا دیتی ہے اور سرور میں دخول کے اثرات کو وسیع کرتی ہے۔

موجودہ CA کے خلاف Easy-RSA 3 کے ساتھ درخواست درآمد کرنا اور دستخط کرنا دو حکم ہیں:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

سرٹیفکیٹ کی قسم جان بوجھ کر منتخب کریں۔ کلائنٹ کے بجائے سرور سرٹیفکیٹ کے طور پر دستخط شدہ درخواست ایسی فائل دیتی ہے جو اچھی لگتی ہے مگر ساتھی اسے مسترد کرتا ہے، اور غلطی کا پیغام شاذ و نادر ہی وجہ بتاتا ہے۔ openssl ca کے ساتھ دستخط کریں تو وہی انتخاب آپ کی دی گئی توسیعات میں ہوتا ہے، طے شدہ حصے میں نہیں۔

تیسری شرط: کیا سرور کو سرٹیفکیٹ سے زیادہ چاہیے

سرٹیفکیٹ توثیق والے عام OpenVPN سرور کے لیے سرٹیفکیٹ ہی رجسٹریشن ہے: مشترکہ نام کلائنٹ کی شناخت بن جاتا ہے، اور کوئی بھی ڈائریکٹری، دھکیلا گیا راستہ یا مستقل پتہ اسی نام پر منحصر ہے۔ سرٹیفکیٹ شامل کریں اور کنفیگ بھول جائیں تو ٹنل جڑ جاتا ہے مگر ضروری راستے ظاہر نہیں ہوتے۔

پلیٹ فارم اسے بدلتے ہیں۔ OpenVPN Access Server اپنا صارف ڈیٹا بیس رکھتا ہے، اس لیے دستخط شدہ سرٹیفکیٹ اکاؤنٹ نہیں؛ اکاؤنٹ موجود اور اجازت یافتہ ہونا چاہیے۔ دوسرے گیٹ وے شناختی تار کو گروہ سے جوڑتے ہیں۔ ایک ڈیوائس کی رجسٹریشن عام طور پر دو نظاموں کو چھوتی ہے، اور سرٹیفکیٹ صرف پہلا ہے۔

اضافی طریقہ کار اور کب دوبارہ تعمیر درست ہے

بغیر نقصان ایک ڈیوائس شامل کرنے کی ترتیب: فنگر پرنٹ سے جاری کنندہ کی تصدیق کریں، PKI ڈائریکٹری کا تازہ بیک اپ لیں، کلائنٹ کردار کے لیے درخواست درآمد کر کے دستخط کریں، منظور شدہ راستے سے سرٹیفکیٹ اس کی زنجیر کے ساتھ پہنچائیں، اور صارف کے جڑنے سے پہلے تصدیق کریں:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

مقصد کی سطر میں SSL client دکھنا چاہیے۔ اجرا کے بعد CA بیک اپ اپ ڈیٹ کر کے ختم کریں، کیونکہ نیا سلسلہ نمبر درج ہونے سے پہلے لیا گیا بیک اپ ابھی شامل کردہ ڈیوائس کے بغیر حالت بحال کرتا ہے۔

دوبارہ تعمیر تین صورتوں میں درست ہے: CA کلید کمزور ہو گئی، اجرا کی حالت ناقابل تلافی طور پر ضائع ہو گئی، یا آپ جان بوجھ کر کلید الگورتھم یا سرٹیفکیٹ پالیسی بدل رہے ہیں۔ تینوں ایسے منصوبے ہیں جن کے لیے ہر کلائنٹ کی دوبارہ رجسٹریشن کا منصوبہ درکار ہے، ایک ڈیوائس کی درخواست کے مراحل نہیں۔ کوئی بھی لاگو نہ ہو تو اضافی طور پر رجسٹر کریں۔