সার্টিফিকেট বৈধ থাকলেও নতুন VPN লগইন ব্যর্থ হচ্ছে: CRL যাচাই করুন

কয়েক মাস বাকি থাকা সার্টিফিকেট আর সঙ্গে সঙ্গে ব্যর্থ হওয়া লগইন দুই ভিন্ন ঘড়িতে চলা দুই ভিন্ন বস্তুর দিকে ইশারা করে। সার্ভার সংযোগ প্রত্যাখ্যান করছে কারণ যে প্রত্যাহারকৃত সার্টিফিকেটের তালিকা সে দেখে তার নিজের মেয়াদোত্তীর্ণ তারিখ পেরিয়ে গেছে, ব্যবহারকারীদের সার্টিফিকেট পুরোনো হয়ে যাওয়ার কারণে নয়। ব্যবহারকারীর সার্টিফিকেট নবায়ন করলে সেই তালিকার জন্য কিছুই হয় না।

দুটি সময়সূচি আলাদা করাই পুরো রোগনির্ণয়, আর এটা ঠিক করে দেয় সমাধানটি কেমন হবে।

দুটি ঘড়ি, আর তাদের একটিই সার্টিফিকেট

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

দুটি বস্তুর মালিকও ভিন্ন: সার্টিফিকেট আসে যে CA তা ইস্যু করেছে তার কাছ থেকে, আর তালিকাটি সময়সূচি অনুযায়ী তৈরি করেন সেই CA যে পরিচালনা করেন। ব্যবহারকারী এটা রিফ্রেশ করতে পারেন না, আর সার্টিফিকেট পুনরায় ইস্যু করলে এটির মেয়াদ বাড়ে না।

সেবা বাস্তবে যে তালিকা লোড করে তা পড়ুন

আপনি যে ফাইল প্রত্যাশা করেন তা থেকে নয়, চলমান কনফিগারেশন থেকে শুরু করুন। crl-verify-এর পথ সম্পূর্ণ, প্রোফাইলের সাপেক্ষে আপেক্ষিক, বা ইমেজে গাঁথা একটি অনুলিপি হতে পারে, আর যাচাইকারী সেই অনুলিপি পড়ে। এটি জায়গাতেই openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate দিয়ে পরীক্ষা করুন এবং তারিখগুলো সার্ভারের ঘড়ির সঙ্গে মিলিয়ে দেখুন।

তারপর নিশ্চিত করুন যে ফাইলটি সত্যিই ব্যবহৃতটিই: openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout দিয়ে এর স্বাক্ষর দেখুন, যা চুপচাপ ক্ষেত্র ছাপানোর বদলে যাচাইয়ের ফলাফল জানায়। অন্য কোনো CA দ্বারা স্বাক্ষরিত তালিকা, বা দ্বিতীয় ফোল্ডারে পড়ে থাকা পুরোনো অনুলিপি, ঠিক মেয়াদোত্তীর্ণ তালিকার মতোই ব্যর্থ হয়।

শূন্য থেকে নয়, প্রত্যাহার ডেটাবেস থেকে আবার তৈরি করুন

নতুন তালিকাটিকে অবশ্যই CA-এর চলমান প্রত্যাহার ডেটাবেস থেকে, অনুমোদিত স্বাক্ষর প্রক্রিয়ার মধ্য দিয়ে আসতে হবে। খালি তালিকা তৈরি করা, বা সূচকের পুরোনো ব্যাকআপ থেকে আবার তৈরি করা, সেই ব্যাকআপের পরে যোগ হওয়া প্রতিটি পরিচয়কে চুপচাপ প্রত্যাহারমুক্ত করে দেয়। এতে লগইনের বিঘ্ন নিরাপত্তা-অবনমনে পরিণত হয়, আর কেউ তা টের পায় না কারণ উপসর্গটি মিলিয়ে যায়।

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

যাচাইকারী যে জায়গায় দেখে সেখানেই মোতায়েন করুন

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

যদি একাধিক সেবা ক্লায়েন্ট যাচাই করে, প্রতিটিতে মোতায়েন করুন। একটি প্রান্তবিন্দু হালনাগাদ করে অন্যটি পুরোনো অনুলিপি দিয়ে রেখে দিলে যে ব্যর্থতা তৈরি হয় তা কেবল সেই ব্যবহারকারীদের কাছেই দেখা যায় যারা দ্বিতীয়টিতে পড়েন। একই রানবুকে সেই প্রান্তবিন্দুগুলোর একটি সংক্ষিপ্ত তালিকা রাখুন। মোতায়েনের পর অনুলিপি পৌঁছেছে ধরে নেওয়ার বদলে প্রতিটির জানানো তালিকার তারিখ যাচাই করুন।

পরবর্তী সময়সীমা পার হওয়ার আগেই তা দৃশ্যমান করুন

দীর্ঘতর প্রকাশনা-বিরতি কোনো প্রক্রিয়া তৈরি না করেই এই ঘটনার কম্পাঙ্ক কমায়। পরিচালকের নীতিমালা থেকে বিরতিটি বাছুন, তারপর আবার তৈরি ও মোতায়েনের যথেষ্ট সময় হাতে রেখে মোতায়েনকৃত তালিকার পরবর্তী হালনাগাদ ক্ষেত্রে সতর্কতা দিন। মোতায়েনকৃত অনুলিপিতে সতর্কতা দিন, CA হোস্টে নয়, কারণ মোতায়েনকৃত অনুলিপিই ব্যর্থ হয়।

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