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

ایک تجدید، دو رویے

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

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

تجدید آبجیکٹ بدلتی ہے، صرف تاریخ نہیں

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

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

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

پڑھیں کہ کلائنٹ کیا پن کر رہا ہے

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

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

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

ہر بیک اینڈ کے پیش کردہ سرٹیفکیٹ کا موازنہ کریں

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

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

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

اعتماد کو منظم راستے سے بدلیں

کہیں بھی قبول کرنے سے پہلے پہلے سے قابل اعتماد انتظامی چینل کے ذریعے تبدیلی کی تصدیق کریں۔ قابل اعتماد میعاد ختم ہونے کی تاریخ ملکیت کا ثبوت نہیں ہے۔ منظم ترتیب کو اس کے مالک عمل کے ذریعے اپ ڈیٹ کریں، قابل قبول شناختوں کی کسی بھی منصوبہ بند اوورلیپ کے ساتھ، اور تعیناتی کی مطلوبہ نام کی تصدیق برقرار رکھیں۔ نام کی جانچ کے بغیر پن اس CA اعتماد سے کمزور ڈیزائن ہے جسے اس نے بدلا۔

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

متعلقہ مضامین