কেন প্রতিটি VPN ক্লায়েন্টে ca.key কপি করলে CA ভেঙে পড়ে
ক্লায়েন্ট CA-এর সার্বজনীন সার্টিফিকেট যাচাই করে; সই করা কী তার কখনোই প্রয়োজন হয় না। ca.key প্রতিটি ডিভাইসে কপি করা মানে যে কেউ একটি কপি নিলেই ইস্যু করার ক্ষমতা পেয়ে যায়।
সেটআপের নির্দেশনার কোথাও একটি ডিরেক্টরি প্রতিটি ল্যাপটপে সম্পূর্ণ কপি করা হয়, কারণ কোন ফাইলগুলো সেখানে থাকা উচিত তা ঠিক করার চেয়ে এটা সহজ ছিল। সেই ডিরেক্টরিতে ca.key আছে, আর এটি দ্বিতীয় ডিভাইসে পৌঁছাতেই সার্টিফিকেট অথরিটি আর অথরিটি থাকে না। এখন যে কেউ এটি রাখে সে এমন পরিচয় ইস্যু করতে পারে যা বাকি নেটওয়ার্ক বিশ্বাস করবে।
এই বিভ্রান্তি একবার পরিষ্কার করা মূল্যবান, কারণ দুটি ফাইল দেখতে একই রকম কিন্তু বিপরীত কাজ করে।
যাচাইয়ের উপাদান ও সই করার উপাদান
ক্লায়েন্টের কাছে CA-এর সার্বজনীন সার্টিফিকেট প্রয়োজন যাতে যাচাই করতে পারে যে প্রতিপক্ষ যে সার্টিফিকেট দিয়েছে তা ওই অথরিটি সই করেছে। এটি একটি যাচাইয়ের কাজ এবং এতে কোনো গোপন তথ্যের দরকার নেই। প্রতিপক্ষের সার্টিফিকেটে সই করা ভিন্ন কাজ, যা CA পরিচালনাকারী একবার সম্পাদন করে, সেই ব্যক্তিগত কী দিয়ে যা কখনো তার সুরক্ষিত ভাণ্ডার ছাড়ে না। এই দুই কাজ আলাদা রাখাই দুটি ফাইল পাঠানোর পুরো উদ্দেশ্য।
তাই ca.crt প্রোফাইলে থাকে, আর ca.key তার কাছাকাছি কোথাও থাকে না। ফাইলের নাম একটি রীতি, নিশ্চয়তা নয়, তাই নাম থেকে অনুমান না করে ধরনটি পরীক্ষা করতে হয়।
মধ্যবর্তী CA বা অনলাইন ইস্যুয়িং সেবা সহ স্থাপত্য এর ব্যতিক্রম নয়। স্কেলে ডিভাইস সার্টিফিকেট ইস্যু করার সময় সই করার সামর্থ্য প্রান্ত থেকে দূরে রাখার এটাই আদর্শ উপায়।
ক্লায়েন্টকে নিজের কী দিয়ে কী প্রমাণ করতে হবে
প্রতিটি ডিভাইস নিজের কী জোড়া ও নিজের সার্টিফিকেট পায়, যা CA একবার সই করে। ক্লায়েন্ট সেই সার্টিফিকেট উপস্থাপন করে এবং সংশ্লিষ্ট ব্যক্তিগত কী তার কাছে আছে তা প্রমাণ করে, আর সার্ভার তা গ্রহণ করবে কি না তা ঠিক করে। ল্যাপটপ হারালে যে পরিচয় বাতিল হয় সেটি এই পরিচয়ই।
চুরির পরে এই পার্থক্যই সবচেয়ে গুরুত্বপূর্ণ। প্রতি ডিভাইসের পরিচয় থাকলে একটি প্রকাশিত ক্লায়েন্ট বাতিল বা প্রতিপক্ষ অপসারণের মাধ্যমে সরিয়ে ফেলা হয়, আর বাকি সবকিছু কাজ করতে থাকে।
ফাঁস হওয়া অথরিটি কী এভাবে সামলানো যায় না। এটি এতদিনে যেসব সার্টিফিকেটে সই করেছে বা করতে পারত, সবই সন্দেহজনক হয়ে যায়, তাই প্রতিক্রিয়া একটি একক বাতিল নয়, বিশ্বাস প্রতিস্থাপন। এটি একটি প্রকল্প, টিকিট নয়।
| File | Role | Belongs on |
|---|---|---|
ca.crt | Public certificate used to verify signatures | Every client profile |
ca.key | Private key that issues certificates | Protected CA storage only |
| client key pair | Proves one device's identity | That device alone |
ফাইল কোথাও কপি করার আগে পড়ুন
দুটি কমান্ড কোনো গোপন তথ্য ছাপিয়ে না দিয়েই বলে দেয় আপনি কোন ধরনের বস্তু হাতে ধরে আছেন। প্রথমটি একটি সার্টিফিকেটের সাবজেক্ট ও CA ফ্ল্যাগ জানায়; দ্বিতীয়টি একটি কী যাচাই করে তার ধরন জানায়। আপনি যে বান্ডেল বিতরণ করতে যাচ্ছেন তার ফাইলগুলোতে দুটোই চালান। ব্যক্তিগত কী হিসেবে যাচাই হয় এমন কিছু ক্লায়েন্ট ডিরেক্টরিতে থাকা উচিত নয়।
openssl x509 -in ca.crt -noout -subject -ext basicConstraints openssl pkey -in ca.key -noout -check
ক্লায়েন্ট বান্ডেলে থাকা কোনো ফাইলে দ্বিতীয় কমান্ড সফল হলে থামুন এবং বান্ডেলটিকে আপসহীন মনে করুন। যে আউটপুট বলে কী বৈধ, তা আরও বলে যে কী-টি উপস্থিত, আর উপস্থিতিই পুরো সমস্যা।
উল্টো দিকটিও লক্ষ করুন: ক্লায়েন্ট প্রোফাইলে সেই ক্লায়েন্টের নিজের ব্যক্তিগত কী বৈধভাবেই থাকে। যে কোনো কী পেলেই মুছে ফেলা সংযোগ ভেঙে দেয় কিন্তু কিছুই ভালো করে না, তাই সরানোর আগে বস্তুটির পরিচয় নির্ধারণ করতে হবে।
ইতিমধ্যে বিতরণ করা কী নিয়ন্ত্রণে রাখা
স্থানীয় কপি মুছে ফেললে প্রকাশ বাতিল হয়ে যায় এমন ধরে নেবেন না। যে কেউ ফাইলটি রেখেছিল সে কপি করে থাকতে পারে, আর নিরাপদ অনুমান হলো সে করেছে। অপারেটরের ঘটনা প্রক্রিয়া অনুসরণ করুন এবং বিশ্বাসের অ্যাঙ্কর প্রতিস্থাপন করুন, নতুন CA-এর অধীনে ডিভাইস সার্টিফিকেট পুনরায় ইস্যু করে।
তারপর যে প্যাকেজিং সমস্যাটি তৈরি করেছে তা বদলান। স্পষ্ট ফাইল অনুমোদন তালিকা সহ ডিরেক্টরি তালিকা পাঠান, CA কী এমন একটি মেশিনে রাখুন যা কখনো ক্লায়েন্ট ফ্লিটে যোগ দেয় না, এবং কোন সিস্টেম এটি ধরে রাখে তা লিপিবদ্ধ করুন।
অথরিটিকে ঘনঘন ইস্যু করতে হলে সই করার কাজ একটি সেবা বা সংকীর্ণ পরিধি ও কম বৈধতার মধ্যবর্তী অথরিটির পিছনে সরিয়ে দিন। এভাবে ভবিষ্যতের ভুল পুরো স্থাপনার বিশ্বাসের মূল নয়, ইস্যুর একটি অংশ প্রকাশ করে।