منسوخ کلائنٹ اب بھی جڑتا ہے: فہرست کبھی نہیں پہنچی

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

فہرست ایک ان پٹ ہے، کوئی عمل نہیں

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

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

نیا کنکشن بمقابلہ چلتی سیشن

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

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

وہ فائل پہنچائیں جو تصدیق کنندہ واقعی پڑھتا ہے

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

ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pem

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

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

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

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

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

کیا کچھ بھی منسوخ نہیں کرتا

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

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