Access Server ওয়েব সার্টিফিকেট ত্রুটি: খালি CA বান্ডল ঠিক করা

DNS সঠিকভাবে রিজলভ হওয়া সত্ত্বেও যে ওয়েব লগইন পেজ লোড হয় না, সেটি সাধারণত DNS সমস্যা নয়। পরিষেবা লগে খালি সার্টিফিকেট-বান্ডল পথ বা ওয়েব সার্টিফিকেট ও প্রাইভেট কী-র জন্য PEM পার্স ব্যর্থতার উল্লেখ থাকলে, HTTPS লিসেনারের ব্যবহারযোগ্য উপাদান নেই এবং নাম রিজলিউশনে কোনো লাভ হবে না। মেরামত তিনটি কনফিগারেশন কী-তে, এবং কোনো VPN ক্লায়েন্ট সার্টিফিকেট পুনরায় ইস্যু করার দরকার নেই।

তিনটি কী আসলে কী নির্দেশ করে

কাস্টম ওয়েব সার্টিফিকেট সেট বর্ণিত হয় cs.cert, cs.priv_key ও cs.ca_bundle দিয়ে। প্রতিটি একটি ফাইলের পথ সংরক্ষণ করে, আর তিনটি ওয়েব পরিষেবা একসঙ্গে ব্যবহার করে। ভুল কী-যুক্ত সার্টিফিকেট, বা যে চেইন ফাইল আসলে লিফ সার্টিফিকেট, খালি মানের মতোই ব্যর্থ হয়: লিসেনার ব্রাউজার-গ্রহণযোগ্য চেইন তৈরি করতে পারে না।

এই কী-গুলি অ্যাডমিন ও ক্লায়েন্ট ওয়েব UI-র। এগুলি VPN ক্লায়েন্টদের সার্টিফিকেট ইস্যু করা PKI থেকে আলাদা, তাই প্রতিস্থাপনে ক্লায়েন্ট প্রোফাইল, সার্ভার কী বা সার্টিফিকেট অথরিটি স্পর্শ করার দরকার নেই। ওয়েব TLS ত্রুটিকে গোটা 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

গোটা কনফিগারেশন ডেটাবেস মোছা সার্টিফিকেট মেরামত নয়। ওই তিনটি কী লক্ষ্য করুন, প্রয়োগ করুন, ওয়েব UI উত্তর দিচ্ছে নিশ্চিত করুন। web-ssl ডিরেক্টরির স্ব-স্বাক্ষরিত ফাইলগুলি ফলব্যাক সম্পদ, কাজের জায়গা নয়: সেগুলো ওভাররাইট বা পুনরুৎপাদন করলে হোস্টের একমাত্র কার্যকর উপাদান মুছে যেতে পারে।

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

সফল সাইন-ইনের পরেই পুনরুদ্ধার সম্পূর্ণ

TCP লিসেনার দেখা গেলেই পুনরুদ্ধার শেষ নয়। DNS নাম, সার্টিফিকেট পরিচয় ও সেই নামের চেইন যাচাই করুন, তারপর অ্যাডমিন ও ক্লায়েন্ট দুটি ওয়েব UI লোড করে সাইন-ইন সম্পূর্ণ করুন। পোর্ট পরীক্ষা এর কোনোটিই প্রমাণ করে না।

Access Server 3.1 ও পরবর্তী সংস্করণ প্রতিটি SNI হোস্টনামের জন্য আলাদা ওয়েব সার্টিফিকেটও দিতে পারে। সেটি কনফিগার থাকলে, ডিফল্ট কী ও হোস্টনাম-নির্দিষ্ট এন্ট্রি আলাদা সেট, আর IP ঠিকানায় পরীক্ষা করলে ব্যবহারকারীরা যে সার্টিফিকেট পান তার থেকে ভিন্নটি সহজেই দেখা যেতে পারে। ব্যর্থ নামের সেট ঠিক করে যাচাই করুন, তারপর ঘটনা বন্ধ করার আগে সাইন-ইন পরীক্ষা পুনরাবৃত্তি করুন।