خود دستخط شدہ کلائنٹ سرٹیفکیٹ؟ VPN سرور پھر بھی اسے مسترد کرتا ہے
کلائنٹ سرٹیفکیٹ کو اس CA سے زنجیر بننا چاہیے جس پر سرور بھروسا کرتا ہے، اور خود دستخط شدہ ایسا کبھی نہیں کرے گا۔ یہاں یہ ہے کہ CSR کیا کر سکتا ہے اور کیا مانگنا چاہیے۔
آپریٹر ایک پتہ اور صارف نام بھیجتا ہے، اور کلائنٹ CA فائل، سرٹیفکیٹ اور کلید مانگتا ہے۔ ان تینوں کو مقامی طور پر بنانا اگلا واضح قدم لگتا ہے۔ نتیجہ ایسا سرٹیفکیٹ ہوتا ہے جس پر صرف آپ کی اپنی مشین بھروسا کرتی ہے۔ سرور کا بھروسا ایسی CA میں جڑا ہے جسے آپ کنٹرول نہیں کرتے، اس لیے مصافحہ شروع ہونے سے پہلے ختم ہو جاتا ہے۔
بھروسا سرور پر رہتا ہے، آپ کی پروفائل میں نہیں
سرٹیفکیٹ کی تصدیق ایک موازنہ ہے۔ کلائنٹ سرٹیفکیٹ پیش کرتا ہے؛ گیٹ وے جانچتا ہے کہ اسے اس کی تشکیل میں موجود کسی CA نے دستخط کیا ہے یا نہیں۔
آپ کی پروفائل اس CA فائل کا نام دیتی ہے جو کلائنٹ کو سرور کی تصدیق کے لیے استعمال کرنی چاہیے۔ یہ اس CA کا نام نہیں دے سکتی جو سرور کو آپ کی تصدیق کے لیے استعمال کرنی چاہیے۔ تشکیل کا وہ آدھا حصہ آپ کا نہیں ہے۔
خود بنایا ہوا سرٹیفکیٹ تکنیکی طور پر کامل ہونے کے باوجود اس موازنہ میں ناکام ہو جاتا ہے۔ اس پر درست دستخط، موضوع اور تاریخیں ہیں، لیکن جاری کرنے والا ایسی CA ہے جس کا نام گیٹ وے نے کبھی نہیں سنا۔ خرابی مصافحے کے دوران ظاہر ہوتی ہے، سرور کے پہلے ہی سرٹیفکیٹ مانگ لینے کے بعد۔ کلائنٹ پروفائل میں کچھ بھی جواب نہیں بدل سکتا۔
خود دستخط شدہ سرٹیفکیٹ اس کی جگہ کیوں نہیں لے سکتا
خود دستخط شدہ سرٹیفکیٹ اپنی ہی کلید سے دستخط ہوتا ہے۔ دستخط اسی فائل کے خلاف تصدیق ہوتے ہیں، جو اسے خود مطابقت رکھنے والا اور کسی اور کے گیٹ وے کے لیے سند کے طور پر بے کار بنا دیتا ہے۔
گیٹ وے نہیں پوچھتا کہ سرٹیفکیٹ اندرونی طور پر مطابق ہے یا نہیں۔ وہ پوچھتا ہے کہ کسی قابل اعتماد جاری کنندہ نے اس پر دستخط کیے ہیں یا نہیں۔
اسی لیے خرابی کے پیغامات الجھن پیدا کرتے ہیں۔ کلائنٹ سرور کی خرابی جیسی لگنے والی تصدیق کی ناکامی کی اطلاع دے سکتا ہے، جبکہ سرور نامعلوم جاری کنندہ درج کرتا ہے۔ دونوں اسی عدم مطابقت کو مخالف سروں سے بیان کرتے ہیں۔
CSR کا راستہ آپ کی نجی کلید رکھتا ہے
آپ اب بھی زیادہ تر کام مقامی طور پر کر سکتے ہیں۔ کلید کا جوڑا بنائیں، عوامی آدھے کے گرد سرٹیفکیٹ دستخط کی درخواست بنائیں اور وہ درخواست آپریٹر کو بھیجیں۔ صرف درخواست ہی آپ کی مشین سے نکلتی ہے۔ نجی آدھا وہیں رہتا ہے جہاں آپ نے اسے بنایا تھا۔
openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"
آپریٹر اپنی CA سے درخواست پر دستخط کرتا ہے اور سرٹیفکیٹ واپس کرتا ہے۔ آپ کی نجی کلید نے کبھی سفر نہیں کیا، اور نتیجہ اس اینکر سے زنجیر بنتا ہے جس پر گیٹ وے بھروسا کرتا ہے۔
منظم سروسز اکثر CSR چھوڑ دیتی ہیں اور پورا بنڈل جاری کرتی ہیں۔ یہ معقول تبادلہ ہے جب وہی فراہم کنندہ پہلے ہی ٹنل ختم کرتا ہے اور CA رکھتا ہے۔ کلید کی حفاظت اسے رکھنے سے بہتر نہیں ہوتی، کیوں کہ فراہم کنندہ کسی بھی وقت نئی بنا سکتا ہے۔
بنڈل درآمد کیے جاتے ہیں، نصب نہیں
سیکیورٹی جیسے ناموں والے وینڈر بنڈل اکثر OpenVPN پروفائل ہوتے ہیں۔ ان میں تشکیل اور کبھی کبھی سرٹیفکیٹ ہوتے ہیں، اور یہ کچھ نصب نہیں کرتے۔ فائل کو ایسے کلائنٹ میں درآمد کریں جو پروٹوکول بولتا ہے، اور کنکشن تشکیل پا جاتا ہے۔
سنبھالنے کا قاعدہ مواد سے آتا ہے۔ اگر پروفائل میں نجی کلید شامل ہے، تو یہ سند ہے اور پاس ورڈ جیسی دیکھ بھال کی حقدار ہے: کوئی ای میل نہیں، کوئی ذخیرہ نہیں، کوئی مشترکہ ڈاؤن لوڈ فولڈر نہیں۔ جب آپریٹر ca.crt، client.crt اور client.key الگ الگ دیتا ہے، تو انہیں محدود اجازتوں کے ساتھ اکٹھا رکھیں اور پروفائل کو ان کی طرف اشارہ کریں۔
وہ جانچیں شامل کریں جو آپریٹر نے چھوڑ دی ہوں
راؤٹر سے بنی پروفائل میں کبھی کبھی پیر کی تصدیق نہیں ہوتی۔ remote-cert-tls server تقاضا کرتا ہے کہ پیر سرٹیفکیٹ میں سرور کی تصدیق کا مقصد ہو، تاکہ کلائنٹ سرٹیفکیٹ کو بطور سرور دوبارہ نہ چلایا جا سکے۔ وہ ایک سطر واضح جواز کے ساتھ چھوٹی تبدیلی ہے۔
verify-x509-name مزید آگے جاتا ہے جب آپریٹر متوقع موضوع یا SAN کا نام دے سکتا ہے۔ دونوں پروفائل میں چھوٹے اضافے ہیں، اور دونوں قابل دفاع ہیں۔ درآمد کرنے سے پہلے جانچیں کہ آپ کو کیا ملا۔
openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt
تصدیق کی ترتیبات ٹوٹی زنجیر کی مرمت نہیں ہیں۔ اگر جاری کنندہ غلط ہے، تو جواب درست CA کا سرٹیفکیٹ ہے، جانچ بند کرنے والا جھنڈا نہیں۔ تصدیق بند کرنا تصدیق کی ناکامی کو ناقابل شناخت ناکامی میں بدل دیتا ہے۔
ایک بنڈل مانگیں: PEM کی صورت میں اتھارٹی کا سرٹیفکیٹ، اس اتھارٹی کا دستخط شدہ کلائنٹ سرٹیفکیٹ، وہ کلید جو آپ نے بنائی یا کسی ایسے ذریعے سے آئی جس پر آپ بھروسا کرتے ہیں، اور وہ درست سرور نام جو سرٹیفکیٹ پیش کرے گا۔ اسی پیغام میں میعاد ختم ہونے کی تاریخ لکھیں، کیوں کہ میعاد ختم شدہ سرٹیفکیٹ مہینوں بعد نیٹ ورک خرابی جیسا لگتا ہے۔