VPN سرٹیفکیٹ کاپی کرنے سے کلید کاپی نہیں ہوتی
سرٹیفکیٹ میں عوامی کلید اور دستخط شدہ شناخت ہوتی ہے؛ اس کی نجی کلید الگ ہوتی ہے۔ یہ ماننے سے پہلے کہ کوئی کاپی تصدیق کر سکتی ہے، برآمدگی کا بنڈل پڑھیں۔
یہ رہنما کلائنٹ کی سرٹیفکیٹ فہرست سے شروع ہوتی ہے، جہاں اندراج صرف نام، جاری کنندہ اور اختتام کی تاریخ دکھاتا ہے، اور کچھ نہیں۔ اسے برآمد کریں، دوسرے آلے پر درآمد کریں، اور کنکشن مسترد ہو جاتا ہے کیونکہ کلائنٹ نجی کلید رکھنے کا ثبوت نہیں دے سکتا۔ فائل مکمل طور پر کاپی ہوئی تھی؛ غلطی یہ ہے کہ سرٹیفکیٹ اپنی کلید ساتھ لے کر آئے گا۔ فارمیٹ چننے سے پہلے برآمدگی کا ڈائیلاگ پڑھیں، پھر وہ فائل دیکھیں جو واقعی آپ کو ملی۔
دو کلکس، دو بالکل مختلف اشیاء۔
فائل کی توسیع نہیں، برآمدگی کا ڈائیلاگ پڑھیں
DER یا PEM سرٹیفکیٹ برآمدگی میں عوامی کلید اور دستخط شدہ شناختی دعوے ہوتے ہیں، جو سرور کو آپ پر بھروسہ کرنے اور کلائنٹ کو سرور کی تصدیق کرنے کے لیے درکار ہیں۔ PKCS#12 بنڈل ایسا کنٹینر ہے جو سرٹیفکیٹ، اس کی زنجیر اور اس سے مطابقت رکھنے والی نجی کلید رکھ سکتا ہے، پاس ورڈ سے محفوظ، اگرچہ اسے کلید کے بغیر بھی بنایا جا سکتا ہے۔
PEM صرف متنی انکوڈنگ ہے، مواد کے بارے میں کوئی وعدہ نہیں۔ ایک ہی توسیع ایک سرٹیفکیٹ یا کئی لیبل شدہ بلاکس والی فائل بیان کر سکتی ہے، اور کون سی، یہ برآمدگی کے اختیارات طے کرتے ہیں۔
لہٰذا کارآمد سوال کبھی یہ نہیں کہ آپ کو کون سی توسیع ملی، بلکہ یہ کہ فائل میں کون سے بلاکس ہیں۔ کلید کے بغیر برآمد کیا گیا بنڈل بھی بنڈل ہی ہے۔ فارمیٹ کی مقبولیت نہیں، مواد جانچیں۔
جانچیں کہ آپ کو واقعی کیا ملا
کچھ بھی درآمد کرنے سے پہلے لیبل تلاش کریں، پھر سرٹیفکیٹ کے فیلڈز پڑھ کر تصدیق کریں کہ آپ کے پاس کون سی شناخت ہے۔ جانچ اسی فائل پر چلائیں جو واقعی درآمد ہوگی۔ ہر دوبارہ برآمدگی کے بعد انہیں دہرائیں، کیونکہ اختیارات مختلف ہو سکتے ہیں۔
grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem openssl x509 -in client.crt -noout -subject -issuer -dates openssl pkey -in client.key -noout -text | head -5 openssl pkcs12 -info -in client.p12 -noout
صرف سرٹیفکیٹ بلاک والی برآمدگی ایک عوامی شے ہے اور تصدیق نہیں کر سکتی۔ سرٹیفکیٹ کے بغیر کلید کا بلاک آپ کو اس زنجیر سے محروم کر دیتا ہے جس کی سرور توقع کرتا ہے۔ PKCS#12 کی معلوماتی آؤٹ پٹ یہ بھی بتاتی ہے کہ کلید موجود ہے یا نہیں، جو اس فارمیٹ کے لیے سوال طے کر دیتی ہے۔ یہ الگورتھم اور کلید کا حجم بھی بتاتی ہے، اور کلید نہ ہونے پر مکمل ناکام ہو جاتی ہے۔
نجی کلید والی فائل کبھی معاون تھریڈ، مسئلہ ٹریکر یا چیٹ میں نہ چسپاں کریں، چاہے وہ اسی سرٹیفکیٹ جیسی لگے جو آپ پہلے شیئر کر رہے تھے۔ کلید پینل کے اسکرین شاٹس بھی اتنی ہی احتیاط کے متقاضی ہیں۔
کلید کسی ایسی جگہ ہو سکتی ہے جہاں سے آپ کاپی نہیں کر سکتے
زیرِ انتظام آلات پر نجی کلید آپریٹنگ سسٹم کے کی چین، ہارڈویئر ٹوکن یا محفوظ انکلیو میں ہو سکتی ہے، اور پالیسی اسے ناقابلِ برآمد نشان زد کرتی ہے۔ پھر سرٹیفکیٹ منتظم عوامی شے دکھاتا ہے جبکہ راز اپنی جگہ رہتا ہے، اور کوئی برآمدگی کمانڈ قابلِ نقل کاپی پیدا نہیں کرے گی۔ موبائل ڈیوائس مینجمنٹ کے ذریعے اندراج اکثر ڈیزائن کے مطابق اسی طرح کام کرتا ہے۔
یہ ایک نگرانی ہے، گریز کی رکاوٹ نہیں۔ عوامی سرٹیفکیٹ سے نجی کلید دوبارہ بنانا ممکن نہیں، اور ایسا دعویٰ کرنے والا کوئی بھی اوزار کچھ اور کر رہا ہے۔
کاپی کرنے کے بجائے نئی شناخت درج کریں
معاونت یافتہ راستہ عام طور پر یہ ہے کہ نئے آلے کے لیے الگ شناخت درج کریں اور پرانی کو ریٹائر ہونے پر منسوخ کر دیں۔ اس طرح ہر آلہ آزادانہ طور پر واپس لیا جا سکتا ہے۔ جہاں کلید کے ساتھ برآمدگی واقعی منظور شدہ ہو، وہاں بنی فائل اور اس کے پاس ورڈ کو اسناد سمجھیں: سکون کی حالت میں خفیہ کردہ، قابلِ اعتماد چینل سے منتقل شدہ، اور اندراج مکمل ہونے پر حذف شدہ۔
درآمد شدہ شناخت سے تصدیق کر کے جانچیں، درآمد کی کامیابی دیکھ کر نہیں۔ جو کلائنٹ اپنے ذخیرے میں عوامی سرٹیفکیٹ قبول کرتا ہے، اس نے کلید کے بارے میں کچھ ثابت نہیں کیا۔
یہ یقینی بنا کر ختم کریں کہ سرور نئی شناخت قبول کرتا ہے اور پرانی اب بھی پالیسی کے مطابق برتاؤ کرتی ہے۔ اسی طرح یہ رہنما ثبوت کے ساتھ مکمل ہوتی ہے، کسی درست دکھنے والی فائل کے ساتھ نہیں۔