ایک مشترکہ نام، دو سرٹیفکیٹ: اجازت کی فہرست یا منسوخی؟

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

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

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

سرور کی ترتیب پڑھیں اور نوٹ کریں کہ کون سا شناختی ماخذ زیر استعمال ہے۔ username-as-common-name تصدیق شدہ صارف نام کو کلائنٹ مخصوص تلاش کے لیے مؤثر نام بناتا ہے۔ اس کے بغیر سرٹیفکیٹ کا موضوع مشترکہ نام استعمال ہوتا ہے۔ جواب جو بھی ہو، کسی بھی اجازت فہرست کو چھونے سے پہلے اسے لکھ لیں۔

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

دیکھیں کہ کلائنٹ کو واقعی کیا داخل کرتا ہے

مطابق فائل سے منسلک client-config-dir کلائنٹ مخصوص اختیارات فراہم کرتا ہے؛ اکیلے میں یہ داخلے کا قاعدہ نہیں ہے۔ نام سے داخلے کے لیے ccd-exclusive درکار ہے، جو مطابق فائل کے بغیر کلائنٹس کو مسترد کرتا ہے۔ چلتی تعیناتی میں اسے فعال کرنے سے ہر وہ شخص منقطع ہو جاتا ہے جس کے نام کی فائل نہیں ہے، اس لیے کچھ بھی بدلنے سے پہلے فائلیں گنیں۔

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

گنتی ہی جانچ ہے: ڈائریکٹری کی فہرست کا موازنہ ان شناختوں سے کریں جن کے جڑنے کی توقع ہے۔

پھر یقینی بنائیں کہ ہر فائل کا نام مؤثر شناخت سے بالکل مطابقت رکھتا ہے، بشمول حروف کے بڑے چھوٹے ہونے اور خالی جگہوں کے۔ office-laptop کے لیے فائل اس سرٹیفکیٹ کے لیے کچھ نہیں کرتی جس کا موضوع Office-Laptop پڑھا جاتا ہے۔ آخر کی خالی جگہیں بھی عام فہرست سے چھپ جاتی ہیں، اور اسی طرح موجود دکھنے والی فائل بغیر پڑھے رہ جاتی ہے۔

گیٹ وے کی لوڈ کردہ CRL جانچیں

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

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

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

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

تبدیل کریں، پھر دونوں نتائج ثابت کریں

اسی مشترکہ نام کے تحت متبادل جاری کریں، دونوں سیریل نمبر درج کریں، اور اس کے بعد ہی پرانا منسوخ کریں۔ یہ ترتیب تبدیلی کی تیاری کے دوران کام کرنے والی شناخت دستیاب رکھتی ہے۔

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

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

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

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

جہاں سرٹیفکیٹ کی سطح کا کنٹرول ضروری ہو، وہ طریقہ استعمال کریں جو سرٹیفکیٹ کا نام لیتا ہے: CRL اندراجات، یا تصدیق کا ہک جو آپریٹر کے رکھے ہوئے فنگر پرنٹ کی جانچ کرتا ہے۔ دونوں کو دیکھ بھال درکار ہے، اور دونوں اس چیز کے بارے میں ایماندار ہیں جس کی وہ جانچ کرتے ہیں۔ OpenVPN 2.6 کا دستی کے مطابق crl-verify اور کلائنٹ مخصوص داخلہ الگ الگ اختیارات کے طور پر درج ہیں، اسی وجہ سے۔

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