এক সাধারণ নাম, দুটি সার্টিফিকেট: অনুমোদিত তালিকা না প্রত্যাহার?
একই সাধারণ নামের জন্য সার্টিফিকেট পুনরায় ইস্যু করলে পুরোটির বৈধতা থাকে। নামের অনুমোদিত তালিকা তাদের আলাদা করতে পারে না; কেবল একটি CRL বা সিরিয়াল যাচাই পারে।
একই সাধারণ নামে ল্যাপটপের সার্টিফিকেট পুনরায় ইস্যু করা প্রতিস্থাপনের মতো মনে হয়, এবং সবাই ধরে নেয় পুরোটির মৃত্যু হয়েছে। তা নয়। পূর্ববর্তীটি একই কর্তৃপক্ষের স্বাক্ষরিত বৈধ সার্টিফিকেট হিসেবেই থাকে, এবং নাম দিয়ে ক্লায়েন্ট গ্রহণ করে এমন যেকোনো নিয়ন্ত্রণ তাকে গ্রহণ করতেই থাকবে। পরিচয় যাচাই ও প্রমাণপত্র যাচাইয়ের মধ্যে পার্থক্য করে সিরিয়াল নম্বর, আর ঠিক সেখানেই সংশোধনী হওয়া উচিত।
সার্ভার যে নামকরণ নীতি ব্যবহার করে তা দিয়ে শুরু করুন
দুটি নিয়ন্ত্রণ মিলিয়ে ফেলা হয়: ক্লায়েন্ট নিজেকে যেই বলে দাবি করে সেই কারণে তাকে গ্রহণ করা, এবং একটি নির্দিষ্ট সার্টিফিকেট সেবা থেকে সরানো। প্রথমটি নাম যাচাই, দ্বিতীয়টি প্রত্যাহার যাচাই। তারা ভিন্ন প্রশ্নের উত্তর দেয়, এবং একটি স্থাপনায় একটি থাকতে পারে অন্যটি ছাড়াই।
সার্ভার কনফিগারেশন পড়ুন এবং কোন পরিচয়ের উৎস ব্যবহৃত হচ্ছে তা খেয়াল করুন। username-as-common-name প্রমাণীকৃত ব্যবহারকারীর নামকে ক্লায়েন্ট-নির্দিষ্ট অনুসন্ধানের কার্যকর নাম করে তোলে। এটি ছাড়া সার্টিফিকেট থেকে সাবজেক্টের সাধারণ নাম ব্যবহার হয়। উত্তর যাই হোক, কোনো অনুমোদিত তালিকা স্পর্শ করার আগে তা লিখে রাখুন।
দুই পথ একই সার্টিফিকেটের জন্য ভিন্ন অনুমোদিত নামের সেট দেয়। এখানে অনুমান করা মানে ভুল ফাইল সম্পাদনা করে নিয়ন্ত্রণটি কাজ করে না বলে সিদ্ধান্তে পৌঁছানো।
আসলে কী ক্লায়েন্ট গ্রহণ করে তা যাচাই করুন
মিলে যাওয়া ফাইলসহ client-config-dir প্রতি-ক্লায়েন্ট অপশন দেয়; একা এটি গ্রহণের নিয়ম নয়। নাম দিয়ে গ্রহণের জন্য প্রয়োজন ccd-exclusive, যা মিলে যাওয়া ফাইল নেই এমন ক্লায়েন্ট প্রত্যাখ্যান করে। চালু স্থাপনায় এটি সক্রিয় করলে যাদের নামের ফাইল নেই তাদের সবাই সংযোগ বিচ্ছিন্ন হয়, তাই কিছু বদলানোর আগে ফাইলগুলো গুনুন।
grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/গণনাই যাচাই: ডিরেক্টরি তালিকাকে আপনি যাদের সংযোগ আশা করেন সেই পরিচয়গুলোর সঙ্গে মেলান।
তারপর নিশ্চিত করুন প্রতিটি ফাইলের নাম কার্যকর পরিচয়ের সঙ্গে হুবহু মেলে, অক্ষরের বড়-ছোট ও ফাঁকা জায়গাসহ। office-laptop এর জন্য একটি ফাইল এমন সার্টিফিকেটের জন্য কিছুই করে না যার সাবজেক্ট Office-Laptop। পেছনের ফাঁকা জায়গাও সাধারণ তালিকা থেকে লুকিয়ে থাকে, আর এভাবেই উপস্থিত দেখতে ফাইলটি অপঠিত থেকে যায়।
গেটওয়ে যে CRL লোড করে তা যাচাই করুন
একটি CRL প্রত্যাহৃত সার্টিফিকেটগুলো ইস্যুকারী ও সিরিয়াল দ্বারা নামকরণ করে, যা নাম যাচাইয়ের নেই এমন সূক্ষ্মতা। দুটি সার্টিফিকেট একই সাধারণ নাম ভাগ করে সিরিয়ালে ভিন্ন হতে পারে, এবং কেবল সিরিয়াল-স্তরের তালিকাই তাদের আলাদা করে।
ফাইলটিতে আদৌ ভরসা করার আগে কনফিগার করা পথ, ইস্যুর তারিখ ও পরবর্তী-হালনাগাদের ক্ষেত্র নিশ্চিত করুন।
openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subjectCRL-এর সিরিয়ালের সঙ্গে আপনি রাখতে চাওয়া সার্টিফিকেটের সিরিয়াল মেলান। এই মেলানোই পুরো পরীক্ষা, আর একবার চোখে করে নেওয়া এমন স্ক্রিপ্টে ভরসা করার চেয়ে ভালো যা কেউ পড়েনি। হালনাগাদ CRL গেটওয়ে যে পথ আগে থেকেই পড়ে সেই পথে বিতরণ করুন। ভুল ডিরেক্টরিতে থাকা CRL কিছুই প্রয়োগ করে না, এবং কোনো ক্লায়েন্ট লগ তা উল্লেখ করবে না।
প্রতিস্থাপন করুন, তারপর দুই ফলাফলই প্রমাণ করুন
একই সাধারণ নামে প্রতিস্থাপনটি ইস্যু করুন, দুই সিরিয়াল লিখে রাখুন, এবং কেবল তারপর পুরোটিকে প্রত্যাহার করুন। এই ক্রম পরিবর্তন প্রস্তুত করার সময় একটি কার্যকর পরিচয় উপলব্ধ রাখে।
আগে প্রতিস্থাপনটি পরীক্ষা করুন: এটি প্রমাণীকরণ করবে এবং তার নামের অধিকার অনুযায়ী সবকিছুতে পৌঁছাবে। তারপর পুরো সার্টিফিকেট পরীক্ষা করে নিশ্চিত করুন এটি প্রত্যাখ্যাত হয়, কারণ সফল প্রতিস্থাপন প্রত্যাহার সম্পর্কে কিছুই বলে না। যদি দুটোই এখনো সংযোগ করে, তবে প্রত্যাহারের ইনপুট পড়া হচ্ছে না বা পুরো সিরিয়াল কখনো তালিকাভুক্ত হয়নি। যদি কোনোটিই সংযোগ না করে, তবে আপনি প্রমাণপত্র নয়, গ্রহণের নিয়মটিই ভেঙেছেন।
ইতিমধ্যে প্রতিষ্ঠিত সেশন আলাদা বিষয়, কারণ প্রত্যাহার নতুন প্রমাণীকরণে প্রযোজ্য, যদি না গেটওয়ে জীবন্ত সংযোগ বাদ দেওয়ার জন্যও কনফিগার করা থাকে। কাউকে প্রতিশ্রুতি দেওয়ার আগে তাৎক্ষণিক অপসারণ প্রয়োজন কি না ঠিক করুন।
নাম যাচাই কখনোই যা করতে পারে না
অনুমোদিত তালিকা উত্তর দেয় এই পরিচয় সংযোগ করতে পারবে কি না। এটি বলতে পারে না সেই পরিচয় কোন সার্টিফিকেট ব্যবহার করেছে, এবং পুরোনো প্রমাণপত্র যতদিন বৈধ ও অপ্রত্যাহৃত থাকে ততদিন তা গ্রহণ করবে। এই ফাঁক ঘটনার সময় প্রকাশ পায়, যখন প্রতিস্থাপন মাসখানেক আগে ইস্যু হয়েছে আর পূর্ববর্তীটি এখনো কাজ করে।
যেখানে সার্টিফিকেট-স্তরের নিয়ন্ত্রণ প্রয়োজন, সেখানে সার্টিফিকেটের নাম বলে এমন একটি ব্যবস্থা ব্যবহার করুন: CRL এন্ট্রি, বা একটি যাচাই hook যা অপারেটরের রক্ষণাবেক্ষণ করা ফিঙ্গারপ্রিন্ট যাচাই করে। দুটোই রক্ষণাবেক্ষণ খরচ করে, আর দুটোই যে বস্তু পরীক্ষা করে সে সম্পর্কে সৎ। OpenVPN 2.6 ম্যানুয়াল নথিভুক্ত করে crl-verify এবং ক্লায়েন্ট-নির্দিষ্ট গ্রহণকে পৃথক অপশন হিসেবে, সেই কারণেই।
কোন নিয়ন্ত্রণ কোন কাজ করে তা লিখে রাখুন, তারপর নেতিবাচক ক্ষেত্রটি পরীক্ষা করুন। যে প্রত্যাহারকে আপনি কখনো কোনো সংযোগ প্রত্যাখ্যান করতে দেখেননি, তা এমন কনফিগারেশন যা কাজ করবে বলে আপনি আশা করছেন।