ہر VPN کلائنٹ پر ca.key کاپی کرنا CA کو کیوں توڑ دیتا ہے
کلائنٹ CA کے عوامی سرٹیفکیٹ کی تصدیق کرتا ہے؛ اسے کبھی اس چابی کی ضرورت نہیں ہوتی جو دستخط کرتی ہے۔ ca.key کو ہر ڈیوائس پر کاپی کرنا ایک نقل لینے والے کو اجرا کا اختیار دے دیتا ہے۔
سیٹ اپ ہدایات میں کہیں، کون سی فائلیں وہاں ہونی چاہئیں یہ طے کرنے سے آسان ہونے کی وجہ سے ایک ڈائریکٹری ہر لیپ ٹاپ پر مکمل کاپی کر دی جاتی ہے۔ اس ڈائریکٹری میں ca.key موجود ہے، اور جیسے ہی یہ دوسرے آلے تک پہنچتی ہے، سرٹیفکیٹ اتھارٹی اتھارٹی نہیں رہتی۔ اب کوئی بھی حامل ایسی شناختیں جاری کر سکتا ہے جن پر باقی نیٹ ورک بھروسا کرے گا۔
اس الجھن کو ایک بار سلجھانا مناسب ہے، کیونکہ دونوں فائلیں دکھنے میں یکساں اور کام میں متضاد ہیں۔
تصدیق کا مواد اور دستخط کا مواد
کلائنٹ کو CA کا عوامی سرٹیفکیٹ درکار ہے تاکہ جانچ سکے کہ سامنے والے فریق کا پیش کردہ سرٹیفکیٹ اسی اتھارٹی نے دستخط کیا ہے۔ یہ تصدیق کا کام ہے اور اسے کسی راز کی ضرورت نہیں۔ سامنے والے فریق کے سرٹیفکیٹ پر دستخط کرنا دوسرا کام ہے، جو CA چلانے والا ایک بار، اپنے محفوظ ذخیرے سے کبھی نہ نکلنے والی نجی چابی سے کرتا ہے۔ ان دونوں کاموں کو الگ رکھنا ہی دو فائلیں بھیجنے کا پورا مقصد ہے۔
لہٰذا ca.crt پروفائل میں آتا ہے اور ca.key اس کے قریب کہیں نہیں آتا۔ فائل کے نام ایک روایت ہیں، ضمانت نہیں، اسی لیے قسم کو نام سے اندازہ لگانے کے بجائے جانچنا پڑتا ہے۔
درمیانی CA یا آن لائن اجرا سروس والی ساخت اس کا استثنا نہیں۔ بڑے پیمانے پر آلات کے سرٹیفکیٹ جاری کرتے ہوئے دستخط کی صلاحیت کو آخری مقامات سے دور رکھنے کا یہی معیاری طریقہ ہے۔
کلائنٹ کو اپنی چابی سے کیا ثابت کرنا چاہیے
ہر آلے کو اپنی چابی کی جوڑی اور اپنا سرٹیفکیٹ ملتا ہے، جس پر CA ایک بار دستخط کرتی ہے۔ کلائنٹ وہ سرٹیفکیٹ پیش کرتا ہے اور متعلقہ نجی چابی اپنے پاس ہونے کا ثبوت دیتا ہے، اور سرور طے کرتا ہے کہ قبول کرنا ہے یا نہیں۔ لیپ ٹاپ گم ہونے پر منسوخ ہونے والی شناخت یہی ہے۔
چوری کے بعد یہ فرق سب سے زیادہ اہمیت رکھتا ہے۔ ہر آلے کے لیے الگ شناخت ہو تو کھلا ہوا ایک کلائنٹ منسوخی یا سامنے والے فریق کو ہٹانے سے نکال دیا جاتا ہے، اور باقی بیڑا کام کرتا رہتا ہے۔
افشا شدہ اتھارٹی چابی کو اس طرح سنبھالا نہیں جا سکتا۔ اس نے آج تک جن سرٹیفکیٹس پر دستخط کیے یا کر سکتی تھی، سب مشتبہ ہو جاتے ہیں، اس لیے ردعمل ایک منسوخی نہیں بلکہ بھروسے کی تبدیلی ہے۔ یہ ایک منصوبہ ہے، ٹکٹ نہیں۔
| File | Role | Belongs on |
|---|---|---|
ca.crt | Public certificate used to verify signatures | Every client profile |
ca.key | Private key that issues certificates | Protected CA storage only |
| client key pair | Proves one device's identity | That device alone |
فائل کو کہیں بھی کاپی کرنے سے پہلے پڑھیں
دو کمانڈیں کوئی راز چھاپے بغیر بتاتی ہیں کہ آپ کے ہاتھ میں کس قسم کی چیز ہے۔ پہلی سرٹیفکیٹ پر موضوع اور CA کا جھنڈا بتاتی ہے؛ دوسری چابی کی تصدیق کر کے اس کی قسم بتاتی ہے۔ آپ جس بنڈل کو تقسیم کرنے جا رہے ہیں اس کی فائلوں پر دونوں چلائیں۔ نجی چابی کے طور پر تصدیق ہونے والی کوئی چیز کلائنٹ ڈائریکٹری میں نہیں ہونی چاہیے۔
openssl x509 -in ca.crt -noout -subject -ext basicConstraints openssl pkey -in ca.key -noout -check
اگر کلائنٹ بنڈل میں موجود فائل پر دوسری کمانڈ کامیاب ہو، تو رکیں اور بنڈل کو متاثر سمجھیں۔ جو نتیجہ کہتا ہے کہ چابی درست ہے وہ یہ بھی کہتا ہے کہ وہ موجود ہے، اور موجودگی ہی پورا مسئلہ ہے۔
اُلٹی سمت پر بھی توجہ دیں: کلائنٹ پروفائل میں اس کلائنٹ کی اپنی نجی چابی قانونی طور پر موجود ہوتی ہے۔ ملنے والی ہر چابی مٹا دینا کچھ بہتر کیے بغیر کنکشن توڑ دیتا ہے، اس لیے ہٹانے سے پہلے چیز کی شناخت ضروری ہے۔
پہلے ہی تقسیم شدہ چابی کو قابو میں رکھنا
یہ نہ سمجھیں کہ مقامی نقل مٹانے سے افشا اُلٹ جاتا ہے۔ جس کے پاس بھی فائل تھی وہ اس کی نقل کر سکتا تھا، اور محفوظ مفروضہ یہی ہے کہ اس نے کی۔ آپریٹر کی واقعہ کارروائی کی پیروی کریں اور بھروسے کا لنگر تبدیل کریں، نئی CA کے تحت آلات کے سرٹیفکیٹ دوبارہ جاری کرتے ہوئے۔
پھر وہ پیکیجنگ بدلیں جس نے مسئلہ پیدا کیا۔ فائلوں کی واضح اجازت فہرست کے ساتھ ڈائریکٹری کی فہرست بھیجیں، CA کی چابی ایسی مشین پر رکھیں جو کبھی کلائنٹ بیڑے میں شامل نہ ہو، اور درج کریں کہ کون سا نظام اسے رکھتا ہے۔
اگر اتھارٹی کو بار بار جاری کرنا پڑے تو دستخط کو تنگ دائرہ اور مختصر مدت والی سروس یا درمیانی اتھارٹی کے پیچھے منتقل کریں۔ اس طرح آئندہ کی غلطی پوری تنصیب کے بھروسے کی جڑ کے بجائے اجرا کے ایک حصے کو افشا کرے گی۔