IKEv2 میں دو دستخط ہیں: سرٹیفکیٹ اور IKE_AUTH

آپ کا ٹکٹ کہتا ہے کہ سرٹیفکیٹ SHA-256 ہے، جبکہ گیٹ وے لاگ کسی دوسرے دستخطی الگورتھم کا نام لیتا ہے، اور کسی نے پہلے ہی CA کو دوبارہ جاری کرنے کی درخواست تیار کر لی ہے۔ اس درخواست کے کہیں جانے سے پہلے دونوں دستخط الگ کریں: ایک عوامی کلید پر جاری کرنے والے کی مہر ہے، دوسرا ساتھی کا یہ ثبوت کہ IKE_AUTH کے دوران اس کے پاس مماثل نجی کلید ہے۔ مختلف اجزا انہیں منتخب کرتے ہیں، اور ان کا مختلف ہونا جائز ہے۔ ہر ایک کو وہاں سے پڑھنے میں جہاں وہ رہتا ہے، دو کمانڈز اور ایک جدول لگتی ہے۔

سرٹیفکیٹ سے جاری کرنے والے کا دستخط پڑھیں

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

openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"

دونوں لیبل الگ اندراجات کے طور پر لکھیں۔ پہلا CA کا بیان کرتا ہے، دوسرا موضوع کی کلید کا، اور کوئی بھی آن لائن دستخط کی پیش گوئی نہیں کرتا۔

IKE منتقلی سے آن لائن دستخط پڑھیں

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

ipsec statusall | grep -i "auth\|proposal"

جب ایک فریق ایسی اسکیم بتائے جو دوسرا بنا نہیں سکتا، تو آپ کو وہی تضاد مل گیا جس کے بارے میں ٹکٹ تھا۔ CA کو دوبارہ جاری کرنا اس کا غلط علاج ہے، کیونکہ ناکام ہونے والا سرٹیفکیٹ کبھی نہیں تھا۔

RFC 7427 کیا بدلتا ہے اور کیا نہیں

اصل طریقے RFC 7296 میں ہر الگورتھم امتزاج کے مطابق شمار کیے گئے ہیں۔ بعد کا RFC 7427 دستخطی توسیع دستخطی ہیش کی معاونت کے اشارے کے ساتھ عام Digital Signature طریقہ شامل کرتا ہے، اس لیے نئی ہیش کو اپنا طریقہ نمبر درکار نہیں رہتا۔ یہ بات چیت سے طے ہوتا ہے، مفروضہ نہیں: ساتھی کو توسیع اس لیے نہیں ملتی کہ اس کی لائبریری وہی سرٹیفکیٹ تجزیہ کر سکتی ہے، اور جو ساتھی صرف اصل طریقے نافذ کرتا ہے وہ گیٹ وے کو ان میں سے ایک رکھنے پر مجبور کرتا ہے۔ یہ مطابقت کی لاگت والی پالیسی کی تبدیلی ہے، خرابی نہیں۔

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

فہرست میں چار سطریں رکھیں

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

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

PKI کو کمزور کیے بغیر پرانا معاملہ طے کریں

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

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