Nebula-এর জন্য তিনটি ফাইল দরকার: CA, হোস্ট সার্টিফিকেট, হোস্ট কী
তিনটি ফাইল তিনটি কাজ করে: CA সার্টিফিকেট বিশ্বাস প্রতিষ্ঠা করে, হোস্ট সার্টিফিকেট নোডের নাম দেয়, আর ব্যক্তিগত কী শুধু সেই নোডেই থাকে।
কাউকে একটি Nebula ডিরেক্টরি দিলে তিনি সাধারণত পুরোটা কপি করেন, যার মধ্যে সেই ফাইলটিও থাকে যা কখনো আপনার ওয়ার্কস্টেশন ছাড়া উচিত নয়। বিভ্রান্তিটা বোঝা যায়, কারণ হোস্টের PKI ব্লকে থাকা তিনটি ফাইলই একরকম দেখায় এবং দুটি সার্টিফিকেট। প্রতিটি আলাদা প্রশ্নের উত্তর দেয়, আর তাদের মধ্যে কেবল দুটি নোডে থাকা উচিত। কিছু কপি করার আগে ভূমিকা অনুযায়ী সেগুলো আলাদা করুন।
তিনটি ফাইল, তিনটি আলাদা কাজ
CA সার্টিফিকেট হলো বিশ্বাসের নোঙর: অন্য হোস্ট নিজের পরিচয় দিলে কোন কর্তৃপক্ষকে বিশ্বাস করবে তা এটি হোস্টকে জানায়। হোস্ট সার্টিফিকেট হলো নোডের নিজের প্রমাণপত্র, যা সেই কর্তৃপক্ষ স্বাক্ষর করে। হোস্ট কী হলো তার সঙ্গে মেলানো ব্যক্তিগত অর্ধেক, এবং তা ঠিক একটি মেশিনেরই। CA সার্টিফিকেট ও নিজের জোড়া থাকলে একটি নোড overlay নেটওয়ার্কে যোগ দিয়ে নিজের পরিচয় প্রমাণ করতে পারে। অন্যের কী থাকলে একটি নোডও নিজেকে সেই ব্যক্তি বলে দাবি করতে পারে, আর এই ভুলটাই প্রতিরোধ করতে এই বিন্যাস তৈরি।
তাই চালু হোস্ট ডিরেক্টরি দ্বিতীয় মেশিনে কপি করা কোনো শর্টকাট নয়। এটি অনুমেয় পরিণতিসহ একটি নকল পরিচয়।
স্বাক্ষর কী কখনো ভ্রমণ করে না
CA স্বাক্ষর কী কোনো হোস্ট কনফিগারেশনের অংশ নয়। এটি নতুন পরিচয় তৈরি করে, আর যার কাছে এটি আছে সে যেকোনো overlay ঠিকানা ও যেকোনো গ্রুপের জন্য সার্টিফিকেট বানাতে পারে। সমকক্ষদের স্বাক্ষর যাচাই করতে কেবল পাবলিক CA সার্টিফিকেটই লাগে, তাই ক্লায়েন্টে ব্যক্তিগত অর্ধেকের কোনো ভূমিকাই নেই। সার্টিফিকেট যেখানে ইস্যু হয় সেই মেশিনেই এটি রাখুন, আর দুর্ঘটনাক্রমে কপি হলে সেটিকে সুবিধা নয়, ঘটনা হিসেবে ধরুন।
একাধিক মানুষকে সার্টিফিকেট ইস্যু করতে হলে কী-এর কপি নয়, একটি প্রক্রিয়া দিন। ল্যাপটপে রাখা ভাগ করা স্বাক্ষর কী এমন এক কর্তৃত্ব যা কেউ নিরীক্ষা বা বাতিল করতে পারে না।
হোস্ট সার্টিফিকেটের ভেতরে কী থাকে
হোস্ট সার্টিফিকেট একটি ফাইলের নামের চেয়ে বেশি কিছুকে কী-এর সঙ্গে বাঁধে। এটি নোডের overlay ঠিকানা, তার নাম ও গ্রুপ সদস্যপদ বহন করে, সবই স্বাক্ষরিত যাতে সমকক্ষ গ্রহণ করবে কি না তা ঠিক করতে পারে। তাই হোস্টের নাম বদলানো মানে কনফিগারেশনের একটি লাইন সম্পাদনা নয়, নতুন সার্টিফিকেট ইস্যু করা।
nebula-cert print -path host.crt দেখায় আসলে কী ইস্যু হয়েছে। সার্টিফিকেটে আপনার ইচ্ছাকৃত ঠিকানাই আছে ধরে নেওয়ার আগে এটি পড়ুন।
রিলোড সবসময় যথেষ্ট নয়
কিছু PKI সেটিং সিগন্যালে রিলোড হয়, কিছু হয় না। যে সার্টিফিকেটের overlay ঠিকানা বদলেছে সেটিই চিরাচরিত ক্ষেত্র যেখানে রিলোড নয়, প্রসেস রিস্টার্ট দরকার।
চলমান প্রসেস আসলে কোন পথগুলো খুলেছে তা নিশ্চিত করুন, কেবল কনফিগ ফাইলে লেখা পথ নয়। তারপর একটি প্রমাণপত্র বদলান, সংযোগ ও লগ যাচাই করুন, তারপরেই পরেরটি ধরুন। পুরোনো সার্টিফিকেট মেমরিতে রেখেই সফল দেখানো রিলোড এমন অমিল তৈরি করে যা রাউটিং সমস্যার মতো দেখায়। রিস্টার্ট করা সস্তা; অর্ধেক overlay যে পরিচয়কে এখনো পুরোনোভাবে দেখে তা ডিবাগ করা সস্তা নয়।
পরিচয় সরাতে ব্লকলিস্ট দরকার
হারানো বা প্রকাশিত প্রমাণপত্র বদলের দুটি অর্ধেক আছে। নতুন সার্টিফিকেট প্রবেশাধিকার ফিরিয়ে দেয়, আর পুরোনো পরিচয় গ্রহণযোগ্য হওয়া বন্ধ করতে হয়। এগুলো আলাদা কাজ, আর কেবল প্রথমটি করলে আক্রান্ত প্রমাণপত্রটি বৈধই থেকে যায়।
ব্লকলিস্ট এমন একটি ফাইল যা আপনি হোস্টদের মধ্যে বিতরণ করেন, lighthouse নিজে থেকে পাঠায় না। আজ যেগুলো অফলাইন সেগুলোসহ প্রতিটি নোডে এটি কীভাবে পৌঁছাবে তা পরিকল্পনা করুন, এবং কোন ফিঙ্গারপ্রিন্ট ব্লক করেছেন তা লিখে রাখুন। ইস্যু করা মেশিনে কী ঘোরান এবং নতুন সার্টিফিকেটের বিবরণ হোস্ট রেকর্ডের সঙ্গে রাখুন। যে মেশিনটি আপনি সম্পাদনা করেছেন কেবল সেখানেই থাকা বাতিলকরণ বাতিলকরণ নয়।