صرف CSR اندراج نہیں: VPN CA کو کیا جانچنا چاہیے

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

اندراج کے دو ماڈلز کو اس بنیاد پر موازنہ کرنا چاہیے کہ وہ کیا باندھتے ہیں، اس بنیاد پر نہیں کہ وہ کون سا پروٹوکول بولتے ہیں۔

درخواست نام کا دعویٰ کرتی ہے، ثابت نہیں کرتی

درخواست کو اس لحاظ سے پڑھیں کہ اس میں واقعی کیا ہے: ایک عوامی کلید، درخواست دہندہ کا منتخب کردہ subject، اور دونوں پر خود دستخط۔ اس ساخت میں کچھ بھی آپ کی فہرست، اکاؤنٹ ڈائرکٹری یا منظوری کے بہاؤ کا حوالہ نہیں دیتا۔ cn=finance-laptop جیسا subject کسی کا ٹائپ کردہ سٹرنگ ہے۔ جب تک اجرا کا عمل اس سٹرنگ کو کسی قابل اعتماد ریکارڈ کے ساتھ نہیں جانچتا، سرٹیفکیٹ دستخط لگا ہوا دعویٰ ہے۔ یہی فرق اندراج کے عمل کے وجود کی پوری وجہ ہے۔

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

ماڈلز کا موازنہ اس بنیاد پر کریں کہ وہ کیا باندھتے ہیں

ہاتھ سے دستخط کرنا وہ باندھتا ہے جسے جانچنا آپریٹر کو یاد رہتا ہے۔ خودکار اندراج سروس تصدیق شدہ درخواست کو ایسے فیصلے سے باندھتی ہے جسے سروس نافذ کر سکتی ہے، اور RFC 7030 ایسا ایک ڈیزائن بیان کرتا ہے جس میں سرٹیفکیٹ واپس دیے جانے سے پہلے گاہک تصدیق کرتا ہے۔ آڈٹ سے بچنے والا فرق خودکاری نہیں ہے؛ وہ یہ ہے کہ شناخت کی جانچ اجرا کے راستے کے اندر ہوتی ہے یا اس کے ساتھ۔

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

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

پہلے اجرا سے ہی زندگی کا دورانیہ درج کریں

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

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

جاری شدہ سرٹیفکیٹ، پھر رسائی کی جانچ کریں

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

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

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