ওয়েবসাইট ভুল সার্টিফিকেট দেখাচ্ছে? শ্রোতাকে খুঁজুন

ওয়েব হোস্টে 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-এ টাইপিং ভুল থাকা নামযুক্ত ভার্চুয়াল হোস্ট ঠিক এই লক্ষণ তৈরি করে, এবং যে দ্বিতীয় কনফিগারেশন ফাইল প্রথমে সবকিছু ধরে রাখা হোস্ট লোড করে সেটিও তা-ই করে। দুটোই সেই বিন্যাস তালিকায় দৃশ্যমান।

প্রতিটি দাবি করা পথে মেরামত যাচাই করুন

অনুমোদিত পরিবর্তনের পরে প্রতিটি ঠিকানা পরিবারের জন্য হোস্টনাম-নির্দিষ্ট পরীক্ষা পুনরাবৃত্তি করুন এবং বাইপাস পতাকার বদলে ব্রাউজারের স্বাভাবিক বৈধতা যাচাই দিয়ে শেষ করুন। ভাগ করা শ্রোতা সেটিংস স্পর্শ করার আগে আলাদা প্রশাসনিক পথ সংরক্ষণ করুন, কারণ সেখানকার ভুল সেই অ্যাক্সেস সরিয়ে দেয় যা আপনি তা পূর্বাবস্থায় ফেরাতে ব্যবহার করতেন। তারপর লিখুন কোন শ্রোতা উত্তর দিয়েছিল, কোন ভার্চুয়াল হোস্ট মিলেছিল এবং আগে ও পরে কোন সার্টিফিকেট পরিবেশন করা হয়েছিল।

প্যাকেজ সরানো বিন্যাস বদলাতে পারে এবং মূল অমিলকে ব্যাখ্যাহীন রেখে দিতে পারে, তাই সেই রেকর্ড মেরামতের চেয়ে বেশি টিকে থাকে।

আপনি যা চান তা হলো উদ্দেশ্যপ্রণোদিত সাইটটি উদ্দেশ্যপ্রণোদিত প্রবেশ বিন্দুতে। অসম্পর্কিত সেবা হারিয়ে যাওয়ার পরে ভিন্ন সার্টিফিকেট সেই ফলাফল নয়, এমনকি যখন ব্রাউজার অভিযোগ করা বন্ধ করে দেয়।