দুটি OpenVPN সার্টিফিকেট, একটি CCD নাম: কী ভুল হয়েছে

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

সংঘর্ষটি তৈরি হয় নিবন্ধনের সময়ে এবং ধরা পড়ে কেবল সংযোগের সময়ে, সাধারণত কোনো ডিভাইস যখন অন্য একটি মেশিনের অন্তর্গত ঠিকানা বা রুট সেট পায় তখন। এটি প্রতিরোধ করতে হলে সার্ভার কোন ফিল্ড ম্যাপ করে তা নিয়ে একমত হতে হবে, তারপর কিছু স্বাক্ষর করার আগেই সেই মানটি সংরক্ষিত করতে হবে।

আপনার সার্টিফিকেট টুলিং আপনাকে সতর্ক করবে না, কারণ X.509-এর ভেতরের অনন্যতা আর OpenVPN পলিসি নামের অনন্যতা ভিন্ন ভিন্ন সিস্টেম দ্বারা প্রয়োগ করা ভিন্ন ভিন্ন প্রয়োজনীয়তা।

সার্ভার একটি নাম খোঁজে, ফিঙ্গারপ্রিন্ট নয়

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

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

যেখানে দুই কর্তৃপক্ষ একই নামে মেলে

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

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

OpenSSL CA ডকুমেন্টেশন unique_subject সেটিংটি কভার করে যা তার নিজের ডেটাবেসের মতামত নিয়ন্ত্রণ করে, আর সৎ সূচনা হলো আপনার ইস্যুয়িং কনফিগ পড়া, নির্দিষ্ট কোনো EasyRSA বা OpenSSL ডিফল্ট প্রযোজ্য ধরে নেওয়া নয়।

স্বাক্ষরের আগেই কার্যকর নামটি সংরক্ষণ করুন

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

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

নবায়ন ইচ্ছাকৃতভাবে একটি নাম পুনর্ব্যবহার করে

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

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

মেশিনে থাকা টুল দিয়ে ম্যাপিং নিশ্চিত করুন

একটি ডিভাইসকে তার নতুন প্রমাণপত্র দেওয়ার আগে সার্ভার যেভাবে পড়বে সেভাবে সার্টিফিকেট থেকে নামটি পড়ুন, তারপর প্রত্যাশিত নির্বাচিত পলিসি ফাইলের সঙ্গে তা মিলিয়ে দেখুন।

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

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

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