VPN سرٹیفکیٹ کی شناخت تبدیل کیے بغیر اس کی تجدید

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

تین شرطیں تجدید کی شکل کا تعین کرتی ہیں

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

اپنے پاس موجود سرٹیفکیٹ کی جانچ سے شروع کریں۔ openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName موضوع، جاری کرنے والا، اعتبار کی مدت اور وہ نام چھاپتا ہے جن کے لیے سرٹیفکیٹ واقعی معتبر ہے۔ وہ آخری فیلڈ سب سے اہم ہے اور سب سے زیادہ فرض کیا جاتا ہے: تجدید کی وہ درخواست جو گاہک کے بھروسے والے SAN کو چھوڑ دے، تکنیکی طور پر معتبر مگر عملی طور پر غلط سرٹیفکیٹ بناتی ہے۔ پرانے سرٹیفکیٹ سے SAN فہرست درخواست میں نقل کریں، یادداشت سے دوبارہ ٹائپ کرنے کے بجائے۔

پہلی شرط: کیا کوئی چیز پتے کو پن کرتی ہے

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

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

دوسری شرط: پن اور سلسلے کا موازنہ کریں

فنگر پرنٹ پن کو قابل جانچ بناتے ہیں: پرانے اور نئے سرٹیفکیٹ پر openssl x509 -noout -fingerprint -sha256 -in server.crt، اور عوامی کلیدوں کے موازنے کے لیے openssl x509 -noout -pubkey۔ اگر گاہک کی ترتیب، موبائل پروفائل یا آلے کا اعتماد ذخیرہ ان میں سے کوئی قدر رکھتا ہے، تو آپ کے پاس پن ہے۔ موبائل VPN پروفائل چھپنے کی عام جگہ ہیں، کیونکہ پروفائل ایک بار تقسیم ہوتا ہے اور پھر کبھی جانچا نہیں جاتا۔

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

سرور واقعی جو سلسلہ بھیجتا ہے اسے openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts کے ساتھ جانچیں، اور openssl verify -CAfile ca.pem -untrusted chain.pem server.crt کے ساتھ مقامی طور پر تصدیق کریں۔ تبدیلی سے پہلے ایسا کرنا آپ کو بعد میں موازنے کے لیے بنیادی لکیر دیتا ہے۔

تیسری شرط: نام کو اور کون تصدیق کرتا ہے

VPN کنسنٹریٹر، لوڈ بیلنسر، مانیٹرنگ پروب، RADIUS یا SAML انضمام اور موبائل پروفائل میں سے ہر ایک متوقع نام یا اعتماد اینکر کی اپنی نقل رکھ سکتا ہے۔ تجدید وہ لمحہ ہے جب وہ نقلیں الگ ہوتی ہیں، کیونکہ سرٹیفکیٹ بدلتا ہے اور نقلیں نہیں۔

تبدیلی سے پہلے ہر صارف کی فہرست بنائیں اور ہر ایک کے لیے فیصلہ کریں کہ اسے تازہ کاری چاہیے یا نہیں۔ جسے آپ بھولیں گے وہی آپ کو بلائے گا۔

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

تعینات کریں، نئی تصدیق کے ساتھ جانچیں، پھر ہٹائیں

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

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

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