OpenVPN verify-x509-name: subject، name اور name-prefix کا فرق

پہلے موازنے کی قسم پڑھیں، پھر متن: ایک verify-x509-name ہدایت درست دکھائی دے سکتی ہے اور پھر بھی ایسا سرٹیفکیٹ قبول کر سکتی ہے جس پر بھروسہ کرنے کا آپ کا ارادہ نہیں تھا۔ ایک جیسا متوقع متن مگر مختلف اقسام والی دو سطریں دو مختلف شرطیں ہیں۔ پہلے قسم پڑھیں، پھر متن۔ ہدایت کو کنکشن پر ایک اور شرط سمجھیں، پوری جانچ نہیں۔

یہ آپشن درحقیقت کیا دعویٰ کرتا ہے

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

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

subject: مکمل امتیازی نام، حرف بہ حرف

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

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

name: ایک فیلڈ، عام طور پر عام نام

قسم name subject کے ایک فیلڈ کا موازنہ کرتی ہے۔ جب تک پروفائل کچھ اور نہ کہے، وہ فیلڈ عام نام ہے، اور متوقع قدر بالکل وہی فیلڈ ہے، اس کے گرد کا DN نہیں۔

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

name-prefix: ڈیزائن سے وسیع، اس لیے دائرہ محدود کریں

قسم کی ایک توقع name-prefix منتخب فیلڈ کے آغاز سے مطابقت رکھتی ہے۔ یہ نام دینے کے نظام کے لیے سہولت اور کسی بھی مشترکہ چیز کے لیے خطرہ ہے۔

توقع vpn.example ہو تو، دونوں vpn.example.com اور vpn.example.net پاس ہوں گے، بشرطیکہ باقی زنجیر قابلِ اعتماد ہو۔ وسعت ہی خصوصیت ہے، اور یہی وہ حصہ ہے جسے تحریری طور پر جواز بنانا چاہیے۔ سابقہ تب مناسب ہے جب CA اور نام دینے کا نظام آپ کا ہو، اور بہت کمزور جب کوئی عوامی CA اسی نمونے میں جاری کرے۔ اگر نظام کو لچک چاہیے تو کلائنٹ جانچ بڑھانے کے بجائے CA پر محدود کریں۔

شناخت کنندہ سے قسم منتخب کریں، پھر ثابت کریں

آپریٹر کی مراد کردہ شناخت سے پیچھے کی طرف کام کریں۔ اگر وہ پورا DN شائع کرتا ہے اور اسے مستحکم رکھتا ہے، subject یہی ظاہر کرتا ہے۔ اگر خدمت کو عام نام سے پکارتا ہے تو استعمال کریں name ۔ اگر نام دینے کا نظام رکھتا ہے اور اس کی پوری وسعت قبول کرتا ہے، name-prefix یہ واضح طور پر کہتا ہے۔

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

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