SSTP سرٹیفکیٹ کا عدم مطابقت: وہ نام جو آپ کے سرور کو پیش کرنا چاہیے

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

پروفائل کا نام طے کرتا ہے کہ کیا جانچا جائے گا

SSTP، TCP 443 پر TLS چلاتا ہے، اس لیے کلائنٹ کسی بھی دوسرے TLS کلائنٹ کی طرح برتاؤ کرتا ہے: پروفائل سے ہوسٹ نام لیتا ہے، اُس نام کی درخواست کرتا ہے اور اُس سے سرٹیفکیٹ کا موازنہ کرتا ہے۔ اگر پروفائل میں IP پتہ لکھیں تو موازنہ IP پتوں کا موازنہ بن جاتا ہے، جسے بیشتر سرور سرٹیفکیٹ پورا نہیں کرتے۔

چنانچہ براؤزر کی جانچ کامیاب ہو سکتی ہے جبکہ VPN ناکام ہو، کیونکہ براؤزر نے پروفائل سے مختلف نام استعمال کیا۔ یہی تقسیم اُس وقت بھی نظر آتی ہے جب split-horizon DNS VPN کا ہوسٹ نام اندرونی پتے میں حل کرتا ہے جبکہ براؤزر کسی عوامی پتے تک پہنچ گیا ہو۔ پہلے پروفائل کو دستاویزی ہوسٹ نام کے مطابق لائیں، پھر سرٹیفکیٹ کا موازنہ کریں۔ اس سے پہلے آپ جو کچھ اور بدلیں وہ اندازہ ہے۔

سرور سرٹیفکیٹ میں کیا ہونا چاہیے

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

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

لاگ ان تفصیلات سے پہلے زنجیر اور گھڑی جانچیں

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

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

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

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

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

نام یا سرٹیفکیٹ درست کریں اور دوبارہ جانچیں

تین شرطیں مرمت طے کرتی ہیں۔ اگر پروفائل کا نام غلط ہے تو پروفائل درست کریں یا غائب نام سرٹیفکیٹ میں شامل کریں۔ اگر زنجیر نامکمل ہے تو سرور پر درمیانی سرٹیفکیٹ نصب کریں۔ اگر مقصد غلط ہے تو اردگرد پیوند لگانے کے بجائے دوبارہ جاری کریں۔

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