جب آپ VPN سرٹیفکیٹ اتھارٹی تبدیل کرتے ہیں تو کیا ہوتا ہے

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

ایک تبدیلی، دو الگ تبدیلیاں

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

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

تصدیق کنندہ کیا دیکھتا ہے، ترتیب سے

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

اس سفر کو آف لائن دہرانے کے لیے، -CAfile کو بالکل اسی بنڈل کی طرف اشارہ کریں جو آپ تعینات کریں گے، نظام کے ذخیرے کی طرف نہیں۔ ورنہ آپ تبدیلی نہیں، میزبان جانچ رہے ہیں:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

یہ حکم صرف گیٹ وے کے HTTPS انتظامی صفحے جیسے سادہ TLS سننے والے کے خلاف کام کرتا ہے؛ OpenVPN کا کنٹرول چینل TLS سے پہلے آتا ہے، اس لیے s_client سرنگ کی دستک نہیں دیکھ سکتا۔

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

پرانی سرنگ کیوں چلتی رہتی ہے

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

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

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

موضوع کا نام دوبارہ استعمال کرنے کا جال

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

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

ایسی گردش جو نیٹ ورک نہ گرائے

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

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

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

نتیجہ جانچیں، فائلوں کی فہرست نہیں

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

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

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