Access Server میں ویب سرٹیفکیٹ کی خرابی: خالی CA بنڈل

ویب لاگ ان صفحہ جو DNS کے درست حل ہونے کے باوجود لوڈ نہیں ہوتا، عام طور پر DNS مسئلہ نہیں ہوتا۔ اگر سروس لاگ خالی سرٹیفکیٹ بنڈل راستے یا ویب سرٹیفکیٹ اور نجی کلید کے لیے PEM تجزیے کی ناکامی کا ذکر کرے، تو HTTPS سننے والے کے پاس کوئی قابل استعمال مواد نہیں اور نام حل کرنا مدد نہیں کرے گا۔ مرمت تین کنفیگریشن کلیدوں میں ہے اور کسی بھی VPN کلائنٹ سرٹیفکیٹ کو دوبارہ جاری کرنے کی ضرورت نہیں۔

تین کلیدیں دراصل کس طرف اشارہ کرتی ہیں

حسب ضرورت ویب سرٹیفکیٹ سیٹ cs.cert، cs.priv_key اور cs.ca_bundle سے بیان ہوتا ہے۔ ہر ایک فائل کا راستہ محفوظ کرتا ہے اور ویب سروس تینوں کو مل کر استعمال کرتی ہے۔ غلط کلید والا سرٹیفکیٹ، یا ایسی زنجیر فائل جو دراصل پتی سرٹیفکیٹ ہے، خالی قدر کی طرح ناکام ہوتی ہے۔

یہ کلیدیں Admin اور Client ویب انٹرفیس کی ہیں۔ یہ اُس PKI سے الگ ہیں جو VPN کلائنٹس کو سرٹیفکیٹ جاری کرتی ہے، اس لیے تبدیلی کے لیے پروفائلز، سرور کلید یا سرٹیفکیٹ اتھارٹی کو چھونے کی ضرورت نہیں۔ پورا PKI دوبارہ بنانا یہاں سب سے مہنگی غلطی ہے۔

ایک فرق وقت بچاتا ہے: واضح طور پر خالی حسب ضرورت قدر کسی اوور رائیڈ نہ ہونے کی حالت کے برابر نہیں۔ پہلی تجزیہ کار کو خالی راستہ دیتی ہے، لاگ لائن یہی کہتی ہے۔ دوسری Access Server کو اسی کے اپنے مواد پر چھوڑ دیتی ہے۔

موجود فائل پھر بھی کیوں تجزیہ نہیں ہوتی

تجزیہ کار فائل کے اندر کے لیبل والے بلاک پڑھتا ہے، فائل کا نام نہیں۔ نجی کلید والا .crt، ایک ہی بلاک میں لکھی زنجیر، یا آخری سطر کٹی ہوئی فائل مسترد ہوتی ہے۔ RFC 7468 وہ پڑھنے کے قابل لیبل اسی لیے متعین کرتا ہے کہ وہی بتاتے ہیں کہ آگے کس قسم کی چیز آتی ہے۔

اشیاء کو دیکھیں، ایکسٹینشنز کو نہیں۔ Linux میزبان پر openssl x509 -noout -subject -issuer -in server.pem اور openssl pkey -noout -check -in key.pem دو اہم سوالوں کے جواب دیتے ہیں، اور دونوں کا ماڈیولس یا عوامی کلید موازنہ کرنا ثابت کرتا ہے کہ وہ ساتھ ہیں۔ نجی کلید کی آؤٹ پٹ کو ٹکٹوں اور چیٹ لاگز سے دور رکھیں۔

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

دانستہ طور پر بیک اپ پر واپس جائیں

Access Server کے CLI میں جانچ ہے جو تین راستے بطور دلیل لیتی ہے اور بتاتی ہے کہ سیٹ قابل استعمال ہے یا نہیں۔ نیچے دیے راستے مثال ہیں؛ انہیں میزبان کے محفوظ مقامات سے بدلیں۔

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

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

وہ نام جانچیں جو صارفین واقعی لکھتے ہیں

جب حسب ضرورت مواد خراب ہو اور درست بلٹ اِن بیک اپ اب بھی موجود ہو، تو دستاویزی بازیابی تین اوور رائیڈ ہٹانا اور Access Server کو وہ بیک اپ استعمال کرنے دینا ہے۔ پہلے کنسول رسائی اور موجودہ کنفیگریشن کی نقل تیار کریں۔

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

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

توقع رکھیں کہ بیک اپ کے مؤثر ہونے کے بعد براؤزر مختلف سرٹیفکیٹ دکھائے گا۔ یہی درست نتیجہ ہے؛ اسے اپنے قابلِ اعتماد انتظامی عمل سے تصدیق کریں۔

بازیابی کامیاب لاگ ان کے بعد ہی مکمل ہوتی ہے

TCP سننے والا ظاہر ہونے سے بازیابی مکمل نہیں ہوتی۔ DNS نام، سرٹیفکیٹ کی شناخت اور اُس نام کی زنجیر جانچیں، پھر Admin اور Client دونوں ویب انٹرفیس لوڈ کر کے لاگ ان مکمل کریں۔ پورٹ جانچ ان میں سے کچھ ثابت نہیں کرتی۔

Access Server 3.1 اور بعد کے ورژن ہر SNI میزبان نام کے لیے مختلف ویب سرٹیفکیٹ بھی پیش کر سکتے ہیں۔ اگر یہ ترتیب دیا گیا ہو تو ڈیفالٹ کلیدیں اور نام کے مخصوص اندراجات الگ سیٹ ہیں، اور IP پتے سے جانچ کرنا آسانی سے وہ سرٹیفکیٹ دکھا سکتا ہے جو صارفین کو نہیں ملتا۔ ناکام نام کا سیٹ درست اور جانچیں، اور واقعہ بند کرنے سے پہلے لاگ ان ٹیسٹ دہرائیں۔