آپ کا VPN کلائنٹ سرٹیفکیٹ پر بھروسا کرنے سے پہلے کیا جانچتا ہے

آپ کا VPN کلائنٹ کہتا ہے کہ سرٹیفکیٹ کی تصدیق نہیں ہو سکی، اور ڈائیلاگ وہیں رک جاتا ہے۔ فائل موجود ہے، سرور چل رہا ہے، اور وہی پروفائل پچھلے مہینے کسی دوسرے لیپ ٹاپ پر چلی تھی۔ اُس ایک سطری وارننگ کے نیچے کلائنٹ نے پیر کے سرٹیفکیٹ کو چار دروازوں سے گزارا: آپ کا ترتیب دیا ہوا سرٹیفکیٹ اتھارٹی دستخط کے راستے کی ضمانت دیتا ہے، وہ راستہ اتھارٹی تک پہنچتا ہے، پیر کا نام وہی ہے جو آپ نے مانگا، اور سرٹیفکیٹ اب اِس مقصد کے لیے قابلِ استعمال ہے۔ بند ہوا دروازہ ڈھونڈیں اور مرمت عموماً ایک فائل ہوتی ہے؛ وہ مرحلہ چھوڑ دیں تو ساری دوپہر بنڈل دوبارہ درآمد کرتے رہیں گے۔

پروفائل میں ترمیم سے پہلے ڈائیلاگ پڑھیں

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

کچھ بھی بدلنے سے پہلے لاگ کی سطح بڑھائیں۔ OpenVPN --verb 4 کے ساتھ چلانے پر مصافحے کے گرد تصدیق کی ناکامی بتاتا ہے، اور strongSwan اپنے شناخت اور زنجیر کے فیصلے charon لاگ میں لکھتا ہے۔ پھر یقینی بنائیں کہ آپ کون سا سرٹیفکیٹ دیکھ رہے ہیں، کیونکہ لوگ عموماً ڈسک کی فائل جانچتے ہیں جبکہ پروفائل پرانی نقل اندر رکھتی ہے۔ جب پروفائل PEM بلاک اندر رکھتی ہے تو اندر رکھا سرٹیفکیٹ ہی جانچا جاتا ہے۔

سرٹیفکیٹ اتھارٹی شناختوں پر دستخط کرتی ہے، اجازتوں پر نہیں

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

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

وہ راستہ دوبارہ بنائیں جو کلائنٹ بنانے کی کوشش کر رہا ہے

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

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

صفر اخراجی حیثیت کا مطلب ہے کہ راستہ اُن فائلوں سے بنا؛ ناکامی اُس سرٹیفکیٹ کا نام لیتی ہے جہاں پہنچا نہیں جا سکا۔ اگر openssl verify کامیاب ہو اور کلائنٹ پھر بھی انکار کرے تو فرق اِس میں ہے کہ سرور واقعی کیا بھیجتا ہے یا پروفائل کون سی اعتماد فائل لوڈ کرتی ہے۔ OpenVPN میں درمیانی سرٹیفکیٹ سرور سرٹیفکیٹ فائل کے ساتھ جا سکتے ہیں یا --extra-certs کے ساتھ الگ دیے جا سکتے ہیں، اور ایک ہی موضوع نام کے نیچے لکھی دو جڑوں والا بنڈل آپ کے ایک کلائنٹ کو غلط شاخ میں بھیجے گا۔

نام اور مقصد الگ دروازے ہیں

زنجیر کی تعمیر کبھی نہیں پوچھتی کہ نام آپ کا ہے یا نہیں۔ OpenVPN اِسے صرف اُس وقت جانچتا ہے جب پروفائل --verify-x509-name مقرر کرے، اور صرف عام نام ملانے کی پرانی عادت اُن سرٹیفکیٹوں پر ٹوٹتی ہے جن کی شناختیں subjectAltName میں رہتی ہیں۔ IKEv2 تعیناتیاں ترتیب شدہ شناخت کو SAN اندراجات یا امتیازی نام سے ملاتی ہیں، کلائنٹ کے مطابق، اور wildcard یا %any قدر آپ کے خیال میں موجود موازنے کو خاموشی سے بند کر دیتی ہے۔

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

منسوخی صرف اُس وقت چلتی ہے جب کسی نے اُسے ترتیب دیا ہو

CRL یا OCSP جواب خودکار طور پر نہیں دیکھے جاتے۔ OpenVPN سرور پر کلائنٹ سرٹیفکیٹ فہرست کے ساتھ صرف اُس وقت ملائے جاتے ہیں جب --crl-verify کسی فہرست کی طرف اشارہ کرے۔ سرور سرٹیفکیٹ کی کلائنٹ طرف جانچ عمل درآمد پر منحصر ہے اور اکثر موجود نہیں ہوتی۔ strongSwan کو پیر کے لیے CRL دیکھنے سے پہلے اپنا منسوخی پلگ ان اور پالیسی درکار ہوتی ہے۔

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

تصدیق کو آن رکھنے والا مرمت کا ترتیب

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

فہرست ایک ہی مرحلے میں مکمل کریں: پروفائل کی لوڈ کردہ فائل کی تصدیق کریں، راستہ خود بنائیں، دیکھیں کہ سرور درمیانی سرٹیفکیٹ بھیجتا ہے یا نہیں، گھڑی کا موازنہ کریں، SAN پڑھیں، EKU پڑھیں، پھر دوبارہ جڑیں اور وہی لاگ سطر غائب ہوتے دیکھیں۔ اگر کسی ڈیوائس کو CA بالکل نہ دیا جا سکے تو پننگ ایماندار متبادل ہے، کیونکہ OpenVPN 2.6 --peer-fingerprint قبول کرتا ہے اور جانچ ہٹانے کے بجائے بھروسا ایک کلید تک محدود کر دیتا ہے۔ اِن میں سے ہر میدان کے معنی کے لیے RFC 5280 حوالہ ہے۔