OpenSSL 3 کے بعد OpenVPN کلید کی درخواست: فراہم کنندہ کو دیکھیں

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

پہلا سوال یہ ہے کہ کلید خفیہ کردہ ہے یا نہیں، اور دوسرا یہ کہ یہ بلڈ اسے خفیہ کشائی کر سکتا ہے یا نہیں۔ دونوں جوابات جاننے کے بعد ہی ترتیب کی تبدیلیوں کا مطلب ہے۔

دیکھیں کہ کلید خفیہ کردہ ہے یا نہیں

فائل کی پہلی سطر پڑھیں اور پھر لائبریری کو اسے تجزیہ کرنے دیں، کیونکہ فائل کا نام کچھ ثابت نہیں کرتا۔ لیبل والا PEM بلاک ENCRYPTED PRIVATE KEY خفیہ کردہ PKCS#8 ہے، اور پرانا RSA PRIVATE KEY بلاک جو Proc-Type: 4,ENCRYPTED رکھتا ہے روایتی شکل ہے، اور دونوں پاس فریز کی توقع رکھتے ہیں۔ غیر خفیہ PRIVATE KEY بلاک تو اسے بالکل نہیں مانگنا چاہیے۔ تجزیہ اسی اکاؤنٹ سے چلائیں جو فائل کا مالک ہے، کیونکہ اجازت کا مسئلہ مختلف اور کہیں کم دلچسپ خرابی دیتا ہے۔

اگر کلید واقعی خفیہ نہیں اور کلائنٹ پھر بھی پوچھتا ہے، تو خفیہ نگاری دیکھنا بند کریں اور دیکھیں کہ پروفائل ایسی askpass فائل کا نام دیتا ہے یا نہیں جسے سروس اب بھی پڑھ سکتی ہے۔

دیکھیں کہ یہ بلڈ اسے خفیہ کشائی کر سکتا ہے یا نہیں

OpenSSL 3 نے اپنی الگورتھم معاونت فراہم کنندگان میں تقسیم کی، اور پرانے مخفی رموز کا مجموعہ اب طے شدہ فراہم کنندہ کی بجائے legacy فراہم کنندہ میں ہے۔ ان رموز میں سے کسی سے خفیہ کردہ کلید درست رہتی ہے، لیکن legacy فراہم کنندہ کے بغیر لوڈ کردہ لائبریری اسے خفیہ کشائی نہیں کر سکتی۔ کچھ کلائنٹس میں یہ دہرائی جانے والی درخواست کے طور پر ظاہر ہوتا ہے، اور کچھ میں پاس فریز کے فوراً بعد سخت ناکامی کے طور پر۔

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

دستیاب سب سے تنگ حل دیکھیں

نظام گیر تبدیلی کی بجائے کلائنٹ تک محدود تبدیلی کو ترجیح دیں۔ کچھ 2.6 بلڈز ایسا پروفائل اختیار قبول کرتے ہیں جو اس ڈیمون کے عمل کے لیے دونوں فراہم کنندگان لوڈ کرتا ہے، اس لیے اس پر بھروسہ کرنے سے پہلے اپنے درست ورژن کے دستی کتاب میں ہدایت کی تصدیق کریں؛ اس کے بجائے نظام کی openssl.cnf تدوین کرنے سے میزبان پر ہر OpenSSL پروگرام متاثر ہوتا ہے۔ تنگ ترتیب کلید کے دوبارہ انکوڈ ہونے کے بعد واپس لینا بھی کہیں آسان ہے۔

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

سروس کا سیاق دیکھیں، پھر دوبارہ انکوڈ کریں

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

پھر اس یونٹ کو دیکھیں جو واقعتاً کلائنٹ چلاتا ہے۔ آپ کے شیل میں پڑھی جانے والی کلید کسی دوسرے اکاؤنٹ کے تحت یا سخت کیے گئے ہوم ڈائریکٹری کی ترتیب کے ساتھ چلنے والی سروس کے لیے ناقابلِ مطالعہ ہو سکتی ہے۔

پروفائل کے ساتھ فراہم کنندہ کی ترتیب درج کریں اور دو کمانڈ والا امتحان بھی ساتھ رکھیں۔ جب بعد کی کوئی اپ گریڈ legacy فراہم کنندہ ہٹا دے، تو وہ امتحان دوبارہ چلائیں تاکہ دیکھ سکیں کہ کلید کو اب بھی اس کی ضرورت ہے یا پروفائل کو اس عارضی حل سے نکالا جا سکتا ہے۔

درخواست کم از کم تین وجوہات والی علامت ہے، اور ان میں صرف ایک ہی گمشدہ پاس فریز ہے۔