لیف سرٹیفکیٹ درست، چین ختم: گہرائی پڑھیں

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

گہرائی ناکام سرٹیفکیٹ کا نام لیتی ہے

OpenSSL تشخیص میں، گہرائی 0 ہدف سرٹیفکیٹ ہے اور گہرائی 1 وہ جاری کرنے والا ہے جس نے اس پر دستخط کیے، جبکہ بڑے نمبر اعتماد کے لنگر کی طرف جاری رہتے ہیں۔ گہرائی 1 پر رپورٹ شدہ میعاد ختم ہونا لیف پر موجود موجودہ notAfter سے متصادم نہیں، اس لیے نظر آنے والے سرٹیفکیٹ کو دوبارہ چیک کرنا کبھی خرابی کی وضاحت نہیں کرے گا۔

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

ایک سے زیادہ سرٹیفکیٹ کردار والی مصنوعات پر بھی توجہ دیں۔ OpenVPN Access Server پر، ویب انٹرفیس کی حفاظت کرنے والے سرٹیفکیٹ VPN کنکشنز کے لیے استعمال ہونے والوں سے الگ ہیں، اس لیے ایڈمن صفحہ کھولنے والا براؤزر ٹنل کے راستے کے بارے میں کچھ ثابت نہیں کرتا۔

اعتماد کے ان پٹ چین کے امیدواروں سے الگ ہیں

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

ڈیفالٹ راستہ اور اسٹور -no-CApath -no-CAstore سے غیر فعال کرنا ٹیسٹ کو دیانت دار رکھتا ہے: نتیجہ پھر آپ کے بتائے گئے فائلوں پر منحصر ہوتا ہے، ورک اسٹیشن کے اتفاقاً بھروسے پر نہیں۔ OpenSSL تصدیق کا حوالہ ان اختیارات اور ان سے پیدا ہونے والی تشخیص کی دستاویز کرتا ہے۔

تصدیق کامیاب ہونے پر -show_chain بنائی گئی چین پرنٹ کرتا ہے، جو اس بات کی تصدیق کے لیے مفید ہے کہ راستہ وہی ہے جو آپ نے ارادہ کیا۔ ناکام ہونے پر، رپورٹ شدہ گہرائی اور subject رکھیں؛ وہ دو فیلڈ اگلے قاری کو بتاتے ہیں کہ کون سا سرٹیفکیٹ معائنہ کرنا ہے۔

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

جانچ کیا ثابت کرتی ہے اور کیا چھوڑ دیتی ہے

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

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

ہر سرٹیفکیٹ کی کھڑکی کو ایک ایک کر کے دیکھنے کے بجائے مجموعہ کے طور پر دیکھنے کے لیے انہیں یوں پرنٹ کریں:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

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

تصدیق کمزور کیے بغیر راستہ درست کریں

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

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

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