غیر تعاون یافتہ سرٹیفکیٹ مقصد: درمیانی CA کیوں ناکام ہوتا ہے

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

تصدیق کنندہ نے اصل میں کون سا سرٹیفکیٹ مسترد کیا

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

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

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

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

پتی کا مقصد اور چین کی پالیسی دو ٹیسٹ ہیں

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

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

غائب EKU محدود کرنے والا EKU نہیں ہے

RFC 5280 توسیع شدہ کلید استعمال کے extension کو اختیاری بناتا ہے اور جب موجود ہو تو محدود کرنے والا۔ اس لیے extension کے بغیر CA سرٹیفکیٹ نے سرور کی تصدیق کو 'نہیں' نہیں کہا، جبکہ صرف غیر متعلق مقصد کی فہرست دینے والے نے کچھ بہت مخصوص کہا ہے۔ ان دو حالتوں کو برابر سمجھنا غلط تشخیص اور، اس سے بدتر، غلط علاج پیدا کرتا ہے۔ یہ فرق یہ بھی بتاتا ہے کہ کنسول میں ایک جیسے نظر آنے والے دو اتھارٹیاں چین میں بالکل مختلف کیوں برتاؤ کرتی ہیں۔

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

دوبارہ جاری کرنے سے پہلے ناکامی آف لائن دہرائیں

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

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

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

جاری کرنے کی پالیسی درست کریں، تصدیق کی کال نہیں

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

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