آپ VPN سیٹ اپ کے سرٹیفکیٹ صفحے پر پہنچتے ہیں، مفت خود-دستخط شدہ اختیار کو ادا شدہ عوامی CA کے ساتھ دیکھتے ہیں، اور سوال تحفظ کے انتخاب جیسا لگتا ہے۔ دراصل یہ سامعین کا انتخاب ہے۔ دونوں اختیارات ٹنل کو ایک جیسے بنیادی اجزاء سے خفیہ کرتے ہیں، اور نجی کلید لیک ہونے پر دونوں بے کار ہو جاتے ہیں۔ انہیں الگ کرنے والی بات یہ ہے کہ سرور کی شناخت کے بارے میں دعوی کون کرتا ہے اور اس دعوے کی جانچ کرنے کی پوزیشن میں کون ہے۔

سرٹیفکیٹ دو کام کرتا ہے جن میں الجھن ہوتی ہے

سرٹیفکیٹ ایک عوامی کلید کو نام سے باندھتا ہے، اور کلید خفیہ کاری اور دستخط کا کام کرتی ہے۔ سرٹیفکیٹ پر دستخط ایک الگ بیان ہے: کسی اتھارٹی نے تصدیق کی ہے کہ نام اس کلید کے مالک کا ہے۔ خود-دستخط شدہ سرٹیفکیٹ یہ بیان اپنے بارے میں خود کرتا ہے، جو کسی تیسرے فریق کا دعوی ہی نہیں ہے۔

عوامی ویب سائٹس کو تیسرے فریق والا نسخہ درکار ہوتا ہے، کیونکہ زائرین بغیر کسی سابقہ تعلق کے آتے ہیں اور براؤزر کے اعتماد کے ذخیرے پر انحصار کرتے ہیں۔ VPN کلائنٹ اجنبی نہیں ہے۔ آپ اسے CA سرٹیفکیٹ دیتے ہیں، یا جو پروفائل وہ انسٹال کرتا ہے اس کے اندر سرور سرٹیفکیٹ پن کرتے ہیں، اس لیے تصدیق بالکل اسی اتھارٹی کے خلاف چلتی ہے جو آپ نے منتخب کی۔ اس جانچ کے بامعنی ہونے کے لیے کسی تجارتی CA کا شامل ہونا ضروری نہیں۔

نتیجے میں بننے والے سیشن کی طاقت کلید کے سائز اور سائفر سیٹ سے آتی ہے، دستخط کرنے والے سے نہیں۔ اسی لیے خود-دستخط شدہ سرٹیفکیٹ کو "کم خفیہ" کہنا سراسر غلط ہے؛ یہ کم وسیع پیمانے پر ضمانت یافتہ ہے، جو ایک مختلف خصوصیت ہے۔

عوامی CA اپنی فیس کہاں کما کر حاصل کرتا ہے

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

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

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

نجی CA VPN میں کہاں موزوں ہے

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

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

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

CA کی نجی کلید طے کرتی ہے کہ بعد میں آپ کیا کر سکتے ہیں

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

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

پوری ٹیم کے لیے ایک مشترکہ کلائنٹ سرٹیفکیٹ کی بجائے ہر ڈیوائس کے لیے ایک سرٹیفکیٹ جاری کریں۔ پھر گمشدہ لیپ ٹاپ آپ کو سب کے لیے دوبارہ جاری کرنے کی بجائے صرف ایک منسوخی کا خرچ دے گا۔

جانچیں کہ آپ کو ورثے میں کیا ملا

کسی بھی تبدیلی کی منصوبہ بندی سے پہلے، وہ سرٹیفکیٹ پڑھیں جو آپ کے پاس پہلے سے ہے:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

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

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

متعلقہ مضامین