ভুল VPN সার্টিফিকেট প্রত্যাহার করেছেন? পুনরুদ্ধারের বিকল্প ও সীমা

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

সার্টিফিকেট চিহ্নিত করুন, ব্যক্তিকে নয়

সাধারণ নামের পুনরাবৃত্তি হয়। গত প্রান্তিকে পুনরায় নিবন্ধিত একজন ব্যবহারকারীর একই CN এবং ভিন্ন ক্রমিক নম্বরের দুটি সার্টিফিকেট থাকতে পারে, আর একটি প্রত্যাহার করলে অন্যটি কাজ করতে থাকে। প্রথমে সঠিক বস্তুটি নির্ধারণ করুন:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

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

একটি দ্রুত আচরণগত পরীক্ষা কিছু না বদলেই অবস্থা নিশ্চিত করে:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

যদি এটি সার্টিফিকেটকে প্রত্যাহৃত হিসেবে জানায়, তাহলে CRL ও ক্লায়েন্ট একমত; যদি এটি পরিষ্কারভাবে যাচাই হয়, তাহলে আপনার হাতে থাকা ক্লায়েন্টটি প্রত্যাহৃতটি নয়, এবং অনুসন্ধান চলতে থাকে।

CA ধারণ নাকি স্থায়ী প্রত্যাহার ব্যবহার করেছে তা পরীক্ষা করুন

RFC 5280 certificateHold-কে সাময়িক অবস্থা এবং removeFromCRL-কে তা মুক্ত করার সংকেত হিসেবে সংজ্ঞায়িত করে। সেই জীবনচক্র বাস্তব, কিন্তু এটি সাধারণ আনডো বোতাম নয়। কারণ কোড পড়লে বোঝা যায় ইস্যুকারী আদৌ মুক্তি সমর্থন করতে চেয়েছিল কি না।

ফাঁদ হলো ধরে নেওয়া যে সাময়িক অভিপ্রায় মানে সাময়িক রেকর্ড। যদি CA এন্ট্রিতে keyCompromise বা cessationOfOperation থাকে, তাহলে বোতাম টেপা ব্যক্তি যা করতে চেয়েছিলেন তা যাই হোক, সার্টিফিকেট স্থায়ীভাবে প্রত্যাহৃত। বিপরীতভাবে, যে CA ধারণ-মুক্তি বাস্তবায়ন করে না সেখানে certificateHold চিহ্নিত এন্ট্রি বাস্তবে স্থায়ী, কারণ মুক্তিটি কখনো প্রকাশিত হবে না।

OpenSSL-ভিত্তিক CA সীমাটি দেখায়। ca কমান্ড -crl_reason মান গ্রহণ করে, যার মধ্যে certificateHold ও removeFromCRL রয়েছে, কিন্তু এটি ডেল্টা CRL তৈরি করে না — OpenSSL CA ডকুমেন্টেশন তার CRL আউটপুটের জন্য এই সীমা উল্লেখ করে। যে সম্পূর্ণ CRL কেবল ক্রমিক নম্বরটি বাদ দেয় তা "এই এন্ট্রি মুক্ত" বলা ডেল্টার থেকে ভিন্ন প্রকাশনা মডেল, তাই OpenSSL-ভিত্তিক VPN CA-তে removeFromCRL পেস্ট করলে মানদণ্ডে সংজ্ঞায়িত মুক্তি তৈরি হয় না।

যদি কী প্রকাশিত হয়ে থাকতে পারে, তা প্রতিস্থাপন করুন

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

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

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

যদি এটি প্রশাসনিক ভুল ছিল, নিয়ন্ত্রণে প্রতিস্থাপন করুন

যখন প্রত্যাহারটি কেবল ভুল ছিল এবং কী কখনো প্রকাশিত হয়নি, মেরামত তবুও সম্পাদনার বদলে নিয়ন্ত্রিত প্রতিস্থাপন। ইস্যুকারীর সমর্থিত প্রক্রিয়া ব্যবহার করুন, ক্রমিক নম্বর ও ইস্যু ইতিহাস অক্ষত রাখুন, এবং দুটি প্রলুব্ধকর শর্টকাট এড়িয়ে চলুন: index.txt-এ অবস্থা অক্ষরটি R থেকে আবার V-এ উল্টে দেওয়া, এবং ইস্যু সারিটি মুছে ফেলা যাতে নতুন সার্টিফিকেট ক্রমিক নম্বরটি পুনরায় ব্যবহার করতে পারে।

OpenSSL CA-তে ডেটাবেসটি ট্যাব-বিভক্ত এবং ভুল পড়া সহজ, যা হাতে সম্পাদনাকে আকর্ষণীয় করে তোলে:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

এটি পড়ুন, লিখবেন না। ফাইল সম্পাদনা কোনো অডিট ট্রেইল ছাড়াই পরবর্তী CRL বদলে দেয়, এবং যে কোনো দ্বিতীয় CA ইনস্ট্যান্স বা ব্যাকআপ যা এখনও মূল সারিটি ধরে রাখে তা পরে এর সাথে অসঙ্গত হবে।

প্রতিস্থাপন ইস্যু করার পরে, স্বাভাবিক প্রক্রিয়ায় একটি নতুন CRL প্রকাশ করুন এবং ক্লায়েন্টদের তা তুলে নিতে দিন। CRL সরানো, তার জীবনকাল শূন্যে নামানো বা ক্লায়েন্ট প্রোফাইলে প্রত্যাহার পরীক্ষা নিষ্ক্রিয় করা CA যে কোনো দিন প্রকাশ করেছে এমন প্রতিটি অন্য প্রত্যাহার দুর্বল করে একজন ব্যবহারকারীকে ঠিক করে।

নতুন অনুমোদন নিশ্চিত করুন এবং রেকর্ড রাখুন

নতুন সংযোগ দিয়ে পরীক্ষা করুন, আগে খোলা সেশন দিয়ে নয়। একটি জীবন্ত টানেল নতুন হ্যান্ডশেক যে অনুমোদন পরীক্ষা করে তা আবার নাও চালাতে পারে, এবং CRL ক্যাশ মানে ক্লায়েন্ট রিফ্রেশ না হওয়া পর্যন্ত সংযোগ চালিয়ে যেতে পারে। বিচ্ছিন্ন করুন, আবার সংযোগ করুন, এবং সার্ভার লগে নিশ্চিত করুন কোন ক্রমিক নম্বর অনুমোদিত হয়েছে।

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

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