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

আস্থা সার্ভারে থাকে, আপনার প্রোফাইলে নয়

সার্টিফিকেট প্রমাণীকরণ একটি তুলনা। ক্লায়েন্ট একটি সার্টিফিকেট উপস্থাপন করে; গেটওয়ে যাচাই করে এটি তার কনফিগারেশনের কোনো CA দ্বারা স্বাক্ষরিত কি না।

আপনার প্রোফাইল সেই CA ফাইলটির নাম দেয় যা ক্লায়েন্টের সার্ভার যাচাই করতে ব্যবহার করা উচিত। এটি এমন CA-র নাম দিতে পারে না যা সার্ভারের আপনাকে যাচাই করতে ব্যবহার করা উচিত। কনফিগারেশনের সেই অর্ধেক আপনার নয়।

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

কেন স্ব-স্বাক্ষরিত সার্টিফিকেট এর বিকল্প হতে পারে না

স্ব-স্বাক্ষরিত সার্টিফিকেট তার নিজের কি দিয়ে স্বাক্ষরিত। স্বাক্ষরটি একই ফাইলের বিপরীতে যাচাই হয়, যা এটিকে স্ব-সঙ্গত এবং অন্যের গেটওয়ের জন্য একটি প্রমাণপত্র হিসেবে অকেজো করে তোলে।

গেটওয়ে জিজ্ঞাসা করছে না সার্টিফিকেটটি অভ্যন্তরীণভাবে সঙ্গত কি না। এটি জিজ্ঞাসা করছে কোনো বিশ্বস্ত ইস্যুকারী এটি স্বাক্ষর করেছে কি না।

এই কারণেই ত্রুটি বার্তাগুলো বিভ্রান্তিকর। ক্লায়েন্ট এমন একটি যাচাই ব্যর্থতা জানাতে পারে যা সার্ভারের সমস্যার মতো শোনায়, অথচ সার্ভার অজানা ইস্যুকারী লগ করে। দুটোই একই অসঙ্গতি বিপরীত প্রান্ত থেকে বর্ণনা করছে।

CSR পথটি আপনার ব্যক্তিগত কি রাখে

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

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

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

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

বান্ডেল আমদানি করা হয়, ইনস্টল নয়

নিরাপত্তা-সম্পর্কিত শব্দযুক্ত নামের ভেন্ডর বান্ডেলগুলো প্রায়ই OpenVPN প্রোফাইল। এগুলোতে কনফিগারেশন এবং কখনো সার্টিফিকেট থাকে, এবং এগুলো কিছু ইনস্টল করে না। ফাইলটি এমন একটি ক্লায়েন্টে আমদানি করুন যা প্রোটোকলটি বোঝে, এবং সংযোগটি কনফিগার হয়ে যায়।

হ্যান্ডলিং নিয়মটি বিষয়বস্তু থেকেই আসে। যদি প্রোফাইলে ব্যক্তিগত কি এমবেড থাকে, এটি একটি প্রমাণপত্র এবং পাসওয়ার্ডের মতোই যত্ন দাবি করে: কোনো ইমেইল নয়, কোনো রিপোজিটরি নয়, কোনো ভাগ করা ডাউনলোড ফোল্ডার নয়। যখন অপারেটর ca.crt, client.crt এবং client.key আলাদাভাবে পাঠান, সেগুলো সীমিত অনুমতিসহ একসাথে রাখুন এবং প্রোফাইলকে সেগুলোর দিকে নির্দেশ করুন।

অপারেটর যে যাচাইগুলো বাদ দিয়েছেন সেগুলো যোগ করুন

রাউটার-উত্পন্ন প্রোফাইলে কখনো পিয়ার যাচাই থাকে না। remote-cert-tls server দাবি করে পিয়ার সার্টিফিকেটে সার্ভার প্রমাণীকরণের উদ্দেশ্য থাকুক, যাতে একটি ক্লায়েন্ট সার্টিফিকেট সার্ভার হিসেবে পুনরায় চালানো না যায়। ওই এক লাইন একটি স্পষ্ট যৌক্তিকতার সঙ্গে ছোট পরিবর্তন।

verify-x509-name আরও এগিয়ে যায় যখন অপারেটর প্রত্যাশিত সাবজেক্ট বা SAN-এর নাম দিতে পারেন। দুটোই প্রোফাইলে ছোট সংযোজন, এবং দুটোই যুক্তিযুক্ত। আমদানি করার আগে আপনি যা পেয়েছেন তা পরীক্ষা করুন।

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

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

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

সম্পর্কিত নিবন্ধ