ویب سائٹ غلط سرٹیفکیٹ دکھا رہی ہے؟ سننے والے کو تلاش کریں

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

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

وہ سرٹیفکیٹ پڑھیں جو براؤزر کو واقعی ملا

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

پھر اسی راستے پر موجود مشین سے مصافحہ دوبارہ پیدا کریں، پتہ واضح طور پر بتائیں اور مطلوبہ سرور نام بھیجیں تاکہ جواب ڈیفالٹ ہوسٹ کے بجائے سائٹ کو ظاہر کرے۔

openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltName

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

اس پورٹ سے بندھے عمل کی شناخت کریں

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

sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'

اگر TLS آگے موجود لوڈ بیلنسر یا پراکسی ختم کر رہا ہے تو یہیں رکیں اور اس کے بجائے وہی سامنے کا حصہ معائنہ کریں۔ اس کے پیچھے موجود Apache کا نمونہ عوامی براؤزر کو کبھی سرٹیفکیٹ پیش نہ کرے، اس لیے اس کی ترتیب میں ترمیم براؤزر کی دیکھی ہوئی کسی چیز کو نہیں بدلتی۔ ساکٹ کا منظر اور بیرونی مصافحہ ایک ہی راستہ بیان کرنے چاہئیں، اور یہی اس موازنے نے ثابت کیا ہے۔

فائل سے پہلے ورچوئل ہوسٹ ملائیں

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

sudo apachectl -S

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

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

ہر دعویٰ کردہ راستے پر مرمت کی تصدیق کریں

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

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

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